Azure DevOpsServer 2020 업데이트 1 릴리스 정보

개발자 커뮤니티 | 시스템 요구 사항 | 사용 조건 | DevOps 블로그 | SHA-1 해시

이 문서에서는 Azure DevOps Server의 최신 릴리스에 대한 정보를 찾을 수 있습니다.

Azure DevOps Server 배포를 설치하거나 업그레이드하는 방법에 대한 자세한 내용은 Azure DevOps Server 요구 사항을 참조 하세요. Azure DevOps 제품을 다운로드하려면 Azure DevOps Server 다운로드 페이지를 방문 하세요.

Azure DevOps Server 2020으로의 직접 업그레이드는 Azure DevOps Server 2019 또는 Team Foundation Server 2015 이상에서 지원됩니다. TFS 배포가 TFS 2010 이하에 있는 경우 Azure DevOps Server 2019로 업그레이드하기 전에 몇 가지 중간 단계를 수행해야 합니다. 자세한 내용은 Azure DevOps 온-프레미스 설치 및 구성을 참조하세요.

---

Azure DevOps Server 2019에서 Azure DevOps Server 2020으로 안전하게 업그레이드

Azure DevOps Server 2020에는 프로젝트 수준 설정에 따라 작동하는 새 파이프라인 실행(빌드) 보존 모델이 도입되었습니다.

Azure DevOps Server 2020은 파이프라인 수준 보존 정책에 따라 빌드 보존을 다르게 처리합니다. 특정 정책 구성으로 인해 업그레이드 후 파이프라인 실행이 삭제됩니다. 수동으로 보존되었거나 릴리스에 의해 유지된 파이프라인 실행은 업그레이드 후에 삭제되지 않습니다.

Azure DevOps Server 2019에서 Azure DevOps Server 2020으로 안전하게 업그레이드하는 방법에 대한 자세한 내용은 블로그 게시물을 참조하세요.

Azure DevOps Server 2020 업데이트 1.2 패치 14 릴리스 날짜: 2024년 11월 12일

파일	SHA-256 해시
devops2020.1.2patch14.exe	89AF4B1FCA1E2BD813A42F0D3E568E64AB470E5FD0A2F87F9E4894B8CA361420

취약한 종속성으로의 업그레이드를 포함하도록 Azure DevOps Server 2020 업데이트 1.2용 패치 14를 릴리스했습니다.

Azure DevOps Server 2020 업데이트 1.2 패치 13 릴리스 날짜: 2024년 3월 12일

파일	SHA-256 해시
devops2020.1.2patch13.exe	55B0A30EABD66EB22AA6093B7750EF3CFE79423018E304503CE728158F56F6

다음의 수정 사항을 포함하는 Azure DevOps Server 2020 업데이트 1.2용 패치 13을 릴리스했습니다.

• 패치 12를 설치한 후 프록시 서버의 작동이 중지되는 문제를 해결했습니다.

Azure DevOps Server 2020 업데이트 1.2 패치 12 릴리스 날짜: 2024년 2월 13일

파일	SHA-256 해시
devops2020.1.2patch12.exe	C4C9EEBBDD3B07C36658C9F78AEA57A980AA633F99DF2A3AD5036F957F095E53

다음의 수정 사항을 포함하는 Azure DevOps Server 2020 업데이트 1.2용 패치 12를 릴리스했습니다.

• 프록시 캐시 폴더에서 사용하는 디스크 공간이 잘못 계산되고 폴더가 제대로 정리되지 않은 버그가 수정되었습니다.
• CVE-2024-20667: Azure DevOps Server 원격 코드 실행 취약성.

Azure DevOps Server 2020 업데이트 1.2 패치 11 릴리스 날짜: 2023년 12월 12일

파일	SHA-256 해시
devops2020.1.2patch11.exe	C47B9C898C2E08527F1DDC3E7A5E67F1A11C3AFF860DE9B5FF3DD8718C3AAE87

다음의 수정 사항을 포함하는 Azure DevOps Server 2020 업데이트 1.2용 패치 11을 릴리스했습니다.

• 파이프라인 단계에서 배포 전 승인 보안 상속이 작동하지 않는 버그가 수정되었습니다.

Azure DevOps Server 2020 업데이트 1.2 패치 10 릴리스 날짜: 2023년 11월 14일

다음에 대한 수정 사항을 포함하는 Azure DevOps Server 2020 업데이트 1.2에 대한 패치를 릴리스했습니다.

• 셸 작업 사용 인수 매개 변수 유효성 검사에 대해 PowerShell 작업 허용 문자 목록을 확장했습니다.

참고 항목

이 패치에 대한 수정 사항을 구현하려면 여러 단계에 따라 작업을 수동으로 업데이트해야 합니다.

패치 설치

Important

2023년 9월 12일에 패치 8이 릴리스된 Azure Pipelines 에이전트에 대한 업데이트를 릴리스했습니다. 패치 8의 릴리스 정보에 설명된 대로 에이전트 업데이트를 설치하지 않은 경우 패치 10을 설치하기 전에 이러한 업데이트를 설치하는 것이 좋습니다. 패치 8을 설치한 후 에이전트의 새 버전은 3.225.0이 됩니다.

TFX 구성

1. 프로젝트 컬렉션 설명서에 업로드 작업의 단계에 따라 tfx-cli를 설치하고 로그인합니다.

TFX를 사용하여 작업 업데이트

파일	SHA-256 해시
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

1. Tasks20231103.zip 다운로드하고 추출합니다.
2. 디렉터리를 추출된 파일로 변경합니다.
3. 다음 명령을 실행하여 작업을 업로드합니다.

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip 

파이프라인 요구 사항

새 동작을 사용하려면 영향을 받는 작업을 사용하는 파이프라인에서 변수 AZP_75787_ENABLE_NEW_LOGIC = true 를 설정해야 합니다.

• 클래식:

  파이프라인의 변수 탭에서 변수를 정의합니다.

• YAML 예제:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 업데이트 1.2 패치 9 릴리스 날짜: 2023년 10월 10일

Important

2023년 9월 12일에 패치 8이 릴리스된 Azure Pipelines 에이전트에 대한 업데이트를 릴리스했습니다. 패치 8의 릴리스 정보에 설명된 대로 에이전트 업데이트를 설치하지 않은 경우 패치 9를 설치하기 전에 이러한 업데이트를 설치하는 것이 좋습니다. 패치 8을 설치한 후 에이전트의 새 버전은 3.225.0이 됩니다.

패치를 릴리스했습니다. Azure DevOps Server 2020 업데이트 1.2의 경우 다음과 같은 수정 사항이 포함되어 있습니다.

• 패치 업그레이드 컴퓨터에서 "분석 소유자" ID가 비활성 ID로 표시되는 버그가 수정되었습니다.

Azure DevOps Server 2020 업데이트 1.2 패치 8 릴리스 날짜: 2023년 9월 12일

다음에 대한 수정 사항을 포함하는 Azure DevOps Server 2020 업데이트 1.2에 대한 패치를 릴리스했습니다.

• CVE-2023-33136: Azure DevOps Server 원격 코드 실행 취약성.
• CVE-2023-38155: Azure DevOps Server 및 Team Foundation Server 권한 상승 취약성.

Important

테스트 환경에 패치를 배포하고 프로덕션 환경에 수정 사항을 적용하기 전에 환경의 파이프라인이 예상대로 작동하는지 확인하세요.

참고 항목

이 패치에 대한 수정 사항을 구현하려면 에이전트 및 작업을 수동으로 업데이트하는 여러 단계를 따라야 합니다.

패치 설치

1. Azure DevOps Server 2020 업데이트 1.2 패치 8을 다운로드하여 설치합니다.

Azure Pipelines 에이전트 업데이트

1. 에이전트 다운로드: https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 - Agent_20230825.zip
2. 자체 호스팅 Windows 에이전트 설명서에 설명된 단계를 사용하여 에이전트를 배포합니다.  

