다음을 통해 공유


빌드, 릴리스 및 테스트에 대한 보존 정책 설정

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

보존 정책을 사용하면 실행, 릴리스 및 테스트를 시스템에 저장할 기간을 설정할 수 있습니다. 스토리지 공간을 절약하려면 이전 실행, 테스트 및 릴리스를 삭제하려고 합니다.

다음 보존 정책은 프로젝트 설정의 Azure DevOps에서 사용할 수 있습니다.

  1. 파이프라인 - 아티팩트, 기호, 첨부 파일, 실행 및 끌어오기 요청 실행을 유지할 기간을 설정합니다.
  2. 릴리스(클래식) - 빌드를 저장하고 기본 및 최대 보존 설정을 볼지 여부를 설정합니다.
  3. 테스트 - 자동화된 테스트 실행 및 수동 테스트 실행, 결과 및 첨부 파일을 유지할 기간을 설정합니다.

프로젝트 설정 보존 정책

참고 항목

온-프레미스 서버를 사용하는 경우 프로젝트의 보존 정책 기본값을 지정하고 릴리스가 영구적으로 제거될 때 지정할 수도 있습니다. 이 문서의 뒷부분에서 릴리스 보존에 대해 자세히 알아봅니다.

필수 조건

기본적으로 기여자, 빌드 관리자, 프로젝트 관리자 및 릴리스 관리자 그룹의 구성원은 보존 정책을 관리할 수 있습니다.

보존 정책을 관리하려면 다음 구독 중 하나가 있어야 합니다.

Azure Test Plans 월간 액세스를 구입하고 기본 + Test Plans 액세스 수준을 할당할 수도 있습니다. 사용자 역할별 액세스 테스트를 참조하세요.

보존 정책 구성

  1. 프로젝트에 로그인합니다.

  2. 프로젝트 설정의 기어 아이콘 설정 탭으로 이동합니다.

  3. 테스트 중인 파이프라인 또는 보존에서 릴리스 보존을 선택합니다.

    • 릴리스 보존을 선택하여 릴리스 보존 정책을 설정하고 릴리스를 삭제하거나 영구적으로 삭제할 시기를 구성합니다.
    • 보존을 선택하여 수동 및 자동화된 테스트 실행을 유지할 기간을 설정합니다.

    DevOps 2019에 대한 프로젝트 설정의 보존 설정 스크린샷

보존 정책 구성

  1. 프로젝트에 로그인합니다.

  2. 프로젝트 설정의 기어 아이콘 설정 탭으로 이동합니다.

  3. 테스트 중인 파이프라인 또는 보존에서 설정 또는 릴리스 보존을 선택합니다.

    • 설정을 선택하여 실행, 아티팩트, 기호, 첨부 파일 및 끌어오기 요청 실행에 대한 보존 정책을 구성합니다.
    • 릴리스 보존을 선택하여 릴리스 보존 정책을 설정하고 릴리스를 삭제하거나 영구적으로 삭제할 시기를 구성합니다.
    • 보존을 선택하여 수동 및 자동화된 테스트 실행을 유지할 기간을 설정합니다.

    프로젝트 설정의 보존 설정 스크린샷

Important

Azure Pipelines는 더 이상 파이프라인별 보존 정책을 지원하지 않습니다. 프로젝트 수준 보존 규칙을 사용하는 것이 좋습니다.

실행 보존 정책 설정

대부분의 경우 완료된 실행을 특정 일 수보다 오래 유지할 필요가 없습니다. 보존 정책을 사용하면 삭제하기 전에 각 실행을 유지할 일 수를 제어할 수 있습니다.

  1. 프로젝트 설정의 기어 아이콘 설정 탭으로 이동합니다.

  2. 파이프라인 섹션에서 설정을 선택합니다.

Warning

Azure DevOps는 더 이상 파이프라인별 보존 규칙을 지원하지 않습니다. YAML 및 클래식 파이프라인에 대한 보존 정책을 구성하는 유일한 방법은 위에서 설명한 프로젝트 설정을 사용하는 것입니다. 파이프라인별 보존 정책을 더 이상 구성할 수 없습니다.

