Azure DevOps용 관리형 DevOps 풀(미리 보기)

아티클
08/14/2024

개발 및 플랫폼 엔지니어링 팀이 사용자 지정 DevOps 풀을 신속하게 설정하고 관리할 수 있도록 설계된 관리형 DevOps 풀의 미리 보기를 발표하게 되어 기쁩니다.

또한 GitHub Advanced Security에 대한 미터 사용량 추정 API를 향상하여 사용자를 식별하는 데 도움이 되는 새로운 기능을 제공합니다.

자세한 내용은 릴리스 정보를 확인하세요.

Azure DevOps용 GitHub Advanced Security

고급 보안 미터 사용량 API는 이제 사용자 ID를 반환합니다.
빌드 없이 C# 및 Java 프로젝트에 대한 GitHub 고급 보안 코드 검사

Azure DevOps용 GitHub Advanced Security

고급 보안 미터 사용량 API는 이제 사용자 ID를 반환합니다.

고급 보안 사용자를 식별할 수 있도록 미터 사용량 추정 API는 이제 표시 이름, CUID, 전자 메일 식별자 및 ID 설명자를 포함하여 각 사용자의 Azure DevOps ID를 반환합니다. 이 기능은 조직, 프로젝트 및 리포지토리 수준에서 사용할 수 있습니다. 이 새 엔드포인트를 사용하기 위해 구문은 엔드포인트에 추가되는 기존 미터 사용량 API 엔드포인트와 /details 유사합니다.

조직 수준에서: GET https://advsec.dev.azure.com/{organization}/_apis/management/meterUsageEstimate/details?api-version=7.2-preview.1
프로젝트 수준에서: GET https://advsec.dev.azure.com/{organization}/{project}/_apis/management/meterUsageEstimate/details?api-version=7.2-preview.1
리포지토리 수준에서: GET https://advsec.dev.azure.com/{organization}/{project}/_apis/management/repositories/{repository}/meterUsageEstimate/details?api-version=7.2-preview.1

빌드 없이 C# 및 Java 프로젝트에 대한 GitHub 고급 보안 코드 검사

CodeQL을 사용한 코드 검색에는 단일 언어에 대한 리포지토리의 코드를 나타내는 데이터베이스에서 쿼리를 실행하는 작업이 포함됩니다. C/C++, C#, Go, Java 및 Swift와 같은 컴파일된 언어의 경우 일반적으로 먼저 코드를 빌드해야 합니다.

그러나 Azure DevOps용 GitHub Advanced Security의 정적 분석 엔진인 CodeQL은 이제 빌드 없이 C# 및 Java 프로젝트를 검색할 수 있습니다. 빌드 모드가 "none"으로 설정되면 CodeQL 데이터베이스가 코드베이스에서 직접 생성되어 빌드 단계를 무시합니다.

컴파일된 모든 언어의 기본 빌드 모드는 "수동"입니다 . 그러나 C# 및 Java의 경우 빌드 모드를 "없음"으로 변경할 수 있습니다.

AdvancedSecurity-Codeql-Init@1 설정 중에 빌드 모드를 구성할 수 있습니다. Azure DevOps를 사용하여 GitHub Advanced Security에서 코드 검색을 구성하는 방법에 대한 자세한 지침은 코드 검색 설정을 참조하세요.

고려:

"none"을 선택하고 지원되는 규격 언어 C# 또는 Java 이외의 언어가 있는 경우 파이프라인 작업이 예상대로 작동하지 않을 수 있습니다.
빌드 모드 "none" 은 현재 다른 해석된 언어(예: JavaScript, Python, Ruby)와 함께 작동합니다.
유효한 예: 빌드 모드가 "none"으로 설정된 C# 및 JavaScript입니다. (해석된 언어의 JavaScript)
잘못된 예: 빌드 모드가 "없음"으로 설정된 C#, JavaScript 및 Swift입니다(Swift는 빌드 모드 "none"에서 지원되지 않음).

Azure Pipelines

관리형 DevOps 풀(미리 보기)

엔지니어링 팀은 사용자를 위한 애플리케이션 및 서비스를 개발하기 위해 코드를 작성하는 데 집중할 수 있을 때 탁월합니다. 그러나 실제로는 DevOps 인프라 유지 관리와 같은 다른 작업을 관리하는 데 상당한 시간이 소요되는 경우가 많습니다.

개발 및 플랫폼 엔지니어링 팀이 고유한 요구 사항에 맞게 사용자 지정 DevOps 풀을 배포할 수 있도록 설계된 새로운 Azure DevOps 기능인 관리형 DevOps 풀(MDP)의 공개 미리 보기를 발표하게 되어 기쁩니다. MDP는 확장 집합 에이전트의 유연성과 Microsoft 호스팅 에이전트와 관련된 유지 관리의 용이성을 결합하여 팀이 성능, 보안, 규정 준수 및 비용 효율성을 최적화하면서 일관성과 모범 사례를 설정할 수 있도록 합니다.