참고 항목

에이전트가 다운그레이드되지 않도록 하려면 AZP_AGENT_DOWNGRADE_DISABLED "true"로 설정해야 합니다. Windows에서는 관리 명령 프롬프트에서 다음 명령을 사용하고 다시 부팅할 수 있습니다. setx AZP_AGENT_DOWNGRADE_DISABLED true /M

TFX 구성

1. 프로젝트 컬렉션 설명서에 업로드 작업의 단계에 따라 tfx-cli를 설치하고 로그인합니다.

TFX를 사용하여 작업 업데이트

1. Tasks_20230825.zip 다운로드하고 추출합니다.
2. 디렉터리를 추출된 파일로 변경합니다.
3. 다음 명령을 실행하여 작업을 업로드합니다.

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.226.3.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.226.2.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.226.1.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.226.2.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.226.2.zip 

파이프라인 요구 사항

새 동작을 사용하려면 영향을 받는 작업을 사용하는 파이프라인에서 변수 AZP_75787_ENABLE_NEW_LOGIC = true 를 설정해야 합니다.

• 클래식:

  파이프라인의 변수 탭에서 변수를 정의합니다.

• YAML 예제:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 업데이트 1.2 패치 7 릴리스 날짜: 2023년 8월 8일

다음에 대한 수정 사항을 포함하는 Azure DevOps Server 2020 업데이트 1.2에 대한 패치를 릴리스했습니다.

• CVE-2023-36869: Azure DevOps Server 스푸핑 취약성.
• SHA2-256 및 SHA2-512를 지원하도록 SSH 서비스를 업데이트합니다. RSA를 사용하도록 하드 코딩된 SSH 구성 파일이 있는 경우 SHA2로 업데이트하거나 항목을 제거해야 합니다.
• markdown 파일에서 상대 링크가 작동하지 않는 문제를 해결했습니다.
• 커밋 페이지에서 메모 탐색이 포함된 버그가 수정되었습니다.
• 분석 소유자 ID가 비활성 ID로 표시되는 버그가 수정되었습니다.
• CronScheduleJobExtension에서 무한 루프 버그가 수정되었습니다.

Azure DevOps Server 2020 업데이트 1.2 패치 6 릴리스 날짜: 2023년 6월 13일

다음에 대한 수정 사항을 포함하는 Azure DevOps Server 2020 업데이트 1.2에 대한 패치를 릴리스했습니다.

• CVE-2023-21565: Azure DevOps Server 스푸핑 취약성.
• CVE-2023-21569: Azure DevOps Server 스푸핑 취약성.
• 2018년 이전 버전에서 업그레이드할 때 패키지 푸시를 방해하는 버그가 수정되었습니다.
• 분리 또는 연결 컬렉션이 다음 오류를 보고하지 못하는 버그를 수정했습니다. 'TF246018: 데이터베이스 작업이 제한 시간을 초과하여 취소되었습니다.

Azure DevOps Server 2020 업데이트 1.2 패치 5 릴리스 날짜: 2023년 2월 14일

다음에 대한 수정 사항을 포함하는 Azure DevOps Server 2020 업데이트 1.2에 대한 패치를 릴리스했습니다.

• CVE-2023-21553: Azure DevOps Server 원격 코드 실행 취약성
• 웹 UI를 통한 선반 접근성 문제 해결
• 고객은 Azure DevOps Server 관리 콘솔에서 SMTP 관련 설정을 업데이트한 후 tfsjobagent 서비스 및 Azure DevOps Server 애플리케이션 풀을 다시 시작해야 합니다.

Azure DevOps Server 2020 업데이트 1.2 패치 4 릴리스 날짜: 2022년 12월 13일

다음에 대한 수정 사항을 포함하는 Azure DevOps Server 2020 업데이트 1.2에 대한 패치를 릴리스했습니다.

• IdentityPicker에서 특수 문자 표시가 수정되었습니다.

• 테스트 데이터가 삭제되지 않아 데이터베이스가 증가했습니다. 이 수정을 통해 새 분리된 테스트 데이터를 만들지 못하도록 빌드 보존을 업데이트했습니다.

Azure DevOps Server 2020 업데이트 1.2 패치 3 릴리스 날짜: 2022년 10월 18일

다음에 대한 수정 사항을 포함하는 Azure DevOps Server 2020 업데이트 1.2에 대한 패치를 릴리스했습니다.

• 새로 추가된 AD ID가 보안 대화 상자 ID 선택기에서 표시되지 않는 문제를 해결합니다.
• 웹 후크 설정에서 그룹 구성원이 요청한 필터 문제를 해결합니다.
• 파이프라인에 대한 조직 설정에 작업 권한 부여 범위가 릴리스가 아닌 파이프라인에 대한 현재 프로젝트로 작업 권한 부여 범위 제한으로 구성된 경우 제어된 체크 인 빌드 오류를 수정합니다.
• 인증된 프록시 뒤에 서비스 연결을 설정할 때 Azure에서 액세스 토큰 검색을 수정합니다.

Azure DevOps Server 2020 업데이트 1.2 패치 2 릴리스 날짜: 2022년 8월 9일

다음에 대한 수정 사항을 포함하는 Azure DevOps Server 2020 업데이트 1.2에 대한 패치를 릴리스했습니다.

• 다른 도메인에 표시되는 ID에 작업 항목을 할당하는 동안 ID 값 오류를 수정합니다.

Azure DevOps Server 2020 업데이트 1.2 패치 1 릴리스 날짜: 2022년 7월 12일

다음에 대한 수정 사항을 포함하는 Azure DevOps Server 2020 업데이트 1.2에 대한 패치를 릴리스했습니다.

• 테스트 실행 API에서 반환되는 연속 토큰이 지정된 "maxLastUpdatedDate" 값보다 큽니다.

Azure DevOps Server 2020 업데이트 1.2 릴리스 날짜: 2022년 5월 17일

Azure DevOps Server 2020 업데이트 1.2 는 버그 수정의 롤업입니다. Azure DevOps Server 2020 업데이트 1.2를 직접 설치하거나 Azure DevOps Server 2020 또는 Team Foundation Server 2013 이상에서 업그레이드할 수 있습니다.

참고 항목

데이터 마이그레이션 도구는 이 릴리스 후 약 3주 후에 Azure DevOps Server 2020 업데이트 1.2에 사용할 수 있습니다. 현재 가져오기에 지원되는 버전 목록은 여기서 볼 수 있습니다.

이 릴리스에는 다음에 대한 수정 사항이 포함되어 있습니다.

• Azure DevOps Server 2020.1.2는 파이프라인 실행(빌드)의 손실을 방지하기 위해 새 보존 모델(Azure DevOps Server 2020에 도입됨)을 사용하지 않도록 설정합니다. 즉, 시스템은 다음을 수행합니다.

  • Server 2020을 실행하는 동안 생성된 최신 3개 빌드에 대한 임대 만들기
  • 파이프라인별 보존 정책이 없는 YAML 파이프라인 및 클래식 파이프라인의 경우 컬렉션 수준 최대 보존 설정에 따라 빌드가 유지됩니다.
  • 사용자 지정 파이프라인별 보존 정책을 사용하는 클래식 파이프라인의 경우 파이프라인별 보존 정책에 따라 빌드가 유지됩니다.
  • 임대가 있는 빌드는 설정을 유지하기 위해 최소값으로 계산되지 않습니다.

• 변경 집합 및 선반 메모 링크가 제대로 리디렉션되지 않았습니다. 변경 집합 또는 선반의 파일에 주석이 추가되었을 때 해당 주석을 선택하면 파일 보기의 올바른 위치로 리디렉션되지 않았습니다.

• "다음 실행" 단추를 사용하여 빌드 큐를 건너뛸 수 없습니다. 이전에는 프로젝트 컬렉션 관리자만 "다음 실행" 단추를 사용하도록 설정했습니다.