각 파이프라인에 대해 유지할 최근 실행 수에 대한 설정에는 좀 더 자세한 설명이 필요합니다. 이 설정의 해석은 파이프라인에서 빌드하는 리포지토리의 유형에 따라 달라집니다.

  • Azure Repos: Azure Pipelines는 파이프라인의 기본 분기 및 리포지토리의 각 보호된 분기 대해 구성된 최신 실행 수를 유지합니다. 모든 분기 정책이 구성된 분기는 보호된 분기 간주됩니다.

    예를 들어 분기가 두 main 개 있는 리포지토리를 release고려합니다. pipeline's default branch 분기가 main 분기이고 release 분기 정책이 보호된 분기 있다고 상상해 보십시오. 이 경우 세 개의 실행을 유지하도록 정책을 구성한 경우 분기의 main 최신 3개 실행과 최신 3개의 실행 release 이 모두 유지됩니다. 또한 이 파이프라인의 최신 3개 실행(분기에 관계 없이)도 유지됩니다.

    이 논리를 더 명확히 하기 위해 이 파이프라인에 대한 실행 목록은 다음과 이며 가장 최근 실행이 맨 위에 있다고 가정해 보겠습니다. 이 표에서는 최근 3개의 실행을 유지하도록 구성한 경우 유지되는 실행을 보여 하며 일 수 설정의 효과는 무시합니다.

    달리다 # 지점 보존/보존되지 않음 이유는 무엇입니까?
    실행 10 main 보존됨 파이프라인의 경우 주 및 최신 3의 최신 3
    실행 9 branch1 보존됨 파이프라인에 대한 최신 3
    실행 8 branch2 보존됨 파이프라인에 대한 최신 3
    실행 7 main 보존됨 최신 3 for main
    실행 6 main 보존됨 최신 3 for main
    실행 5 main 보존되지 않음 main에 대한 최신 3도 아니고 파이프라인용도 아닙니다.
    실행 4 main 보존되지 않음 main에 대한 최신 3도 아니고 파이프라인용도 아닙니다.
    실행 3 branch1 보존되지 않음 main에 대한 최신 3도 아니고 파이프라인용도 아닙니다.
    실행 2 릴리스 보존됨 릴리스용 최신 3
    실행 1 main 보존되지 않음 main에 대한 최신 3도 아니고 파이프라인용도 아닙니다.
  • 다른 모든 Git 리포지토리: Azure Pipelines는 전체 파이프라인에 대해 구성된 최신 실행 수를 유지합니다.

  • TFVC: Azure Pipelines는 분기와 관계없이 전체 파이프라인에 대해 구성된 최신 실행 수를 유지합니다.

실행의 어떤 부분이 삭제되는지

실행이 삭제되면 다음 정보가 삭제됩니다.

  • 로그
  • 모든 파이프라인 및 빌드 아티팩트
  • 모든 기호
  • 바이너리
  • 검사 결과
  • 메타데이터 실행
  • 원본 레이블(TFVC) 또는 태그(Git)

유니버설 패키지, NuGet, npm 및 기타 패키지는 파이프라인 보존에 연결되지 않습니다.

실행이 삭제된 경우

보존 정책은 하루에 한 번 처리됩니다. 부하 분산을 위해 하루 종일 작업을 분산하기 때문에 정책이 처리된 변수를 가져오는 시간입니다. 이 프로세스를 변경할 수 있는 옵션은 없습니다.

다음 조건이 모두 충족되면 실행이 삭제됩니다.

  • 보존 설정에 구성된 일 수를 초과합니다.
  • 보존 설정에 구성된 최근 실행 중 하나가 아닙니다.
  • 무기한 보존되도록 표시되지 않습니다.
  • 릴리스에서 유지되지 않습니다.

파이프라인 실행에 대한 보존 임대 자동 설정

보존 임대는 구성된 보존 기간을 초과하는 파이프라인 실행의 수명을 관리하는 데 사용됩니다. 임대 API를 호출하여 파이프라인 실행에서 보존 임대를 추가하거나 삭제할 수 있습니다. 이 API는 스크립트를 사용하고 runId 및 definitionId에 미리 정의된 변수를 사용하여 파이프라인 내에서 호출할 수 있습니다 .

특정 기간 동안 파이프라인 실행에 보존 임대를 추가할 수 있습니다. 예를 들어 테스트 환경에 배포하는 파이프라인 실행은 더 짧은 기간 동안 보존될 수 있지만 프로덕션 환경에 배포하는 실행은 더 오래 유지될 수 있습니다.

파이프라인 실행에 대한 보존 임대 수동 설정

파이프라인 실행 세부 정보 페이지의 추가 작업 메뉴를 사용하여 파이프라인 실행을 유지하도록 수동으로 설정할 수 있습니다.

수동으로 실행 유지