관리형 DevOps 풀의 주요 이점은 다음과 같습니다.

사용자를 대신하여 호스트됨: MDP는 Microsoft에서 호스트되고 관리되며, 가상 머신은 Microsoft 소유의 Azure 구독 내에서 만들어지고 유지 관리되는 에이전트에 전원을 공급합니다.
관리에 소요된 시간: MDP는 에이전트, 특히 온-프레미스 인프라 또는 수동으로 유지 관리된 시스템을 기반으로 하는 에이전트를 관리하는 데 소요되는 시간을 크게 줄입니다.
특정 풀: 새 풀을 쉽게 만들 수 있으므로 조직은 여러 팀별 또는 워크로드별 풀을 쉽게 만들 수 있습니다.
DevOps 청구: MDP는 여러 기능을 통해 팀의 DevOps 청구서를 최적화하는 데 도움이 됩니다. 팀이 풀의 QoS/성능과 비용 간에 최적의 균형을 쉽게 찾을 수 있습니다.
확장 가능: MDP는 단일 풀에서 1000개의 에이전트로 확장됩니다.

Teams는 Microsoft 호스팅 에이전트에 있는 동일한 소프트웨어가 포함된 빠른 시작 이미지 또는 팀이 시나리오에 고유한 필수 구성 요소로 만든 이미지를 사용하여 풀을 만들 수 있습니다.

블로그 게시물 또는 설명서를 참조하여 관리형 DevOps 풀에 대해 자세히 알아보세요.

Azure 파이프라인 작업은 노드 20을 사용합니다.

대부분의 파이프라인 작업은 Node를 실행자로 사용합니다. 이제 NodeJS를 실행자로 사용하는 Azure 파이프라인 작업은 모두 NodeJS 20을 사용합니다. 작업 확장 프로그램의 작성자는 노드 20을 사용하도록 작업을 업데이트해야 합니다. 업그레이드 방법에 대한 지침은 사용자 지정 작업을 최신 노드로 업그레이드하려면 어떻게 해야 하나요?

빌드 파이프라인 권한 만들기

파이프라인 보안을 강화하기 위해 파이프라인 수준에서 새 권한을 Create build pipeline도입합니다.

이전에는 파이프라인을 Edit build pipeline 만들거나 편집할 수 있는 권한이 필요했습니다. 이로 인해 파이프라인을 만들 수 있는 모든 사용자가 생성하지 않은 파이프라인도 편집할 수 있으므로 보안 위험이 제기되었습니다. 이를 방지하는 데는 시간이 많이 소요되었습니다.

보안을 손상시키지 않고 파이프라인 환경을 향상시키기 위해 이제 권한이 있는 Edit build pipeline 모든 사용자 및 그룹도 사용 권한을 받 Create build pipeline 습니다.

파이프라인을 만들면 해당 작성자에 사용 권한이 부여됩니다 Edit build pipeline .

파이프라인 보안을 개선하기 위해 참가자 및 읽기 권한자와 같은 사용자 그룹에서 사용 권한을 제거 Edit build pipeline 하도록 선택할 수 있습니다. 이렇게 하면 기본적으로 파이프라인의 작성자만 편집할 수 있습니다.

참고 항목

빌드 파이프라인 편집 권한은 다른 사용자가 YAML 파이프라인을 편집할 수 없으므로 파이프라인의 속성만 편집되지 않도록 보호합니다.

새 프로젝트의 경우 권한이 있는 Edit build pipeline 사용자 및 그룹도 사용 권한을 갖습니다 Create build pipeline . 이는 향후 변경될 수 있습니다.

스테이지 수준에서 배타적 잠금 검사

일부 사용 사례에서는 파이프라인이 지정된 시간에 한 번만 특정 리소스에 액세스해야 합니다. 이 경우 를 지원하기 위해 배타적 잠금 검사가 있습니다.

파이프라인 실행이 언제든지 스테이지에 액세스해야 하는 경우에도 비슷한 상황이 발생합니다. 예를 들어 Azure 리소스 그룹에 배포하는 단계가 있는 경우 여러 파이프라인 실행이 동일한 리소스 그룹을 동시에 업데이트하지 못하도록 방지할 수 있습니다. 현재 이 작업을 수행하려면 환경과 같은 프록시 리소스를 사용하고 해당 환경에 배타적 잠금 검사를 수행해야 합니다. 이 방법은 시간이 많이 걸리고, 복잡성을 더하고, 유지 관리 작업을 늘릴 수 있습니다.