• 사용자의 Active Directory 계정을 사용하지 않도록 설정한 후 모든 개인용 액세스 토큰을 해지합니다.

Azure DevOps Server 2020.1.1 패치 4 릴리스 날짜: 2022년 1월 26일

다음에 대한 수정 사항이 포함된 Azure DevOps Server 2020.1.1에 대한 패치를 릴리스했습니다.

• 작업 항목에서 컨트롤을 사용할 때 전자 메일 알림이 @mention 전송되지 않았습니다.
• 사용자 프로필에서 기본 메일 주소가 업데이트되지 않았습니다. 이로 인해 메일이 이전 메일 주소로 전송되었습니다.
• 프로젝트 요약 페이지에 머리글이 표시되지 않았습니다. 헤더는 몇 밀리초 동안 표시되었고 사라졌습니다.
• Active Directory 사용자 동기화 개선.
• log4j 이진 파일에서 jndilookup 클래스를 제거하여 Elasticsearch 취약성을 해결했습니다.

설치 단계

1. 패치 4를 사용하여 서버를 업그레이드합니다.
2. HKLM:\Software\Elasticsearch\Version의 레지스트리 값을 확인합니다. 여기에 레지스트리 값이 없으면 문자열 값을 추가하고 버전을 5.4.1로 설정합니다(Name = Version, Value = 5.4.1).
3. 추가 정보 파일에 안내된 대로 업데이트 명령 PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update를 실행합니다. 다음과 같은 경고를 반환할 수 있습니다. 원격 서버에 연결할 수 없습니다. 업데이트가 완료될 때까지 다시 시도되므로 창을 닫지 마세요.

참고 항목

Azure DevOps Server 및 Elasticsearch가 다른 컴퓨터에 설치되어 있는 경우 아래에 설명된 단계를 수행합니다.

1. 패치 4를 사용하여 서버를 업그레이드합니다.
2. HKLM:\Software\Elasticsearch\Version의 레지스트리 값을 확인합니다. 여기에 레지스트리 값이 없으면 문자열 값을 추가하고 버전을 5.4.1로 설정합니다(Name = Version, Value = 5.4.1).
3. Elasticsearch 원격 파일 폴더에 C:\Program Files\{TFS Version Folder}\Search\zip 있는 zip 폴더의 내용을 복사합니다.
4. Elasticsearch 서버 컴퓨터에서 실행 Configure-TFSSearch.ps1 -Operation update 합니다.

SHA-256 해시: 451F0BB73132EFCD2B3D2922F0040DBF2BCF2808C35D3C37CA5A3CD8F65F29D6

Azure DevOps Server 2020.1.1 패치 3 릴리스 날짜: 2021년 12월 15일

Azure DevOps Server 2020.1.1용 패치 3 에는 다음에 대한 수정 사항이 포함되어 있습니다.

• "단어 포함"을 사용하여 쿼리에 대한 작업 항목 매크로를 수정합니다. 이전에는 쿼리가 줄 바꿈이 포함된 값에 대해 잘못된 결과를 반환했습니다.
• Maven 패키지 버전 문자 길이에 대한 제한을 늘입니다.
• 사용자 지정 작업 항목 레이아웃 상태에 대한 지역화 문제입니다.
• 전자 메일 알림 템플릿의 지역화 문제입니다.
• 필드에 대해 여러 NOTSAMEAS 규칙이 정의된 경우 NOTSAMEAS 규칙 평가와 관련된 문제입니다.

Azure DevOps Server 2020.1.1 패치 2 릴리스 날짜: 2021년 10월 26일

Azure DevOps Server 2020.1.1 용 패치 2에는 다음에 대한 수정 사항이 포함되어 있습니다.

• 이전에는 Azure DevOps Server에서 GitHub Enterprise Server에 대한 연결만 만들 수 있습니다. 이 패치를 사용하면 프로젝트 관리자가 Azure DevOps Server와 GitHub.com 리포지토리 간에 연결을 만들 수 있습니다. 이 설정은 프로젝트 설정 아래의 GitHub 연결 페이지에서 찾을 수 있습니다.
• 테스트 계획 위젯 관련 문제를 해결합니다. 테스트 실행 보고서에 결과에 대한 잘못된 사용자가 표시되었습니다.
• 프로젝트 개요 요약 페이지가 로드에 실패하는 문제를 해결합니다.
• 제품 업그레이드를 확인하기 위해 전자 메일이 전송되지 않는 문제를 해결합니다.

Azure DevOps Server 2020.1.1 패치 1 릴리스 날짜: 2021년 9월 14일

Azure DevOps Server 2020.1.1용 패치 1에는 다음에 대한 수정 사항이 포함되어 있습니다.

• 아티팩트 다운로드/업로드 오류를 수정합니다.
• 일관성 없는 테스트 결과 데이터 문제를 해결합니다.

Azure DevOps Server 2020 업데이트 1.1 릴리스 날짜: 2021년 8월 17일

Azure DevOps Server 2020 업데이트 1.1 은 버그 수정의 롤업입니다. Azure DevOps Server 2020 업데이트 1.1을 직접 설치하거나 Azure DevOps Server 2020 또는 Team Foundation Server 2013 이상에서 업그레이드할 수 있습니다.

참고 항목

데이터 마이그레이션 도구는 이 릴리스 후 약 3주 후에 Azure DevOps Server 2020 업데이트 1.1에 사용할 수 있습니다. 현재 가져오기에 지원되는 버전 목록은 여기서 볼 수 있습니다.

이 릴리스에는 다음과 같은 버그에 대한 수정 사항이 포함되어 있습니다.

Azure Boards

• 알림 전자 메일의 "작업 항목 보기" 하이퍼링크는 공용 URL을 사용하지 않습니다.

Azure Repos

• 리포지토리 간 정책을 설정한 후 제한 병합 형식을 수정할 수 있도록 제한된 병합 형식 상속 확인란 표시가 수정되었습니다.

Azure Pipelines

• 에이전트 업데이트 설정을 변경할 때 설정이 환경의 다른 애플리케이션 계층으로 전파되지 않았습니다.

일반

• 서버 구성 마법사에서 맞춤법이 수정되었습니다.
• 확장 패키지 크기가 증가하여 레지스트리의 크기를 변경할 수 있습니다.

Azure Test Plans

• 기록에서 요약 페이지로 다시 적중하면 테스트 결과를 다시 탐색할 수 없습니다.

---

Azure DevOps Server 2020.1 패치 2 릴리스 날짜: 2021년 8월 10일

다음을 수정하는 Azure DevOps Server 2020.1에 대한 패치 를 릴리스했습니다.

• 빌드 정의 UI 오류를 수정합니다.
• 루트 리포지토리 대신 파일을 표시하도록 검색 기록이 변경되었습니다.

Azure DevOps Server 2020.1 패치 1 릴리스 날짜: 2021년 6월 15일

다음을 수정하는 Azure DevOps Server 2020.1에 대한 패치 를 릴리스했습니다.

• 어설션 SameSite=None하는 권한 부여 흐름에 사용되는 보안 쿠키입니다.

• 알림 SDK 관련 문제를 해결합니다. 이전에는 영역 경로 필터를 사용하는 알림 구독이 올바르게 구문 분석되지 않았습니다.

Azure DevOps Server 2020.1 RTW 릴리스 날짜: 2021년 5월 25일

Azure DevOps Server 2020.1 RTW의 새로운 기능 요약

Azure DevOps Server 2020.1 RTW는 버그 수정의 롤업입니다. 여기에는 이전에 릴리스된 Azure DevOps Server 2020.1 RC2의 모든 기능이 포함됩니다. Azure DevOps Server 2020.1 RTW 는 버그 수정의 롤업입니다. Azure DevOps Server 2020.1을 직접 설치하거나 Azure DevOps Server 2020, 2019 또는 Team Foundation Server 2015 이상에서 업그레이드할 수 있습니다.

