Azure DevOps 환경이 안전하게 유지되도록 하기 위해 주요 서비스 업데이트를 수행합니다. 여기에는 2025년 4월부터 새로운 OAuth 앱 등록에 대한 지원이 종료되지만 기존 앱은 2026년에 완전히 사용 중지될 때까지 계속 작동합니다. 또한 2025년 4월 23일부터 Azure Repos의 TFVC 체크 인 정책에 대한 업데이트와 함께 모든 HTTPS 연결에 SNI(서버 이름 표시)가 필요합니다.
이러한 업데이트와 함께 Azure Boards + GitHub 통합의 최신 개선 사항을 발표하여 분기, 끌어오기 요청 및 커밋을 작업 항목에 쉽게 연결할 수 있게 되었습니다. 또한 파이프라인은 이제 YAML 단계 종속성에 대한 가시성을 높여 팀이 효율성 향상을 통해 더 복잡한 워크플로를 관리할 수 있도록 지원합니다.
자세한 내용은 릴리스 정보를 확인하세요.
일반
Azure Boards:
Azure Repos
Azure Pipelines (애저 파이프라인스)
Azure 테스트 계획:
일반
2025년 4월부터 새로운 Azure DevOps OAuth 앱 없음
2025년 4월부터 더 이상 Azure DevOps OAuth 앱의 새 등록을 지원하지 않습니다. 이는 Azure DevOps OAuth 플랫폼의 사용 중지에 대한 장기적인 비전을 향한 첫 번째 단계입니다. Azure DevOps REST API를 기반으로 애플리케이션을 빌드하는 모든 개발자는 Microsoft ID 플랫폼을 탐색하고 대신 새 Entra 애플리케이션 을 등록하는 것이 좋습니다.
모든 기존 Azure DevOps OAuth 앱은 2026년에 플랫폼이 공식적으로 사용 중지될 때까지 계속 작동합니다. 여기에 있는 블로그 게시물에서 자세히 알아보세요.
이제 Azure DevOps Services에 대한 SNI(서버 이름 표시)가 필수입니다.
2025년 4월 23일부터 Azure DevOps Services에 들어오는 모든 HTTPS 연결에 SNI(서버 이름 표시) 가 필요합니다.
SNI는 클라이언트가 연결 중인 호스트 이름을 지정할 수 있도록 하는 TLS 프로토콜에 대한 확장입니다. 모든 최신 브라우저 및 클라이언트 소프트웨어는 SNI를 지원하고 기본적으로 사용하므로 대부분의 사용자가 원활하게 전환할 수 있습니다. 사실, 우리 서버에 도달하는 고객 트래픽의 99.995% 이상이 SNI를 지원합니다.
그러나 일부 클라이언트 소프트웨어는 오래되거나 잘못 구성된 네트워킹 라이브러리, 런타임 또는 운영 체제와 같은 다양한 요인으로 인해 SNI와 호환되지 않을 수 있습니다. 프록시 또는 NGFW 방화벽에서도 문제가 발생할 수 있습니다. Azure DevOps와 함께 사용되는 다음 도구는 SNI 문제의 영향을 받을 수 있습니다.
- Git 클라이언트
- IDE 플러그인 및 확장(팀 탐색기 에브리웨어)
- SNI(Java 6 이하)를 지원하지 않거나 SNI를 기본적으로 사용하도록 설정하지 않은 이전 Java 버전에서 실행되는 소프트웨어(일부 버전의 Java 7 및 8)
- 이전 브라우저 버전(참조 https://caniuse.com/sni)
SNI 문제는 일반적으로 다음과 같은 연결 오류로 나타납니다.
- ERR_SSL_PROTOCOL_ERROR , ERR_CERT_COMMON_NAME_INVALID (SSL 프로토콜 오류, 인증서 일반 이름 유효하지 않음)
- javax.net.ssl.SSLHandshakeException, javax.net.ssl.SSLException
- SSL/TLS 보안 채널에 대한 트러스트 관계를 설정할 수 없습니다.
SNI를 요구하도록 구성한 Azure DevOps의 상태 엔드포인트를 호출하여 시스템의 SNI 호환성을 확인할 수 있습니다. 이 호출이 성공하면 해당 운영 체제 및 네트워킹 환경을 포함한 호스트가 SNI와 호환된다는 것을 나타냅니다. 테스트 방법에 대한 자세한 지침은 블로그 게시물을 참조하세요.
Azure Boards
GitHub 통합: 커밋, 분기 및 끌어오기 요청에 대한 연결 개선 사항
사용 가능성 격차를 해소하고 Azure Repos에서 익숙한 환경에 맞게 Boards + GitHub 통합을 지속적으로 개선하고 있습니다.
이 업데이트를 통해 분기, 끌어오기 요청 및 커밋이 작업 항목에 연결되는 방법을 간소화하는 몇 가지 개선 사항이 도입되었습니다.
GitHub 분기가 작업 항목에 연결되면 관련된 풀 리퀘스트가 자동으로 연결됩니다. AB#을 수동으로 사용할 필요가 없습니다.
끌어오기 요청이 병합되면 병합 커밋이 작업 항목에 자동으로 연결됩니다.
끌어오기 요청이 병합된 후 분기가 삭제되면 분기 링크가 작업 항목에서 자동으로 제거됩니다.
이러한 향상된 기능으로 개발 진행 상황을 더 쉽게 추적하고 최신의 작업 항목 연관성을 더 쉽게 유지할 수 있습니다.
GitHub 통합: YAML 파이프라인에 대한 빌드 상태 표시
YAML과 클래식 파이프라인 간의 기능 패리티를 달성하기 위해 최선을 다하고 있습니다. 누락된 기능 중 하나는 리포지토리가 GitHub에서 호스트될 때 "빌드에 통합" 링크를 제공하는 기능이었습니다. 최신 릴리스에서는 YAML 파이프라인 설정에서 확인할 수 있는 옵션을 추가하여 이러한 격차를 해결했습니다.
빌드가 완료되면 연결된 작업 항목에 해당 링크가 자동으로 표시되어 전반적인 추적 가능성 스토리가 향상됩니다.
배달 계획 제한 증가
이전에는 프로젝트당 배달 계획을 1,000으로 제한했습니다. 이 업데이트를 통해 프로젝트당 최대 배달 계획을 1,500으로 늘렸습니다. 여기에서 설명서에서 배달 계획을 추가하고 편집하는 방법에 대해 자세히 알아볼 수 있습니다.
Azure Repos
TFVC 체크 인 정책 변경
Microsoft.TeamFoundationServer.ExtendedClient NuGet 패키지의 새 버전(19.255.0-preview)
NuGet Microsoft.TeamFoundationServer.ExtendedClient 패키지는 새 TFVC 정책 클래스 및 메서드로 업데이트되었습니다.
정책 변경
TFVC 체크 인 정책이 Azure DevOps에 저장되는 방식을 변경하고 있습니다. 즉, NuGet Microsoft.TeamFoundationServer.ExtendedClient가 서비스와 통신하는 방법에 대한 업데이트도 의미합니다.
TFVC 프로젝트에서 체크 인 정책을 사용하는 경우 해당 정책을 새 형식으로 마이그레이션합니다. 이 작업을 수행하는 방법에는 두 가지가 있습니다.
- Visual Studio 사용.
경고
작업의 위험한 특정 결과.: 계속하기 전에 Visual Studio를 최신 버전으로 업데이트해야 합니다(VS 2022, VS 2019 및 VS 2017에서 최소 버전 17.14 Preview 3, 17.13.617.12.7, 17.10.13, 17.8.2016.11.4615.9.72 , 새 정책을 지원).
Visual Studio 프로젝트 관리자를 사용하여 새 정책을 만들려면 설정 - 팀 프로젝트 ->> 소스 제어 -> 체크 인 정책을 열고 이전 매개 변수와 동일한 매개 변수를 사용하여 새 정책("사용되지 않음" 표시 없음)을 추가해야 합니다.
- 사용자 지정 구현을
Microsoft.TeamFoundationServer.ExtendedClient사용하여 서버와 통신하는 경우 마이그레이션 가이드를 따르세요.
향후 Azure DevOps 버전과 호환되는 TFVC 체크 인을 유지하려면 마이그레이션이 필요합니다. 당분간 이전(사용되지 않음)과 새 정책은 모두 유효하고 기능적입니다. 향후 계획에 대한 자세한 내용은 블로그 게시물을 참조하세요.
GetRepository API의 향상된 기능
리포지토리 - 리포지토리 생성 날짜를 반환하는 리포지토리 API 가져오기의 응답에 속성을 추가 creationDate 했습니다. 이 속성은 API 버전 7.2-preview 이상에서 사용할 수 있습니다.
끌어오기 요청 쿼리 API 향상
끌어오기 요청 쿼리 - Get API의 응답에 새 Label 속성이 도입되었습니다. 이제 모든 쿼리에서 관련 끌어오기 요청에 대한 레이블(태그)을 포함할지 여부를 지정할 수 있습니다.
새 Include 속성을 사용할 수 있습니다. 레이블로 설정하면 응답에 지정된 PR에 대한 레이블이 포함됩니다.
그대로 null 두면 레이블이 포함되지 않습니다.
의도하지 않은 오류를 방지하려면 NotSet을(를) 명시적으로 할당하지 않도록 하십시오. 이렇게 하면 Bad Request이(가) 발생합니다.
비고
레이블 보강 리소스 사용률은 할당된 레이블 수와 해당 길이에 따라 달라집니다. 레이블을 요청하면 제한에 영향을 미치고 네트워크 부하를 증가시킬 수 있습니다. 성능을 최적화하려면 불필요한 레이블 요청을 방지하는 것이 좋습니다.
요청 페이로드 예제:
{
"queries": [
{
"type": "lastMergeCommit",
"include": "Labels",
"items": [
"0d6c9b2b524113113fced41aecbf8631a4649dec"
]
},
{
"type": "lastMergeCommit",
"items": [
"b524113113f0dd41aecbf8631a4649dec6c9b2ce"
]
}
]
}
Azure Pipelines (애저 파이프라인스)
YAML 파이프라인 단계 종속성에 대한 가시성 향상
YAML 파이프라인은 복잡한 워크플로를 관리할 수 있는 유연성을 제공하지만, 특히 다중 지역 배포에서 스테이지 종속성을 시각화하는 것은 어려운 과제였습니다.
스테이지가 어떻게 연결되는지 항상 명확하지는 않습니다. 예를 들어 CUS3이 WUS2 및 WUS3 외에도 WUS1에 의존하는지 여부를 확인하려면 YAML을 직접 검토해야 합니다.
이 스프린트를 사용하면 스테이지가 확장될 때 스테이지 종속성이 표시되어 실행 순서 및 업스트림 요구 사항에 대한 즉각적인 인사이트를 제공합니다.
새 에이전트 CDN
Edgio CDN이 사용 중지되면 Edgio https://vstsagentpackage.azureedge.net 가 소유한 도메인 URL도 사용 중지됩니다. 새 CDN에서 지원하는 새 도메인 URL https://download.agent.dev.azure.com 을 추가하고 있습니다. 방화벽 허용 목록에 이 새 도메인 URL을 추가해야 합니다. 이전 도메인 URL이 제거되면 자체 호스팅 에이전트에 대한 에이전트 패키지 다운로드가 실패합니다. 자세한 내용은 게시물을 참조하세요.
노드 16이 파이프라인-* 파이프라인 에이전트 패키지에서 제거됩니다.
에이전트 작업은 PowerShell 또는 노드에서 구현할 수 있습니다. 에이전트는 태스크가 대상으로 지정할 수 있는 여러 버전의 노드와 함께 제공됩니다.
새 노드 버전이 릴리스되면 태스크 가 새 노드 버전을 사용하도록 업데이트됩니다. 런타임은 에이전트에 포함됩니다.
노드 버전이 업스트림 유지 관리 기간을 벗어나면 일부 파이프라인 태스크는 여전히 이를 필요로 합니다. Azure DevOps는 지원되는 작업을 지원되는 노드 버전으로 업데이트합니다. 타사 작업을 실행하려면 이전 노드 버전이 여전히 필요할 수 있습니다.
이를 수용하기 위해 다음 두 가지 유형의 파이프라인 에이전트 패키지가 있습니다.
| 패키지 | 노드 버전 | 설명 |
|---|---|---|
vsts-agent-* |
6, 10, 16, 20 | 작업 실행 처리기로 사용할 수 있는 모든 노드 버전을 포함합니다. |
pipelines-agents-* |
20 | 최신 노드 버전만 포함합니다. 이러한 패키지의 목표는 수명 종료 버전의 Node를 포함하지 않는 것입니다. |
노드 16이 번들로 묶여 있지 않은 에이전트에서 노드 16 실행 처리기가 필요한 작업을 실행하려면 파이프라인에 NodeTaskRunnerInstaller@0 작업을 삽입하여 실행 처리기를 설치할 수 있습니다.
steps:
- task: NodeTaskRunnerInstaller@0
inputs:
runnerVersion: 16
Azure 테스트 계획
작업 로깅 사용 중지 및 화면 녹화로 전환
데스크톱 Azure Test Runner 클라이언트는 최신 Windows 버전에서 더 이상 사용되지 않는 Windows 7에 도입된 도구인 PSR(문제 단계 레코더)을 사용합니다. 따라서 데스크톱 테스트 실행기에서 작업 로그 기능은 이후 업데이트에서 더 이상 작동하지 않을 수 있습니다.
중단 없는 테스트 추적을 보장하려면 테스트 단계를 캡처하고 관리하는 최신의 신뢰할 수 있는 방법을 제공하는 웹 실행기 테스트 및 피드백 확장에서 화면 녹화로 전환하는 것이 좋습니다. 테스트 및 피드백 확장으로 전환하는 데 도움이 필요한 경우 지원 팀에 문의하세요.
수동 테스트 실행 자동 일시 중지
자동 일시 중지 기능을 사용하여 테스트 실행에서 진행 상황을 잃지 마세요. 이 새로운 기능은 작업이 중단된 경우 테스트 사례 실행을 자동으로 일시 중지하여 수동 일시 중지 없이 부분 진행률을 저장합니다. 세션을 종료하든 닫든 관계없이 중단한 위치에서 테스트 사례를 쉽게 재개하여 데이터 손실 위험을 줄이고 워크플로를 개선할 수 있습니다. 일시 중지 및 다시 시작 프로세스를 간소화하여 자동 일시 중지를 사용하면 진행률을 잃을 염려 없이 테스트에 집중할 수 있습니다. 시도해보시고 이메일을 통해 어떻게 생각하는지 알려주세요!
다음 단계
비고
이러한 기능은 향후 2~3주 동안 출시될 예정입니다.
Azure DevOps로 이동하여 살펴보세요.
피드백을 제공하는 방법
이러한 기능에 대해 어떻게 생각하는지 듣고 싶습니다. 도움말 메뉴를 사용하여 문제를 보고하거나 제안을 제공합니다.
또한 Stack Overflow에서 커뮤니티로부터 조언을 얻고 질문에 대한 답변을 받을 수 있습니다.
감사
실비우안드리카