환경 만들기 및 대상 지정

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

환경은 파이프라인의 배포를 사용하여 대상으로 지정할 수 있는 리소스 컬렉션입니다. 환경 이름의 일반적인 예로는 개발, 테스트, QA, 스테이징 및 프로덕션이 있습니다. Azure DevOps 환경은 파이프라인이 소프트웨어를 배포하는 논리적 대상을 나타냅니다.

Azure DevOps 환경은 클래식 파이프라인에서 사용할 수 없습니다. 클래식 파이프라인의 경우 배포 그룹은 비슷한 기능을 제공합니다.

환경은 다음과 같은 이점을 제공합니다.

장점 설명
배포 기록 파이프라인 이름 및 실행 세부 정보는 환경 및 해당 리소스에 대한 배포에 대해 기록됩니다. 동일한 환경 또는 리소스 를 대상으로 하는 여러 파이프라인의 컨텍스트에서 환경의 배포 기록은 변경 원본을 식별하는 데 유용합니다.
커밋 및 작업 항목의 추적 가능성 환경을 대상으로 하는 파이프라인 실행 내의 작업을 봅니다. 환경에 새로 배포된 커밋 및 작업 항목을수도 있습니다. 추적 기능을 사용하면 코드 변경(커밋) 또는 기능/버그 수정(작업 항목)이 환경에 도달했는지 여부를 추적할 수 있습니다.
진단 리소스 상태 애플리케이션이 원하는 상태에서 작동하는지 확인합니다.
보안 환경을 대상으로 지정할 수 있는 사용자 및 파이프라인을 지정하여 환경을 보호합니다.

환경은 리소스 그룹화이지만 리소스 자체는 실제 배포 대상을 나타냅니다. Kubernetes 리소스가상 머신 리소스 유형은 현재 지원됩니다.

YAML 파이프라인을 작성하고 존재하지 않는 환경을 참조하면 작업을 수행하는 사용자가 알려지고 권한을 할당할 수 있을 때 Azure Pipelines가 자동으로 환경을 만듭니다. Azure Pipelines에 환경을 만드는 사용자에 대한 정보(예: 외부 코드 편집기에서 YAML 업데이트)가 없는 경우 환경이 아직 없는 경우 파이프라인이 실패합니다.

필수 조건

환경 만들기

  1. 조직에 https://dev.azure.com/{yourorganization} 로그인하고 프로젝트를 선택합니다.

  2. 파이프라인>환경>만들기 환경을 선택합니다.

    Environments

  3. 환경에 대한 정보를 입력한 다음 만들기를 선택합니다. 리소스는 나중에 기존 환경에 추가할 수 있습니다.

    Screenshot of creating a new environment.

파이프라인을 사용하여 환경을 만들고 배포할 수도 있습니다. 자세한 내용은 방법 가이드참조하세요.

빈 환경을 만들고 배포 작업에서 참조할 수 있습니다. 이렇게 하면 환경에 대한 배포 기록을 기록할 수 있습니다.

배포 작업에서 환경 대상 지정

배포 작업은 순차적으로 실행할 단계의 컬렉션입니다. 다음 YAML 코드 조각과 같이 배포 작업을 사용하여 전체 환경(리소스 그룹)을 대상으로 지정할 수 있습니다. 리소스 이름이 지정되었으므로 파이프라인이 myVM 컴퓨터에서 실행됩니다.

- stage: deploy
  jobs:
  - deployment: DeployWeb
    displayName: deploy Web App
    pool:
      vmImage: 'Ubuntu-latest'
    # creates an environment if it doesn't exist
    environment: 
      name: 'smarthotel-dev'
      resourceName: myVM
      resourceType: virtualMachine
    strategy:
      runOnce:
        deploy:
          steps:
          - script: echo Hello world

배포 작업에서 환경 내의 특정 리소스를 대상으로 지정

배포 대상의 범위를 환경 내의 특정 리소스로 지정할 수 있습니다. 그런 다음 환경 내의 특정 리소스에 대한 배포 기록을 기록할 수 있습니다. 배포 작업의 단계는 배포 작업의 대상이 되는 리소스에서 서비스 연결 세부 정보를 자동으로 상속 합니다.

environment: 
  name: 'smarthotel-dev.bookings'