참고 항목

데이터 마이그레이션 도구는 이 릴리스 후 약 3주 후에 Azure DevOps Server 2020 업데이트 1에 사용할 수 있습니다. 현재 가져오기에 지원되는 버전 목록은 여기서 볼 수 있습니다.

Azure DevOps Server 2020.1 RC2 릴리스 날짜: 2021년 4월 13일

Azure DevOps Server 2020.1 RC2의 새로운 기능 요약

Azure DevOps Server 2020.1 RC2는 버그 수정의 롤업입니다. 여기에는 이전에 릴리스된 Azure DevOps Server 2020.1 RC1의 모든 기능이 포함됩니다.

Azure DevOps Server 2020.1 RC1 릴리스 날짜: 2021년 3월 23일

Azure DevOps Server 2020.1 RC1의 새로운 기능 요약

Azure DevOps Server 2020.1 RC1에는 많은 새로운 기능이 도입되었습니다. 몇 가지 중요한 기능은 다음과 같습니다.

• 보드의 상태 전환 제한 규칙
• 이제 이해 관계자가 보드 열 간에 작업 항목을 이동할 수 있습니다.
• 액세스 토큰의 범위를 제한하여 릴리스 보안 개선
• 향상된 끌어오기 요청 환경
• 파이프라인의 다중 리포지토리 트리거

개별 섹션으로 이동하여 각 서비스에 대한 모든 새로운 기능을 확인할 수도 있습니다.

• Boards
• Repos
• 파이프라인
• 아티팩트

---

Boards

상태 전환 제한 규칙

호스트된 XML과 상속된 프로세스 모델 간의 기능 패리티 간격을 계속 닫습니다. 이 새로운 작업 항목 유형 규칙을 사용하면 작업 항목이 한 상태에서 다른 상태로 이동되지 않도록 제한할 수 있습니다. 예를 들어 버그가 새로 만들기에서 해결됨으로 전환되지 않도록 제한할 수 있습니다. 대신 새로 만들기 - 활성 ->> 해결됨에서 이동해야 합니다.

그룹 멤버 자격으로 상태 전환을 제한하는 규칙을 만들 수도 있습니다. 예를 들어 "승인자" 그룹의 사용자만 New -> Approved에서 사용자 스토리를 이동할 수 있습니다.

작업 항목을 복사하여 자식 복사

Azure Boards에서 가장 많이 요청한 기능 중 하나는 자식 작업 항목도 복사하는 작업 항목을 복사하는 기능입니다. 작업 항목 복사 대화 상자에 "자식 작업 항목 포함"에 대한 새 옵션을 추가했습니다. 이 옵션을 선택하면 작업 항목을 복사하고 모든 자식 작업 항목(최대 100개)을 복사합니다.

활성화 및 해결된 필드에 대한 향상된 규칙

지금까지 활성화된 날짜, 활성화된 날짜, 해결한 날짜 및 해결된 날짜에 대한 규칙은 미스터리였습니다. 시스템 작업 항목 유형에 대해서만 설정되며 "활성" 및 "해결됨"의 상태 값과 관련이 있습니다. 이러한 규칙이 더 이상 특정 상태에 대한 것이 아니도록 논리를 변경했습니다. 대신 상태가 상주하는 범주(상태 범주)에 의해 트리거됩니다. 예를 들어 해결된 범주에 "테스트 필요"라는 사용자 지정 상태가 있다고 가정해 보겠습니다. 작업 항목이 "활성"에서 "테스트 필요" 로 변경되면 해결된 날짜 및 확인된 날짜 규칙이 트리거됩니다.

이를 통해 고객은 사용자 지정 규칙을 사용할 필요 없이 사용자 지정 상태 값을 만들고 활성화된 날짜, 정품 인증 날짜, 해결된 날짜 및 해결된 날짜 필드를 계속 생성할 수 있습니다.

관련자는 보드 열 간에 작업 항목을 이동할 수 있습니다.

관련자는 항상 작업 항목의 상태를 변경할 수 있었습니다. 그러나 Kanban 보드로 이동하면 작업 항목을 한 열에서 다른 열로 이동할 수 없습니다. 대신 관련자는 각 작업 항목을 한 번에 하나씩 열고 상태 값을 업데이트해야 합니다. 이것은 오랫동안 고객에게 고통 포인트가되어 왔으며, 이제 보드 열 간에 작업 항목을 이동할 수 있음을 발표하게되어 기쁩니다.

백로그 및 보드의 시스템 작업 항목 형식

이제 선택한 백로그 수준에 시스템 작업 항목 유형을 추가할 수 있습니다. 지금까지 이러한 작업 항목 유형은 쿼리에서만 사용할 수 있었습니다.

Process	작업 항목 형식
애자일.	문제
스크럼	장애
CMMI	변경 요청
	문제
	검토
	위험

백로그 수준에 시스템 작업 항목 유형을 추가하는 것은 간단합니다. 사용자 지정 프로세스로 이동하여 백로그 수준 탭을 클릭합니다. 선택한 백로그 수준(예: 요구 사항 백로그)을 선택하고 편집 옵션을 선택합니다. 그런 다음 작업 항목 유형을 추가합니다.

Azure Boards GitHub 앱 리포지토리 제한 발생

GitHub Marketplace의 Azure Boards 애플리케이션 에 대한 리포지토리 제한이 100에서 250으로 증가했습니다.

끌어오기 요청이 병합될 때 작업 항목 상태 사용자 지정

모든 워크플로가 동일한 것은 아닙니다. 일부 고객은 끌어오기 요청이 완료되면 관련 작업 항목을 닫고자 합니다. 다른 사용자는 작업 항목을 닫기 전에 유효성을 검사할 다른 상태로 설정하려고 합니다. 우리는 둘 다 허용해야합니다.

끌어오기 요청이 병합되고 완료될 때 작업 항목을 원하는 상태로 설정할 수 있는 새로운 기능이 있습니다. 이렇게 하려면 끌어오기 요청 설명을 검색하고 작업 항목의 #mention 뒤에 오는 상태 값을 찾습니다. 이 예제에서는 두 개의 사용자 스토리를 해결됨으로 설정하고 두 작업을 닫습니다.

다른 프로젝트의 빌드에 작업 항목 연결

이제 작업 항목을 빌드, 빌드에서 찾거나 빌드에서 통합된 항목에 연결하여 프로젝트 전체에서 빌드 종속성을 쉽게 추적할 수 있습니다.

시스템 필드에 대한 설명(도움말 텍스트) 편집

항상 사용자 지정 필드에 대한 설명을 편집할 수 있었습니다. 그러나 우선 순위, 심각도 및 활동과 같은 시스템 필드의 경우 설명을 편집할 수 없습니다. 이는 일부 고객이 상속된 모델로 마이그레이션하지 못하게 하는 Hosted XML과 Inherited 간의 기능 차이였습니다. 이제 시스템 필드에 대한 설명을 편집할 수 있습니다. 편집된 값은 프로세스 및 해당 작업 항목 형식의 해당 필드에만 영향을 미칩니다. 이렇게 하면 여러 작업 항목 유형에서 동일한 필드에 대해 서로 다른 설명을 유연하게 사용할 수 있습니다.

끌어오기 요청이 병합될 때 작업 항목 상태 사용자 지정

끌어오기 요청은 종종 여러 작업 항목을 참조합니다. 끌어오기 요청을 만들거나 업데이트할 때 그 중 일부를 닫고, 그 중 일부를 해결하고, 나머지는 열어 둘 수 있습니다. 이제 아래 그림에 표시된 메모와 같은 주석을 사용하여 이를 수행할 수 있습니다. 자세한 내용은 설명서를 참조하세요.

작업 보드의 부모 필드

인기 있는 요청으로 인해 이제 작업 보드의 자식 카드와 부모 카드 모두에 부모 필드를 추가할 수 있습니다.