실행 삭제

파이프라인 실행 세부 정보 페이지의 추가 작업 메뉴를 사용하여 실행을 삭제할 수 있습니다.

참고 항목

현재 실행에 보존 정책이 적용되는 경우 실행을 삭제하기 전에 제거해야 합니다. 지침은 파이프라인 실행 세부 정보 - 실행 삭제를 참조하세요.

실행 삭제

릴리스 보존 정책 설정

클래식 릴리스 파이프라인에 대한 릴리스 보존 정책은 릴리스 및 연결된 실행이 보존되는 기간을 결정합니다. 이러한 정책을 사용하면 각 릴리스가 마지막으로 수정 또는 배포된 후 유지하려는 일 수와 각 파이프라인에 대해 보존해야 하는 최소 릴리스 수를 제어할 수 있습니다.

릴리스가 수정되거나 스테이지에 배포될 때마다 릴리스의 보존 타이머가 다시 설정됩니다. 설정을 유지할 최소 릴리스 수가 일 수보다 우선합니다. 예를 들어 최소 3개의 릴리스를 유지하도록 지정하는 경우 가장 최근의 3개 릴리스는 지정된 일 수에 관계없이 무기한 유지됩니다. 그러나 더 이상 필요하지 않은 경우 이러한 릴리스를 수동으로 삭제할 수 있습니다. 릴리스 보존 작동 방식에 대한 자세한 내용은 아래 FAQ를 참조하세요.

릴리스 파이프라인의 작성자로서 보존 탭에서 파이프라인 릴리스에 대한 보존 정책을 사용자 지정할 수 있습니다.

YAML 및 빌드 파이프라인에 대한 보존 정책은 동일합니다. 설정 섹션의 파이프라인에 대한 프로젝트 설정에서 파이프라인의 보존 설정을 볼 수 있습니다.

전역 릴리스 보존 정책

온-프레미스 Team Foundation Server 또는 Azure DevOps Server를 사용하는 경우 릴리스 보존 정책 기본값과 프로젝트의 최대값을 지정할 수 있습니다. 릴리스가 영구적으로 제거되는 시기를 지정할 수도 있습니다(빌드 탐색기의 삭제된 탭에서 제거됨).

온-프레미스 릴리스 보존 설정

Azure DevOps Services를 사용하는 경우 프로젝트에 대한 이러한 설정을 볼 수 있지만 변경할 수는 없습니다.

프로젝트의 릴리스 보존 설정에서 전역 릴리스 보존 정책 설정을 검토할 수 있습니다.

  • Azure DevOps Services: https://dev.azure.com/{organization}/{project}/_settings/release?app=ms.vss-build-web.build-release-hub-group
  • 온-프레미스: https://{your_server}/tfs/{collection_name}/{project}/_admin/_apps/hub/ms.vss-releaseManagement-web.release-project-admin-hub

최대 보존 정책은 모든 릴리스 파이프라인에 대해 릴리스를 보존할 수 있는 기간에 대한 상한을 설정합니다. 릴리스 파이프라인의 작성자는 여기에 지정된 값을 초과하여 해당 정의에 대한 설정을 구성할 수 없습니다.

기본 보존 정책은 모든 릴리스 파이프라인에 대한 기본 보존 값을 설정합니다. 빌드 파이프라인 작성자는 이러한 값을 재정의할 수 있습니다.

소멸 정책을 사용하면 릴리스가 삭제된 후 일정 기간 동안 릴리스를 유지할 수 있습니다. 이 정책은 개별 릴리스 파이프라인에서 재정의할 수 없습니다.

컬렉션 수준 보존 정책 설정

온-프레미스 서버의 경우 사용자 지정 보존 규칙을 사용하여 컬렉션 수준 보존 정책을 설정할 수도 있습니다. 이러한 보존 정책은 클래식 빌드 파이프라인에 적용됩니다. 페이지의 https://{your_server}/{collection_name}/_settings/buildqueue 최대값과 기본값이 제어됩니다.

컬렉션 수준 보존 정책을 구성하는 방법을 보여 주는 스크린샷

파일 복사 작업을 사용하여 데이터를 더 오래 저장

파일 복사 작업을 사용하여 보존 정책에 설정된 것보다 오랫동안 빌드 및 아티팩트 데이터를 저장할 수 있습니다. 빌드 아티팩트 게시 태스크와 함께 저장된 데이터는 주기적으로 정리되고 삭제되므로 파일 복사 태스크를 빌드 아티팩트 게시 태스크보다 사용하는 것이 좋습니다.