strategy: 
 runOnce:
   deploy:
     steps:
     - task: KubernetesManifest@0
       displayName: Deploy to Kubernetes cluster
       inputs:
         action: deploy
         namespace: $(k8sNamespace)
         manifests: $(System.ArtifactsDirectory)/manifests/*
         imagePullSecrets: $(imagePullSecret)
         containers: $(containerRegistry)/$(imageRepository):$(tag)
         # value for kubernetesServiceConnection input automatically passed down to task by environment.resource input

실행 중인 환경 세부 정보

파이프라인의 특정 실행의 배포 작업의 대상이 되는 모든 환경은 파이프라인 실행 세부 정보의 환경 탭에서 찾을 수 있습니다.

Environments in run details

AKS 프라이빗 클러스터를 사용하는 경우 환경 탭을 사용할 수 없습니다.

승인

승인 검사 사용하여 스테이지가 실행되는 시기를 수동으로 제어합니다. 승인 검사 사용하여 프로덕션 환경에 대한 배포를 제어합니다. 파이프라인의 스테이지에서 리소스를 사용하는 시기를 제어하기 위해 리소스 소유자가 검사를 사용할 수 있습니다. 환경과 같은 리소스의 소유자는 해당 리소스를 사용하는 단계를 시작하기 전에 충족해야 하는 승인 및 검사 정의할 수 있습니다.

환경에 대한 수동 승인 검사 지원합니다. 자세한 내용은 승인 참조하세요.

Creator, 관리istrator 및 사용자 역할은 승인 및 검사 관리할 수 있습니다. 읽기 권한자 역할은 승인 및 검사 관리할 수 없습니다.

배포 기록

환경 내의 배포 기록 보기는 다음과 같은 이점을 제공합니다.

  • 특정 환경을 대상으로 하는 모든 파이프라인에서 작업을 봅니다. 예를 들어 각각 자체 파이프라인이 있는 두 개의 마이크로 서비스가 동일한 환경에 배포됩니다. 배포 기록 목록은 이 환경에 영향을 주는 모든 파이프라인을 식별하는 데 도움이 되며 각 파이프라인별 배포 시퀀스를 시각화하는 데도 도움이 됩니다.

    Screenshot of deployment history listing.

  • 작업 세부 정보를 드릴다운하여 환경에 배포된 커밋 및 작업 항목 목록을 확인합니다. 커밋 및 작업 항목 목록은 배포 간의 새 항목입니다. 첫 번째 목록에는 모든 커밋이 포함되며 다음 목록에는 변경 내용만 포함됩니다. 여러 커밋이 동일한 끌어오기 요청에 연결된 경우 작업 항목 및 변경 내용 탭에 여러 결과가 표시됩니다.

    Screenshot of commits under deployment history.

  • 여러 작업 항목이 동일한 끌어오기 요청에 연결된 경우 작업 항목 탭에 여러 결과가 표시됩니다.

    Screenshot of work items under deployment history.

보안

사용자 권한

사용자 권한으로 환경을 만들고, 보고, 사용하고, 관리할 수 있는 사용자를 제어합니다. 작성자(범위: 모든 환경), Reader, User 및 관리istrator의 네 가지 역할이 있습니다. 특정 환경의 사용자 권한 패널에서 상속된 권한을 설정하고 각 환경에 대한 역할을 재정의할 수 있습니다.

  1. 권한을 부여하려는 특정 환경 으로 이동합니다.
  2. 보안을 선택하여> 설정을 봅니다.
  3. 사용자 권한>+사용자 또는 그룹 추가>를 선택한 다음 적절한 역할을 선택합니다.
역할 설명
작성자 환경 허브 보안 옵션에서 사용할 수 있는 전역 역할입니다. 이 역할의 멤버는 프로젝트에서 환경을 만들 수 있습니다. 참가자는 기본적으로 멤버로 추가됩니다. 환경이 아직 없는 경우 YAML 파이프라인을 트리거하는 데 필요합니다.
판독기 이 역할의 멤버는 환경을 볼 수 있습니다.
사용자 이 역할의 멤버는 YAML 파이프라인을 만들거나 편집할 때 환경을 사용할 수 있습니다.
관리자 이 역할의 멤버는 사용 권한을 관리하고, 환경을 만들고, 관리하고, 보고, 사용할 수 있습니다. 특정 환경의 경우 작성자는 기본적으로 관리이니스트레이터로 추가됩니다. 관리도 모든 파이프라인에 대한 환경에 대한 액세스를 열 수 있습니다.

Important

환경을 만들 때 작성자만 관리자 역할을 맡습니다.

역할 설명
작성자 환경 허브 보안 옵션에서 사용할 수 있는 전역 역할입니다. 이 역할의 멤버는 프로젝트에서 환경을 만들 수 있습니다. 참가자는 기본적으로 멤버로 추가됩니다. 환경이 아직 없는 경우 YAML 파이프라인을 트리거하는 데 필요합니다.
판독기 이 역할의 멤버는 환경을 볼 수 있습니다.
사용자 이 역할의 멤버는 YAML 파이프라인을 만들거나 편집할 때 환경을 사용할 수 있습니다.
관리자 이 역할의 멤버는 환경을 사용하는 것 외에도 환경에 대한 다른 모든 역할의 멤버 자격을 관리할 수 있습니다. 작성자는 기본적으로 멤버로 추가됩니다.

파이프라인 권한

파이프라인 사용 권한을 사용하여 환경에 배포할 모든 또는 선택한 파이프라인에 권한을 부여합니다.

  • 환경 또는 리소스에 대한 열기 액세스를 제거하려면 파이프라인 사용 권한에서 권한 제한(Restrict permission)을 선택합니다.
  • 특정 파이프라인이 환경 또는 특정 리소스에 배포되도록 허용하려면 파이프라인 목록에서 선택하고 + 선택합니다.

다음 단계

승인 및 검사 정의

FAQ

Q: 환경을 만들려고 할 때 오류 메시지가 표시되는 이유는 무엇인가요?

A: "액세스 거부됨: {User}이(가) 작업을 수행할 수 있는 권한 만들기 필요"라는 메시지가 표시되면 조직 수준 권한을 검사. 조직 설정>사용자로 이동하여 관련자 역할이 있는지 확인합니다. 관련자 역할은 환경을 만들 수 없습니다. 액세스 수준을 변경한 다음 환경을 만들 수 있는지 확인합니다. 자세한 내용은 사용자 및 권한 관리 FAQ를 참조하세요.

Q: "작업 XXXX: 환경 XXXX를 찾을 수 없습니다. 환경이 존재하지 않거나 사용 권한이 없습니다." 오류가 발생하는 이유는 무엇인가요?

A: 이러한 오류의 가능한 원인은 다음과 같습니다.

  • YAML 파이프라인을 작성하고 YAML 파일에 없는 환경을 참조하는 경우 Azure Pipelines는 경우에 따라 환경을 자동으로 만듭니다.

    • Azure Pipelines 웹 환경에서 YAML 파이프라인 만들기 마법사를 사용하고 아직 생성되지 않은 환경을 참조합니다.
    • Azure Pipelines 웹 편집기를 사용하여 YAML 파일을 업데이트하고 존재하지 않는 환경에 대한 참조를 추가한 후 파이프라인을 저장합니다.
  • 다음 흐름에서 Azure Pipelines에는 환경을 만드는 사용자에 대한 정보가 없습니다. 다른 외부 코드 편집기를 사용하여 YAML 파일을 업데이트하고, 존재하지 않는 환경에 대한 참조를 추가한 다음, 수동 또는 연속 통합 파이프라인이 트리거됩니다. 이 경우 Azure Pipelines는 사용자에 대해 알지 못합니다. 이전에는 환경의 관리자 역할에 모든 프로젝트 기여자를 추가하여 이 사례를 처리했습니다. 그러면 프로젝트의 모든 구성원이 이러한 권한을 변경하고 다른 사용자가 환경에 액세스하지 못하도록 할 수 있습니다.

  • 변수를 사용하여 환경을 만들거나 templateContext를 사용하여 템플릿에 속성을 전달할 수 있습니다. 런타임 매개 변수 는 런타임에 확장되므로 환경을 만들 때 작동하지 않습니다.

  • 관련자 액세스 수준이 있는 사용자는 관련자가 리포지토리에 액세스할 수 없으므로 환경을 만들 수 없습니다.