버그 작업 항목 유형에서 "할당 대상" 규칙 제거

Agile, 스크럼 및 CMMI의 다양한 작업 항목 유형에는 여러 가지 숨겨진 시스템 규칙이 있습니다. 이러한 규칙은 10 년 이상 존재했으며 일반적으로 불만없이 잘 작동했습니다. 그러나, 그들의 환영 밖으로 실행 하는 규칙의 몇 가지가 있다. 특히 한 가지 규칙은 신규 및 기존 고객에게 많은 고통을 일으켰으며 우리는 그것을 제거할 때라고 결정했습니다. 이 규칙은 Agile 프로세스의 버그 작업 항목 유형에 있습니다.

"상태가 해결됨으로 변경될 때 할당된 값을 만든 사람으로 설정"

이 규칙에 대한 많은 피드백을 받았습니다. 이에 대한 응답으로 Agile 프로세스의 버그 작업 항목 유형에서 이 규칙을 제거했습니다. 이 변경 내용은 상속된 Agile 또는 사용자 지정된 상속된 Agile 프로세스를 사용하는 모든 프로젝트에 영향을 미칩니다. 이 현재 규칙을 좋아하고 사용하는 고객의 경우 사용자 지정 규칙을 사용하여 규칙을 다시 추가하기 위해 수행할 수 있는 단계에 대한 블로그 게시물을 참조하세요.

작업 항목 페이지에서 제거된 항목

작업 항목 페이지는 사용자가 만들었거나 할당된 항목을 빠르게 찾을 수 있는 좋은 장소입니다. 여러 개인 설정된 피벗 및 필터를 제공합니다. "나에게 할당됨" 피벗에 대한 가장 큰 불만 중 하나는 제거된 작업 항목(즉, 제거됨 상태의 작업 항목)을 표시한다는 것입니다. 그리고 우리는 동의합니다! 제거된 항목은 더 이상 값이 없는 작업이므로 백로그에서 제거되었으므로 이 보기에 포함하면 도움이 되지 않습니다.

이제 작업 항목 페이지의 내 할당 피벗에서 제거된 모든 항목을 숨길 수 있습니다.

리포지토리

기본 분기 이름 기본 설정

이제 Azure Repos는 Git에 대해 사용자 지정 가능한 기본 분기 이름을 제공합니다. 리포지토리 설정에서 리포지토리가 초기화될 때 사용할 법적 분기 이름을 선택할 수 있습니다. Azure Repos는 항상 기존 리포지토리의 기본 분기 이름 변경을 지원합니다.

자세한 내용은 분기 관리 및 기본 분기 변경을 참조하세요.

기본 분기에 대한 조직 수준 설정

이제 새 리포지토리의 기본 설정 초기 분기 이름에 대한 컬렉션 수준 설정이 있습니다. 프로젝트에서 초기 분기 이름을 선택하지 않은 경우 이 조직 수준 설정이 사용됩니다. 조직 설정 또는 프로젝트 설정에서 초기 분기 이름을 지정하지 않은 경우 새 리포지토리는 Azure DevOps 정의 기본값을 사용합니다.

PR 주석에 기여하기 위한 새 인증 범위 추가

이 릴리스에서는 끌어오기 요청 주석 읽기/쓰기를 위한 새 OAuth 범위를 추가합니다. 주석과만 상호 작용해야 하는 봇 또는 자동화가 있는 경우 이 범위로만 PAT를 제공할 수 있습니다. 이 프로세스는 자동화에 버그가 있거나 토큰이 손상된 경우 폭발 반경을 줄입니다.

끌어오기 요청 환경 개선

다음과 같이 새 끌어오기 요청 환경이 개선되었습니다.

• 선택적 검사를 더 잘 표시

고객은 선택적 검사를 사용하여 잠재적인 문제에 대한 개발자의 관심을 끌 수 있습니다. 이전 환경에서는 이러한 검사가 실패할 때 분명하게 표시되었습니다. 그러나 미리 보기 환경에서는 그렇지 않습니다. 필요한 검사의 크고 녹색 확인 표시는 선택적 검사에서 오류를 마스킹합니다. 사용자는 검사 패널을 열어 선택적 검사가 실패했음을 검색할 수 있습니다. 개발자는 문제의 징후가 없을 때 자주 그렇게 하지 않습니다. 이 배포에서는 선택적 검사의 상태를 요약에 더 잘 표시했습니다.

• 메뉴 항목에서 Ctrl 키를 누른 채 클릭

PR의 탭 메뉴가 Ctrl 클릭을 지원하지 않습니다. 사용자는 끌어오기 요청을 검토할 때 새 브라우저 탭을 여는 경우가 많습니다. 이 문제가 해결되었습니다.

• [+] 주석의 위치

PR의 파일 트리 목록에는 작성자와 검토자가 새 파일을 식별하는 데 도움이 되는 주석 [+]이 표시됩니다. 주석은 줄임표 이후이므로 더 긴 파일 이름에 표시되지 않는 경우가 많습니다.

• PR 업데이트 드롭다운 다시 타이밍 정보

PR에서 업데이트 및 비교 파일을 선택하는 드롭다운에서 미리 보기 환경에서 중요한 요소가 손실되었습니다. 해당 업데이트가 언제 이루어졌는가는 표시되지 않았습니다. 이 문제가 해결되었습니다.

• **향상된 주석 필터 레이아웃 **

끌어오기 요청의 요약 페이지에서 주석을 필터링할 때 드롭다운이 오른쪽에 있었지만 텍스트가 왼쪽 맞춤되었습니다. 이 문제가 해결되었습니다.

• 부모 커밋 탐색

커밋 페이지에서 특정 커밋의 변경 내용을 부모 커밋과 비교할 수 있습니다. 그러나 부모 커밋으로 이동하여 해당 커밋이 자체 부모와 어떻게 다른지 더 잘 이해할 수 있습니다. 이는 릴리스의 모든 변경 내용을 이해하려는 경우에 종종 필요합니다. 이를 달성하기 위해 커밋에 부모 카드를 추가했습니다.

• PR 파일 탭에서 긴 이름을 가진 폴더 및 파일에 대한 추가 공간

파일 트리에서 가로 간격이 부족하여 이름이 긴 폴더와 파일이 잘렸습니다. 루트 노드와 일치하도록 트리의 들여쓰기를 수정하고 가리키기를 제외한 페이지에서 줄임표 단추를 숨김으로써 트리의 일부 추가 공간을 복구했습니다.

새 파일 트리의 이미지:

디렉터리를 마우스로 가리킬 때의 파일 트리 이미지:

• PR 파일 탭에서 Diff 창의 크기를 조정할 때 스크롤 위치 유지

PR 파일 탭에서 나란히 차이 창의 크기를 조정하면 사용자의 스크롤 위치가 손실됩니다. 이 문제는 해결되었습니다. 이제 사용자의 스크롤 위치가 diff 창 크기 조정에 유지됩니다.

• 모바일 디바이스에서 커밋 검색

모바일 디바이스에서 커밋 페이지를 볼 때 새 환경에서 검색 상자가 없습니다. 따라서 해시로 커밋을 찾아 열기가 어렵습니다. 이 문제는 현재 해결되었습니다.

• 새 PR 파일 Diff 모바일 뷰의 공간 사용 향상

사용자가 머리글에서 화면의 40%를 차지하지 않고 모바일 보기에서 더 많은 파일을 볼 수 있도록 공간을 더 잘 사용할 수 있도록 이 페이지를 업데이트했습니다.

• PR 요약 보기의 향상된 이미지

PR에서 편집한 이미지는 PR 요약 보기에 표시되지 않았지만 PR 파일 보기에 올바르게 표시되었습니다. 이 문제가 해결되었습니다.

• 새 PR을 만들 때 분기 환경 개선

이 업데이트 전에는 변경 내용을 비교 분기 대신 리포지토리의 기본 분기 비교하기 때문에 이 환경이 이상적이지 않았습니다.

