이제 스프린트 141 Azure DevOps Services 업데이트에서 Azure Pipelines에 규정 준수 및 보안 유효성 검사를 포함할 수 있습니다. Azure Repos 끌어오기 요청의 대상 분기를 변경할 수 있습니다.
자세한 내용은 아래 기능 목록을 확인하세요.
기능
일반:
Azure Pipelines:
- 파이프라인에서 규정 준수 및 보안 유효성 검사 Azure Policy
- Azure VM에 대한 간소화된 지속적인 업데이트
- Xcode 작업은 새로 릴리스된 Xcode 10을 지원합니다.
- 빌드를 큐에 대기할 때 성능 향상
- 인증서를 사용하여 인증하는 서비스 주체를 사용하여 Azure 서비스 연결 만들기
- 파이프라인에서 테스트 분석 보기
Azure Repos:
관리:
다음 단계
참고
이러한 기능은 향후 2~3주 동안 출시될 예정입니다.
아래의 새로운 기능에 대해 읽고 Azure DevOps Services 직접 시도해 보세요.
일반
탐색 업데이트
올해 6월에 새로운 탐색 모델의 첫 번째 반복을 출시했습니다. 우리는 많은 사람들이 제공 한 피드백에 따라 그 경험을 개선하기 위해 여름을 보냈습니다. 감사합니다! 다음 단계는 새 모델에서 미리 보기로 이동하여 제품의 탐색 이 되는 것입니다. 모든 조직에 새 모델을 도입하기 위한 일정과 함께 최근 변경 내용을 설명하는 블로그 게시물을 읽어보세요.
확장된 검색 상자
검색의 중요성을 이해하고 제품 헤더의 확장된 검색 상자를 다시 가져옵니다. 또한 이제 Azure DevOps의 모든 서비스 페이지에서 "/"를 클릭하여 검색 상자를 호출할 수 있습니다. 이 기능은 사용자 음성 제안에 따라 우선 순위가 지정되었습니다.
기본 검색 상자는 다음과 같습니다.
"/"를 입력하면 확장된 검색 상자가 표시됩니다.
Azure Pipelines
파이프라인에서 규정 준수 및 보안 유효성 검사 Azure Policy
개발 프로세스 초기에 소프트웨어의 안정성과 보안을 보장하면서 개발, 보안 및 운영을 통합하고자 합니다. 이를 위해 Azure Policy 대한 지원이 추가되었습니다.
Azure Policy를 통해 리소스에 대한 규칙 및 효과를 적용하는 정책 정의를 사용하여 IT 문제를 관리하고 방지할 수 있습니다. Azure Policy 사용하는 경우 리소스는 회사 표준 및 서비스 수준 계약을 준수합니다.
릴리스 프로세스의 일부로 규정 준수 및 보안 지침을 준수하기 위해 Azure 리소스 그룹 배포 환경을 개선했습니다. 이제 ARM 템플릿을 배포하는 동안 위반이 발생하는 경우 관련 정책 관련 오류로 Azure 리소스 그룹 배포 작업이 실패합니다.
또한 릴리스 정의 템플릿을 Azure Policy 추가했습니다. 이렇게 하면 사용자가 Azure 정책을 만들고 릴리스 정의 자체에서 리소스, 구독 또는 관리 그룹에 이러한 정책을 할당할 수 있습니다.
Azure VM에 대한 간소화된 지속적인 업데이트
이 릴리스에서는 Azure Virtual Machines 지속적인 업데이트를 설정하는 프로세스를 간소화하는 새 마법사를 추가했습니다. Azure DevOps organization 및 가상 머신을 등록할 배포 그룹을 지정하면 샘플 스크립트 단계를 사용하여 릴리스 파이프라인이 자동으로 만들어집니다. 추가 Azure 리소스를 프로비전하거나, 스크립트를 실행하거나, 애플리케이션을 업그레이드하거나, 추가 유효성 검사 테스트를 실행해야 하는 경우 이 릴리스 파이프라인을 쉽게 사용자 지정할 수 있습니다.
Xcode 작업은 새로 릴리스된 Xcode 10을 지원합니다.
Apple의 Xcode 10 릴리스와 일치하여 이제 Xcode 10을 사용하여 특별히 프로젝트를 빌드하거나 테스트하도록 설정할 수 있습니다. 파이프라인은 Xcode 버전의 행렬 과 병렬로 작업을 실행할 수도 있습니다. Microsoft 호스팅 macOS 에이전트 풀을 사용하여 이러한 빌드를 실행할 수 있습니다. Azure Pipelines에서 Xcode를 사용하기 위한 지침을 참조하세요.
빌드를 큐에 대기할 때 성능 향상
호스트된 에이전트를 사용하면 각 작업에 대한 새 VM이 표시됩니다. 이렇게 하면 보안 및 제어의 추가 계층이 제공됩니다. 이전 빌드가 출력을 벗어나거나 컴퓨터에 악의적인 작업을 수행하는 것에 대해 걱정할 필요가 없습니다. 그러나 처음 시작하는 작업은 이전에 빌드 큐 를 클릭할 때와 파이프라인이 실제로 실행 중인 시점 사이에 지연을 의미했습니다. 이러한 많은 지연을 조사하고 수정했으며 이제 호스트된 풀에서 큐-시작 시간에서 5배의 속도 향상을 확인했습니다. 이제 빌드를 더 빠르게 시작할 수 있습니다. 즉, 더 빠르게 반복할 수 있습니다.
인증서를 사용하여 인증하는 서비스 주체를 사용하여 Azure 서비스 연결 만들기
이제 인증을 위해 서비스 주체 및 인증서를 사용하여 Azure Pipelines 또는 TFS(Team Foundation Server)에서 Azure 서비스 연결을 정의할 수 있습니다. 이제 Azure 서비스 연결에서 인증서로 인증하는 서비스 주체를 지원하므로 이제 AD FS로 구성된 Azure Stack에 배포할 수 있습니다. 인증서 인증을 사용하여 서비스 주체를 만들려면 인증서로 인증하는 서비스 주체를 만드는 방법에 대한 문서를 참조하세요.
파이프라인에서 테스트 분석 보기
시간이 지남에 따라 테스트 품질을 추적하고 테스트 담보를 개선하는 것이 정상 파이프라인을 유지하는 데 핵심입니다. 테스트 분석 기능은 빌드 및 릴리스 파이프라인에 대한 테스트 데이터에 대한 거의 실시간 가시성을 제공합니다. 반복적이고 영향력이 높은 품질 문제를 식별하여 파이프라인의 효율성을 개선하는 데 도움이 됩니다.
테스트 결과를 다양한 요소별로 그룹화하거나, 분기 또는 테스트 파일에 대한 주요 테스트를 식별하거나, 특정 테스트로 드릴다운하여 추세를 보고 flakiness와 같은 품질 문제를 이해할 수 있습니다.
빌드 및 릴리스에 대한 테스트 분석 보기, 아래 미리 보기:
자세한 내용은 이 설명서를 참조하세요.
Azure Repos
끌어오기 요청의 대상 분기 변경
대부분의 팀에서 거의 모든 끌어오기 요청은 또는 develop와 같은 master 동일한 분기를 대상으로 합니다. 그러나 다른 분기를 대상으로 지정해야 하는 경우 대상 분기를 기본 분기에서 변경하는 것을 잊기 쉽습니다. 활성 끌어오기 요청의 대상 분기를 변경하는 새로운 기능을 사용하면 이제 간단한 작업입니다. 끌어오기 요청 헤더의 대상 분기 이름 근처에 있는 연필 아이콘을 클릭하기만 하면 됩니다.
실수를 수정하는 것 외에도 대상 분기를 변경하는 기능을 사용하면 대상 분기가 병합되거나 삭제되었을 때 끌어오기 요청의 대상을 쉽게 "다시 지정"할 수 있습니다. 변경 내용에 따라 달라지는 몇 가지 기능이 포함된 기능 분기 대상으로 하는 PR이 있는 시나리오를 고려해 보세요. 기능 분기 다른 변경 내용과 격리된 종속 변경 내용을 검토하여 처음에 를 대상으로 지정features/new-feature하려고 합니다. 그런 다음 검토자는 변경 내용만 보고 적절한 설명을 남길 수 있습니다.
이제 기능 분기 PR도 활성화되어 있고 변경 전에 에 병합된 master 경우 어떻게 될까요? 이전에는 변경 내용을 포기하고 에 새 PR master을 만들거나 PR을 에 features/new-feature병합한 다음 에서 로 features/new-feature 다른 PR을 master만들어야 했습니다. 대상 분기를 업데이트하는 이 새로운 작업을 사용하면 PR의 대상 분기를 에서 로 features/new-featuremaster변경하여 모든 컨텍스트와 주석을 보존할 수 있습니다. 대상 분기를 변경하면 PR에 대한 새 업데이트가 생성되므로 대상 분기가 변경되기 전에 이전 diff를 쉽게 되돌아볼 수 있습니다.
플랫폼 간 호환성 설정을 사용하여 Git 리포지토리 보호
Git은 플랫폼 간 기술이므로 파일 또는 디렉터리에서 특정 플랫폼에서 호환되지 않을 수 있는 파일 시스템으로 가는 방법을 찾을 수 있습니다. 이러한 비호환성 관련 세부 정보는 설명서에서 확인할 수 있습니다.
팀이 리포지토리 및 해당 개발자를 보호할 수 있도록 하나 이상의 OS 플랫폼과 호환되지 않는 파일/디렉터리로 커밋을 포함하는 푸시를 차단하는 새 리포지토리 설정을 추가했습니다. 이러한 설정에 대해 자세히 알아보세요.
관리
MSA 계정에서 AAD 사용자 지원
이제 Azure DevOps는 MSA에서 지원하는 조직에 액세스하는 AAD(AzureAD) 사용자를 지원합니다. 즉, 관리자의 경우 Azure DevOps organization 회사 사용자에 대해 MSA를 사용하는 경우 이제 Azure DevOps에서만 사용할 새 MSA ID를 만드는 대신 새 직원이 AAD 자격 증명을 사용하여 액세스할 수 있습니다.
회사 사용자가 Azure DevOps를 AAD에 연결하는 것이 가장 좋은 환경이라고 생각하지만, 올해 초 관리자가 변환하는 데 더 많은 시간이 필요하다는 것을 알게 되었습니다. Azure DevOps가 월말에 AzureAD에서 지원하는 사용자 지정 도메인 이름을 사용하여 새 MSA 사용자를 만들지 못하게 되면 AAD 사용자를 MSA 지원 조직에 허용하면 새 사용자가 Azure DevOps에 액세스할 수 있습니다.
Azure DevOps에서 이미 AAD ID를 사용하는 조직의 경우 이 기능은 적용되지 않습니다. 현재 MSA ID를 사용하는 조직의 경우 모든 기존 사용자가 현재와 마찬가지로 MSA ID로 계속 로그인할 수 있습니다. 이는 나중에 추가된 사용자(회사 이메일 주소로 MSA를 만들 수 없는 사용자)에만 적용됩니다.
이 환경이 유용할 수 있는 예제 시나리오는 다음과 같습니다. Dorothy는 회사 Fabrikam에 대한 Azure DevOps 조직 소유자. 그녀와 10명의 팀 구성원으로 구성된 팀은 모두 회사 이메일 주소(예: )를 사용하는 MSA ID를 사용하여 Azure DevOps에 로그인합니다. Dorothy@fabrikam.com Sam은 오늘 회사에 합류한 새로운 팀원입니다. Dorothy는 자신의 이메일 sam@fabrikam.com를 사용하여 Azure DevOps에 그를 초대합니다. 전자 메일에서 지금 참가 링크를 클릭하면 Microsoft 365를 사용하여 전자 메일에 액세스하기 위해 제공된 것과 동일한 AAD ID로 Azure DevOps에 로그인할 수 있습니다. 이를 통해 Sam은 11 명의 동료와 공동 작업할 수 있으며 Dorothy에게 준비가 되면 Azure DevOps organization AAD에 자유롭게 연결할 수 있습니다.
자세한 내용은 블로그 게시물을 참조하세요.
피드백을 제공하는 방법
이러한 기능에 대해 어떻게 생각하는지 듣고 싶습니다. 피드백 메뉴를 사용하여 문제를 보고하거나 제안을 제공합니다.
Stack Overflow에서 커뮤니티에서 조언과 질문에 답변할 수도 있습니다.
감사합니다,
고피나스 치악카가리 (트위터)