- task: CopyFiles@2
  displayName: 'Copy Files to: \\mypath\storage\$(Build.BuildNumber)'
  inputs:
    SourceFolder: '$(Build.SourcesDirectory)'
    Contents: '_buildOutput/**'
    TargetFolder: '\\mypath\storage\$(Build.BuildNumber)'

FAQ

실행 또는 릴리스를 무기한 보존하도록 표시하는 경우 보존 정책이 계속 적용되나요?

아니요. 개별 실행 또는 릴리스를 무기한 보존하도록 표시할 때 파이프라인의 보존 정책이나 관리자가 설정한 최대 제한은 적용되지 않습니다. 무기한 보존을 중지할 때까지 유지됩니다.

프로덕션에 배포된 실행이 더 오래 유지되도록 지정해야 어떻게 할까요??

클래식 릴리스를 사용하여 프로덕션에 배포하는 경우 릴리스 파이프라인에서 보존 정책을 사용자 지정합니다. 프로덕션에 배포된 릴리스가 보존되어야 하는 일 수를 지정합니다. 또한 해당 릴리스와 연결된 실행이 유지되어야 함을 나타냅니다. 그러면 실행 보존 정책이 재정의됩니다.

다단계 YAML 파이프라인을 사용하여 프로덕션에 배포하는 경우 구성할 수 있는 유일한 보존 정책은 프로젝트 설정에 있습니다. 빌드가 배포된 환경에 따라 보존을 사용자 지정할 수 없습니다.

나는 무기한 유지 될 실행을 표시하지 않았다. 그러나 많은 수의 실행이 유지되는 것을 볼 수 있습니다. 이를 방지하려면 어떻게 해야 하나요?

이는 다음 이유 중 하나일 수 있습니다.

  • 실행은 프로젝트의 누군가가 무기한 보존하도록 표시합니다.
  • 실행은 릴리스에서 사용되며 릴리스는 이러한 실행에 대한 보존 잠금을 보유합니다. 위에서 설명한 대로 릴리스 보존 정책을 사용자 지정합니다.

실행이 더 이상 필요하지 않거나 릴리스가 이미 삭제된 경우 실행을 수동으로 삭제할 수 있습니다.

'유지할 최소 릴리스' 설정은 어떻게 작동하나요?

유지할 최소 릴리스는 단계 수준에서 정의됩니다. 릴리스가 보존 기간이 만료된 경우에도 Azure DevOps는 스테이지에 대해 마지막으로 배포된 릴리스의 지정된 수를 항상 유지한다는 것을 나타냅니다. 릴리스는 해당 단계에서 배포가 시작된 경우에만 스테이지에 유지하도록 최소 릴리스에서 고려됩니다. 성공적인 배포와 실패한 배포가 모두 고려됩니다. 승인 보류 중인 릴리스는 고려되지 않습니다.

보존 기간이 다른 여러 단계에 릴리스가 배포될 때 보존 기간은 어떻게 결정되나요?

최종 보존 기간은 릴리스가 배포되는 모든 단계의 설정을 유지하는 데 며칠을 고려하고 그 사이에 유지하는 데 최대 요일이 걸리는 것으로 결정됩니다. 유지할 최소 릴리스는 단계 수준에서 관리되며 여러 단계에 배포된 릴리스에 따라 변경되지 않습니다. 연결된 아티팩트 보존은 릴리스가 true로 설정된 단계에 배포될 때 적용됩니다.

이전 릴리스가 있는 단계를 삭제했습니다. 이 경우 어떤 보존이 고려되나요?

스테이지가 삭제되므로 스테이지 수준 보존 설정은 지금 적용할 수 없습니다. 이러한 경우 Azure DevOps는 프로젝트 수준 기본 보존으로 대체됩니다.

조직에서는 설정에 허용되는 것보다 더 오래 빌드 및 릴리스를 유지해야 합니다. 더 긴 보존을 요청하려면 어떻게 해야 하나요?

보존 설정을 통해 허용되는 것보다 더 오래 실행 또는 릴리스를 유지하는 유일한 방법은 무기한 보존되도록 수동으로 표시하는 것입니다. 더 긴 보존 설정을 수동으로 구성할 수 있는 방법은 없습니다. 지원을 받으려면 Azure DevOps 지원에 문의하세요.

또한 REST API를 사용하여 실행에 대한 정보 및 아티팩트 다운로드 및 사용자 고유의 스토리지 또는 아티팩트 리포지토리에 업로드할 수도 있습니다.