Pipelines

추가 에이전트 플랫폼: ARM64

Azure Pipelines 에이전트에 대해 지원되는 플랫폼 목록에 Linux/ARM64를 추가했습니다. 코드 변경은 최소화되었지만 많은 백그라운드 작업을 먼저 완료해야 했으며 릴리스를 발표하게 되어 기쁩니다.

파이프라인 리소스에 대한 태그 필터 지원

이제 YAML 파이프라인에 '태그'를 추가했습니다. 태그를 사용하여 CI 파이프라인이 실행되도록 설정하거나 자동으로 트리거할 시기를 설정할 수 있습니다.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: main
    tags:              ### This filter is used for resolving default version
    - Production       ### Tags are AND'ed
    trigger:
      tags:            ### This filter is used for triggering the pipeline run
      - Production     ### Tags are AND'ed
      - Signed

위의 코드 조각은 CD(지속적인 배포) 파이프라인 실행이 다른 원본/리소스 또는 예약된 실행 트리거에 의해 트리거되지 않을 때 실행할 CI(연속 통합) 파이프라인의 기본 버전을 결정하는 데 태그를 사용할 수 있음을 보여 줍니다.

예를 들어 CI에 프로덕션 태그가 있는 경우에만 실행하려는 CD 파이프라인에 대해 예약된 트리거 집합이 있는 경우 트리거 섹션의 태그는 CI 완료 이벤트에서 태그 지정 조건이 충족되는 경우에만 CD 파이프라인이 트리거되도록 합니다.

파이프라인에서 허용되는 작업 제어

이제 Marketplace 작업을 사용하지 않도록 설정할 수 있습니다. 일부 사용자들은 Marketplace 확장을 허용할 수 있지만, 파이프라인 작업이 함께 수행되지는 않습니다. 더 많은 제어를 위해 모든 기본 제공 작업을 독립적으로 사용하지 않도록 설정할 수도 있습니다(체크 아웃 제외, 이는 특별한 작업). 이 두 설정을 모두 사용하도록 설정하면 파이프라인에서 실행할 수 있는 작업은 tfx를 사용하여 업로드된 작업뿐입니다. 시작하려면 "작업 제한 사항"이라는 섹션을 방문하여 https://dev.azure.com/<your_org>/_settings/pipelinessettings 찾습니다.

배타적 배포 잠금 정책

이 업데이트를 사용하면 한 번에 하나의 실행만 환경에 배포되도록 할 수 있습니다. 환경에서 "배타적 잠금" 검사를 선택하면 하나의 실행만 진행됩니다. 해당 환경에 배포하려는 후속 실행은 일시 중지됩니다. 배타적 잠금이 있는 실행이 완료되면 최신 실행이 진행됩니다. 중간 실행은 취소됩니다.

파이프라인 리소스 트리거에 대한 단계 필터

YAML에서 파이프라인 리소스에 대한 필터로 '단계'에 대한 지원을 추가했습니다. 이 필터를 사용하면 CD 파이프라인을 트리거하기 위해 전체 CI 파이프라인이 완료될 때까지 기다릴 필요가 없습니다. 이제 CI 파이프라인에서 특정 단계가 완료되면 CD 파이프라인을 트리거하도록 선택할 수 있습니다.

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:            ### This stage filter is used when evaluating conditions for triggering your CD pipeline
      - PreProduction    ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered. 
      - Production

트리거 필터에 제공된 단계가 CI 파이프라인에서 성공적으로 완료되면 CD 파이프라인에 대해 새 실행이 자동으로 트리거됩니다.

YAML 파이프라인에 대한 일반 웹후크 기반 트리거

현재 아티팩트 사용 및 자동화된 트리거를 사용할 수 있는 다양한 리소스(예: 파이프라인, 컨테이너, 빌드 및 패키지)가 있습니다. 그러나 지금까지는 다른 외부 이벤트 또는 서비스를 기반으로 배포 프로세스를 자동화할 수 없었습니다. 이 릴리스에서는 외부 서비스와 파이프라인 자동화를 통합할 수 있도록 YAML 파이프라인에서 웹후크 트리거 지원을 도입했습니다. 웹후크(Github, Github Enterprise, Nexus, Aritfactory 등)를 통해 외부 이벤트를 구독하고 파이프라인을 트리거할 수 있습니다.

웹후크 트리거를 구성하는 단계는 다음과 같습니다.

1. 외부 서비스에 웹후크를 설정합니다. 웹후크를 만들 때 다음 정보를 제공해야 합니다.

   • 요청 URL - "https://dev.azure.com/<ADO 컬렉션>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview"
   • 비밀 - 선택 사항입니다. JSON 페이로드를 보호해야 하는 경우 비밀 값을 제공합니다.

2. 새 "들어오는 웹후크" 서비스 연결을 만듭니다. 세 가지 중요한 정보를 정의할 수 있는 새로 도입된 서비스 연결 유형입니다.

   • 웹후크 이름: 웹후크의 이름은 외부 서비스에서 만든 웹후크와 일치해야 합니다.
   • HTTP 헤더 - 요청 확인을 위한 페이로드 해시 값을 포함하는 요청의 HTTP 헤더 이름입니다. 예를 들어 GitHub의 경우 요청 헤더는 "X-Hub-Signature"입니다.
   • 비밀 - 비밀은 들어오는 요청을 확인하는 데 사용되는 페이로드 해시를 구문 분석하는 데 사용됩니다(선택 사항임). 웹후크를 만드는 데 비밀을 사용한 경우 동일한 비밀 키를 제공해야 합니다.

   

3. YAML 파이프라인에 호출 webhooks 된 새 리소스 종류가 도입되었습니다. 웹후크 이벤트를 구독하려면 파이프라인에서 웹후크 리소스를 정의하고 들어오는 웹후크 서비스 연결을 가리킵니다. 또한 JSON 페이로드 데이터를 기반으로 웹후크 리소스에 대한 추가 필터를 정의하여 각 파이프라인에 대한 트리거를 추가로 사용자 지정할 수 있으며 작업에서 변수 형식으로 페이로드 데이터를 사용할 수 있습니다.

resources:
  webhooks:
    - webhook: MyWebhookTrigger          ### Webhook alias
      connection: MyWebhookConnection    ### Incoming webhook service connection
      filters:
        - path: repositoryName      ### JSON path in the payload
          value: maven-releases     ### Expected value in the path provided
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    ### JSON payload data is available in the form of ${{ parameters.<WebhookAlias>.<JSONPath>}}
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}

4. 들어오는 웹후크 서비스 연결에서 웹후크 이벤트를 수신할 때마다 웹후크 이벤트를 구독하는 모든 파이프라인에 대해 새 실행이 트리거됩니다.

YAML 리소스 트리거 문제 지원 및 추적 가능성

파이프라인 트리거가 예상대로 실행되지 않을 때 혼동될 수 있습니다. 이를 더 잘 이해하기 위해 파이프라인 정의 페이지에 트리거가 실행되지 않는 이유에 대한 정보가 표시되는 '트리거 문제'라는 새 메뉴 항목을 추가했습니다.

리소스 트리거는 두 가지 이유로 실행되지 못할 수 있습니다.

1. 제공된 서비스 연결의 원본이 잘못되었거나 트리거에 구문 오류가 있는 경우 트리거가 전혀 구성되지 않습니다. 오류로 표시됩니다.

2. 트리거 조건이 일치하지 않으면 트리거가 실행되지 않습니다. 이 경우 조건이 일치하지 않는 이유를 이해할 수 있도록 경고가 표시됩니다.

   

다중 리포지토리 트리거

하나의 YAML 파일에서 여러 리포지토리를 지정하고 리포지토리에 대한 업데이트로 인해 파이프라인이 트리거되도록 할 수 있습니다. 예를 들어 이 기능은 다음과 같은 시나리오에서 유용합니다.