이 스프린트에서는 스테이지 수준에서 배타적 잠금을 지정하는 지원이 도입되었습니다. ID가 있는 스테이지가 있고 해당 lockBehavior 속성을 지정하면 해당 스테이지에 대해 잠금이 자동으로 만들어집니다. 동작은 sequential 리소스 수준 및 단계 수준 잠금 모두에 대해 일관성을 유지합니다. 그러나 파이프라인의 runLatest 모든 분기가 아닌 동일한 분기에 대한 빌드만 취소 runLatest 하므로 동작은 다릅니다.

파이프라인 실행의 템플릿 정보

파이프라인 실행 - 확장되고 파이프라인 실행에 포함된 템플릿에 대한 정보가 포함된 REST API 가져오기를 업데이트했습니다.

예를 들어 다음 YAML 파이프라인 코드가 있다고 간주합니다.

extends:
  template: template-stages.yml@templates
  parameters:
    stages:
    - stage: deploy
      jobs:
      - job:
        steps:
        - template: template-step.yml

새 REST API에는 다음과 같은 새 속성이 있습니다.

"yamlDetails":
    {
        "extendedTemplates":
        [
            {
                "yamlFile": "template-stages.yml",
                "repoAlias": "templates"
            }
        ],
        "includedTemplates":
        [
            {
                "yamlFile": "template-step.yml",
                "repoAlias": "templates"
            }
        ],
        "rootYamlFile":
        {
            "ref": "refs/heads/main",
            "yamlFile": "azure-pipelines.yml",
            "repoAlias": "self"
        },
        "expandedYamlUrl": "https://dev.azure.com/fabrikamfiber/161cfeeb-d9fd-395c-917b-fec46db44fbb/_apis/build/builds/39224/logs/1"
    }

수동으로 트리거된 YAML 파이프라인 단계

수동으로 트리거된 YAML 파이프라인 단계에 대한 요청을 자주 받습니다. 통합 파이프라인을 원하지만 항상 완료까지 실행하지 않으려는 경우에 유용합니다.

예를 들어 파이프라인에는 스테이징 환경에 빌드, 테스트, 배포 및 프로덕션에 배포하는 단계가 포함될 수 있습니다. 프로덕션 배포를 제외한 모든 스테이지가 자동으로 실행되도록 할 수 있습니다. 준비되면 수동으로 트리거하는 것이 좋습니다.

이 스프린트를 사용하면 수동으로 트리거된 YAML 파이프라인 단계에 대한 지원이 추가됩니다. 이 기능을 사용하려면 스테이지에 trigger: manual 속성을 추가해야 합니다.

다음 YAML 파이프라인 예제를 고려합니다.

stages:
- stage: stage_WUS1
  displayName: Deploy WUS1
  trigger: manual
  jobs:
  - job: DeployJob
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'AzureWIF'
        scriptType: 'ps'
        scriptLocation: 'inlineScript'
        inlineScript: 'Write-host ''hello, world'''     
- stage: stage_WUS2
  displayName: Deploy WUS2
  trigger: manual
  jobs:
  - job: DeployJob
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'AzureWIF'
        scriptType: 'ps'
        scriptLocation: 'inlineScript'
        inlineScript: 'Write-host ''hello, world'''

이 파이프라인을 실행할 때 환경은 다음과 같습니다.

수동으로 트리거된 YAML 파이프라인 단계의 스크린샷.

수동으로 트리거된 단계는 종속성이 없으며 언제든지 실행할 수 있습니다. 파이프라인 실행은 실행하기 위해 수동으로 트리거된 단계만 남아 있는 경우 완료됩니다.

다음 단계

참고 항목

이러한 기능은 향후 2~3주 동안 출시될 예정입니다.

Azure DevOps로 이동하여 살펴보세요.

Azure DevOps로 이동

피드백을 제공하는 방법

이러한 기능에 대해 어떻게 생각하는지 듣고 싶습니다. 도움말 메뉴를 사용하여 문제를 보고하거나 제안을 제공합니다.

제안하기

Stack Overflow에서 커뮤니티에서 조언과 질문에 답변할 수도 있습니다.

감사합니다,

실비우안드리카

다음을 통해 공유

Azure DevOps용 관리형 DevOps 풀(미리 보기)

Azure DevOps용 GitHub Advanced Security

Azure Pipelines

Azure DevOps용 GitHub Advanced Security

고급 보안 미터 사용량 API는 이제 사용자 ID를 반환합니다.

빌드 없이 C# 및 Java 프로젝트에 대한 GitHub 고급 보안 코드 검사

Azure Pipelines

관리형 DevOps 풀(미리 보기)

Azure 파이프라인 작업은 노드 20을 사용합니다.

빌드 파이프라인 권한 만들기

스테이지 수준에서 배타적 잠금 검사

파이프라인 실행의 템플릿 정보

수동으로 트리거된 YAML 파이프라인 단계

다음 단계

피드백을 제공하는 방법

피드백

추가 리소스