나는 몇 가지 실행을 잃었다. 다시 가져오는 방법이 있나요?

서비스의 버그로 인해 실행이 손실된 것으로 생각되는 경우 즉시 지원 티켓을 만들어 손실된 정보를 복구합니다. 빌드 정의가 1주일 이상 전에 수동으로 삭제된 경우 복구할 수 없습니다. 보존 정책으로 인해 실행이 예상대로 삭제된 경우 손실된 실행을 복구할 수 없습니다.

에이전트의 기능을 사용할 Build.Cleanup 어떻게 할까요? 있나요?

Build.Cleanup 에이전트에 대한 기능을 설정하면 풀의 정리 작업이 해당 에이전트로만 전달되고 나머지는 정기적인 작업을 자유롭게 수행할 수 있습니다. 파이프라인 실행이 삭제되면 Azure DevOps 외부에 저장된 아티팩트가 에이전트에서 작업 실행을 통해 정리됩니다. 정리 작업으로 에이전트 풀이 포화되면 문제가 발생할 수 있습니다. 그 해결 방법은 정리 에이전트인 풀에 있는 에이전트의 하위 집합을 지정하는 것입니다. 에이전트가 Build.Cleanup 설정된 경우 해당 에이전트만 정리 작업을 실행하므로 나머지 에이전트는 파이프라인 작업을 계속 실행할 수 있습니다. 에이전트>기능으로 이동하고 1게 설정 Build.Cleanup 하여 정리 기능을 사용하도록 설정할 수 있습니다.

빌드가 삭제될 때 파일 공유 아티팩트가 어떻게 되나요?

파일 공유 아티팩트가 있는 빌드가 삭제되면 새 빌드 작업이 빌드 에이전트에 큐에 대기하여 해당 파일을 정리합니다. 다음 기준에 따라 이 작업을 수행하기 위해 에이전트가 선택됩니다. 사용 가능한 기능이 있는 Build.Cleanup 에이전트가 있나요? 빌드를 실행한 에이전트를 사용할 수 있나요? 동일한 풀의 에이전트를 사용할 수 있나요? 비슷한 풀의 에이전트를 사용할 수 있나요? 에이전트를 사용할 수 있나요?

릴리스의 일부로 게시된 자동화된 테스트 결과는 릴리스가 삭제될 때까지 유지합니까?

릴리스 단계 내에 게시된 테스트 결과는 테스트 결과에 대해 구성된 보존 정책에 지정된 대로 유지됩니다. 테스트 결과는 릴리스가 유지될 때까지 유지되지 않습니다. 릴리스만큼 테스트 결과가 필요한 경우 프로젝트 설정에서 자동 테스트 실행에 대한 보존 설정을 [삭제 안 함]으로 설정합니다. 이렇게 하면 릴리스가 삭제될 때만 테스트 결과가 삭제됩니다.

수동 테스트 결과가 삭제되어 있나요?

아니요. 수동 테스트 결과는 삭제되지 않습니다.

버전 제어 레이블 또는 태그를 어떻게 보존하나요?

주의

빌드가 삭제되더라도 원본 작업에서 자동으로 생성되지 않는 빌드 파이프라인 중에 적용되는 버전 제어 레이블 또는 태그는 유지됩니다. 그러나 빌드 중에 원본 작업에서 자동으로 생성된 버전 제어 레이블 또는 태그는 빌드 아티팩트 일부로 간주되며 빌드가 삭제될 때 삭제됩니다.

빌드가 삭제된 경우에도 버전 제어 레이블 또는 태그를 유지해야 하는 경우 파이프라인의 작업의 일부로 적용하거나, 파이프라인 외부에서 수동으로 레이블을 지정하거나, 빌드를 무기한 보존해야 합니다.

다른 파이프라인에서 사용되는 파이프라인은 어떻게 되나요?

클래식 릴리스는 자동으로 사용하는 파이프라인을 유지합니다.

다른 파이프라인에서 사용되는 파이프라인은 어떻게 되나요?

클래식 릴리스는 자동으로 사용하는 파이프라인을 유지합니다. YAML을 사용하는 경우 릴리스를 나타내고 리소스로 다른 YAML 파이프라인을 사용하는 다단계 YAML 파이프라인을 만들 수도 있습니다. 리소스 파이프라인은 릴리스 파이프라인이 유지되는 한 자동으로 유지됩니다.