• 다른 리포지토리의 도구 또는 라이브러리를 사용합니다. 도구 또는 라이브러리를 업데이트할 때마다 애플리케이션에 대한 테스트를 실행하려고 합니다.
• YAML 파일을 애플리케이션 코드와 별도의 리포지토리에 보관합니다. 업데이트가 애플리케이션 리포지토리에 푸시될 때마다 파이프라인을 트리거하려고 합니다.

이 업데이트를 사용하면 다중 리포지토리 트리거는 Azure Repos의 Git 리포지토리에 대해서만 작동합니다. GitHub 또는 BitBucket 리포지토리 리소스에는 작동하지 않습니다.

다음은 파이프라인에서 여러 리포지토리 리소스를 정의하는 방법과 모든 리포지토리에서 트리거를 구성하는 방법을 보여 주는 예제입니다.

trigger:
- main

resources:
  repositories:
  - repository: tools
    type: git
    name: MyProject/tools
    ref: main
    trigger:
      branches:
        include:
        - main
        - release

이 예제의 파이프라인은 다음과 같은 업데이트가 있는 경우 트리거됩니다.

• mainself YAML 파일을 포함하는 리포지토리의 분기
• main 또는 release 리포지토리의 tools 분기

자세한 내용은 파이프라인의 여러 리포지토리를 참조하세요.

에이전트 로그 업로드가 개선됨

에이전트가 Azure Pipelines 서버와의 통신을 중지하면 실행 중인 작업이 중단됩니다. 스트리밍 콘솔 로그를 살펴보는 경우 에이전트가 응답을 중지하기 직전에 무엇이었는지에 대한 단서를 얻었을 수 있습니다. 그러나 그렇지 않았거나 페이지를 새로 고친 경우 해당 콘솔 로그가 사라졌습니다. 이 릴리스에서는 에이전트가 전체 로그를 보내기 전에 응답을 중지하는 경우 콘솔 로그를 다음으로 가장 좋은 것으로 유지합니다. 콘솔 로그는 줄당 1000자로 제한되며 경우에 따라 불완전할 수 있지만 아무것도 표시하지 않는 것보다 훨씬 더 유용합니다. 이러한 로그를 검토하면 고유한 파이프라인 문제를 해결하는 데 도움이 될 수 있으며, 지원 엔지니어가 문제 해결을 지원할 때 확실히 도움이 될 것입니다.

선택적으로 컨테이너 볼륨을 읽기 전용으로 탑재

Azure Pipelines에서 컨테이너 작업을 실행하면 작업 영역, 작업 및 기타 자료가 포함된 여러 볼륨이 볼륨으로 매핑됩니다. 이러한 볼륨은 기본적으로 읽기/쓰기 액세스로 설정됩니다. 보안을 강화하기 위해 YAML에서 컨테이너 사양을 변경하여 볼륨을 읽기 전용으로 탑재할 수 있습니다. 아래 mountReadOnly 의 각 키는 읽기 전용으로 true 설정할 수 있습니다(기본값은 false).

resources:
  containers:
    - container: example
      image: ubuntu:18.04
      mountReadOnly:
        externals: true
        tasks: true
        tools: true
        work: false

컨테이너 시작/중지를 세분화하여 제어

일반적으로 Azure Pipelines가 작업 및 서비스 컨테이너의 수명 주기를 관리할 수 있도록 허용하는 것이 좋습니다. 그러나 일부 드문 시나리오에서는 직접 시작하고 중지할 수 있습니다. 이 릴리스에서는 Docker 작업에 해당 기능을 빌드했습니다.

다음은 새 기능을 사용하는 예제 파이프라인입니다.

resources:
  containers:
    - container: builder
      image: ubuntu:18.04
steps:
  - script: echo "I can run inside the container (it starts by default)"
    target:
      container: builder
  - task: Docker@2
    inputs:
      command: stop
      container: builder
# if any step tried to run in the container here, it would fail

또한 파이프라인 변수 Agent.ContainerMapping에 컨테이너 목록을 포함합니다. 예를 들어 스크립트의 컨테이너 목록을 검사하려는 경우 이를 사용할 수 있습니다. 여기에는 리소스 이름(위 예제의 "작성기")을 에이전트가 관리하는 컨테이너 ID에 매핑하는 문자열화된 JSON 개체가 포함되어 있습니다.

각 단계의 작업 번들 압축 풀기

에이전트가 작업을 실행하면 먼저 작업의 단계에 필요한 모든 작업 번들을 다운로드합니다. 일반적으로 성능의 경우 태스크가 여러 단계에서 사용되는 경우에도 작업당 한 번씩 태스크의 압축을 해제합니다. 압축을 푼 콘텐츠를 변경하는 신뢰할 수 없는 코드에 대한 우려가 있는 경우 에이전트가 각 사용량에 대해 작업의 압축을 풉니다. 이 모드를 사용하도록 설정하려면 에이전트를 구성할 때 전달 --alwaysextracttask 합니다.

액세스 토큰의 범위를 제한하여 릴리스 보안 개선

Azure Pipelines에 대한 보안 설정을 강화하기 위한 이니셔티브에 따라 이제 릴리스에 대한 액세스 토큰 범위 제한이 지원됩니다.

릴리스에서 실행되는 모든 작업은 액세스 토큰을 가져옵니다. 액세스 토큰은 태스크 및 스크립트에서 Azure DevOps로 다시 호출하는 데 사용됩니다. 예를 들어 액세스 토큰을 사용하여 소스 코드를 가져오거나, 아티팩트 다운로드, 로그 업로드, 결과 테스트 또는 Azure DevOps에 REST 호출을 합니다. 새 액세스 토큰은 각 작업에 대해 생성되며 작업이 완료되면 만료됩니다.

이 업데이트를 통해 액세스 토큰의 범위를 제한하고 클래식 릴리스로 동일하게 확장하여 파이프라인 보안을 개선합니다.

이 기능은 새 프로젝트 및 컬렉션에 대해 기본적으로 설정됩니다. 기존 컬렉션의 경우 컬렉션 설정 파이프라인 > 설정 > 에서 사용하도록 설정해야 합니다. > 릴리스 파이프라인에 대한 작업 권한 부여 범위를 현재 프로젝트로 제한합니다. 여기서 자세히 알아봅니다.

YAML 미리 보기 API 개선 사항

이제 파이프라인을 실행하지 않고 파이프라인의 전체 YAML 을 미리 볼 수 있습니다. 또한 미리 보기 기능에 대한 전용 새 URL을 만들었습니다. 이제 POST를 사용하여 https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview 완료된 YAML 본문을 검색할 수 있습니다. 이 새 API는 실행 큐와 동일한 매개 변수를 사용하지만 더 이상 "큐 빌드" 권한이 필요하지 않습니다.

바로 이 작업 실행

이 순간에 배포해야 하지만 CI 및 PR 작업 뒤에서 기다려야 하는 버그가 있었나요? 이 릴리스에서는 이제 대기 중 작업의 우선 순위를 변경할 수 있습니다. 풀에 대한 "관리" 권한이 있는 사용자(일반적으로 풀 관리자)는 작업 세부 정보 페이지에 새 "다음 실행" 단추를 표시합니다. 단추를 클릭하면 작업이 가능한 한 빨리 실행되도록 설정됩니다. (물론 사용 가능한 병렬 처리와 적절한 에이전트가 여전히 필요합니다.)

YAML resources 블록에서 허용되는 템플릿 식

이전에는 Azure Pipelines YAML 파일의 섹션에서 컴파일 시간 식(${{ }})이 허용되지 resources 않았습니다. 이 릴리스에서는 컨테이너에 대한 이 제한을 해제했습니다. 이렇게 하면 리소스 내에서 런타임 매개 변수 콘텐츠를 사용할 수 있습니다. 예를 들어 큐 시간에 컨테이너를 선택할 수 있습니다. 이 지원은 시간이 지남에 따라 다른 리소스로 확장할 계획입니다.

Marketplace에서 자동화된 작업 업데이트 제어

YAML 파이프라인을 작성할 때는 일반적으로 포함된 작업의 주 버전 번호만 지정합니다. 이렇게 하면 파이프라인에서 최신 기능 추가 및 버그 수정을 자동으로 수행할 수 있습니다. 경우에 따라 작업의 이전 지점 릴리스로 롤백해야 할 수 있으며, 이 업데이트를 통해 작업을 수행할 수 있는 기능이 추가되었습니다. 이제 YAML 파이프라인에서 전체 major.minor.patch 작업 버전을 지정할 수 있습니다.

이 작업은 정기적으로 수행하지 않는 것이 좋으며, 최신 작업이 파이프라인을 중단하는 것을 발견한 경우에만 임시 해결 방법으로 사용하는 것이 좋습니다. 또한 Marketplace에서 이전 버전의 작업을 설치하지 않습니다. 컬렉션에 이미 있어야 합니다. 그렇지 않으면 파이프라인이 실패합니다.

예시:

steps:
- task: MyTask@1  # a normal, major-version only reference
- task: MyOtherTask@2.3.4   # pinned to a precise version

에이전트 및 작업의 노드 10 지원

노드 6은 더 이상 지원되지 않으므로 노드 10에서 작업하도록 태스크를 마이그레이션하고 있습니다. 이 업데이트를 위해 기본 제공 작업의 약 50%를 노드 10으로 마이그레이션했습니다. 이제 에이전트는 노드 6 및 노드 10 작업을 모두 실행할 수 있습니다. 향후 업데이트에서는 에이전트에서 노드 6을 완전히 제거합니다. 에이전트에서 노드 6을 제거할 준비를 하려면 곧 노드 10을 사용하도록 사내 확장 및 사용자 지정 작업을 업데이트할 것을 요청합니다. 작업에 노드 10을 사용하려면 다음에서 task.jsonexecutionNode 업데이트합니다.Node10

클래식 빌드 디자이너에서 YAML 변환 개선

이 릴리스에서는 디자이너 빌드 파이프라인에 대한 새로운 "YAML로 내보내기" 기능을 소개합니다. 파이프라인 정의를 저장한 다음 메뉴에서 "YAML로 내보내기"를 ... 찾습니다.

새 내보내기 함수는 클래식 빌드 디자이너에서 이전에 찾은 "YAML로 보기" 함수를 대체합니다. 이 함수는 웹 UI가 빌드에 대해 알고 있는 것만 검사할 수 있으므로 불완전했으며 때로는 잘못된 YAML이 생성되기도 했습니다. 새 내보내기 함수는 파이프라인이 처리되는 방법을 정확하게 고려하여 디자이너 파이프라인에 대한 충실도를 갖춘 YAML을 생성합니다.

새 웹 플랫폼 변환 – 리포지토리 설정

두 리포지토리 설정 페이지를 새 웹 플랫폼으로 업그레이드된 단일 환경으로 변환했습니다. 이 업그레이드는 환경을 더 빠르고 최신으로 만들 뿐만 아니라 프로젝트 수준에서 분기 수준까지 모든 정책에 대한 단일 진입점을 제공합니다.

이 새로운 환경을 사용하면 로드 시간이 빨라지고 검색 필터가 추가되어 리포지토리 수가 많은 프로젝트에 대한 탐색이 더 쉬워집니다. 정책 탭에서 프로젝트 수준 정책 및 교차 리포지토리 정책 목록을 볼 수도 있습니다.

리포지토리를 클릭하면 리포지토리 수준에서 설정된 정책 및 사용 권한을 볼 수 있습니다. 정책 탭 내에서 정책이 설정된 모든 분기의 목록을 볼 수 있습니다. 이제 분기를 클릭하여 리포지토리 설정 페이지를 벗어나지 않고 정책을 모두 확인합니다.

이제 정책이 작업 중인 정책보다 높은 범위에서 상속되면 각 개별 정책 옆에서 정책이 상속된 위치를 보여 드립니다. 범위 이름을 클릭하여 상위 수준 정책이 설정된 페이지로 이동할 수도 있습니다.

또한 정책 페이지 자체가 축소 가능한 섹션을 사용하여 새 웹 플랫폼으로 업그레이드되었습니다. 특정 빌드 유효성 검사, 상태 검사 또는 자동 검토자 정책을 찾는 환경을 개선하기 위해 각 섹션에 대한 검색 필터를 추가했습니다.

ServiceNow 변경 관리를 YAML 파이프라인과 통합

ServiceNow용 Azure Pipelines 앱을 사용하면 Azure Pipelines 및 ServiceNow 변경 관리를 통합할 수 있습니다. 이 업데이트를 통해 Azure Pipelines가 ServiceNow에서 관리되는 변경 관리 프로세스를 YAML 파이프라인으로 더 자세히 인식하도록 합니다.

리소스에서 "ServiceNow 변경 관리" 검사를 구성하여 이제 해당 리소스에 빌드를 배포하기 전에 변경 내용이 승인되도록 일시 중지할 수 있습니다. 스테이지에 대한 새 변경을 자동으로 만들거나 기존 변경 요청을 기다릴 수 있습니다.

서버 작업에 작업을 추가하여 UpdateServiceNowChangeRequest 배포 상태, 메모 등으로 변경 요청을 업데이트할 수도 있습니다.

Artifacts

UI에서 조직 범위 피드를 만드는 기능

고객이 온-프레미스 및 호스티드 서비스 모두에 대해 웹 UI를 통해 컬렉션 범위 피드를 만들고 관리할 수 있는 기능을 다시 제공하고 있습니다.

이제 아티팩> 트 - 피드 만들기로 이동하고 범위 내에서 피드 유형을 선택하여 UI를 통해 조직 범위 피드를 만들 수 있습니다.

나머지 Azure DevOps 제품에 맞게 프로젝트 범위 피드를 사용하는 것이 좋습니다. 하지만 UI 및 다양한 REST API를 통해 컬렉션 범위 피드를 다시 만들고 관리하고 사용할 수 있습니다. 자세한 내용은 피드 설명서를 참조하세요.

이제 Maven 패키지에 업데이트 패키지 버전 REST API 사용 가능

이제 Azure Artifacts "패키지 버전 업데이트" REST API를 사용하여 Maven 패키지 버전을 업데이트할 수 있습니다. 이전에는 REST API를 사용하여 NuGet, Maven, npm 및 유니버설 패키지에 대한 패키지 버전을 업데이트할 수 있었지만 Maven 패키지는 업데이트할 수 없었습니다.

Maven 패키지를 업데이트하려면 다음과 같이 HTTP PATCH 명령을 사용합니다.

PATCH https://pkgs.dev.azure.com/{collection}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1

다음을 설정할 수 있습니다.

URI 매개 변수

이름	In	Required	Type	설명
artifactId	path	TRUE	string	패키지의 아티팩트 ID
피드	path	TRUE	string	피드의 이름 또는 ID
groupId	path	TRUE	string	패키지의 그룹 ID
컬렉션	path	TRUE	string	Azure DevOps 컬렉션의 이름
version	path	TRUE	string	패키지 버전
project	경로		string	프로젝트 ID 또는 프로젝트 이름
api-version	query	TRUE	string	사용할 API의 버전입니다. 이 버전의 API를 사용하려면 '5.1-preview.1'로 설정해야 합니다.

요청 본문

이름	타입	설명
보기	JsonPatchOperation	패키지 버전이 추가될 보기

자세한 내용은 업데이트되는 REST API 설명서를 참조하세요.

피드백

많은 의견 부탁드립니다! 문제를 보고하거나 아이디어를 제공하고 개발자 커뮤니티를 통해 추적하고 Stack Overflow에 대한 조언을 얻을 수 있습니다.

---

맨 위로 이동