빌드 파이프라인에서 GitHub Enterprise 지원 및 자동 GitHub 서비스 연결 - Sprint 146 업데이트
Azure DevOps의 Sprint 146 업데이트에서 Azure Pipelines와의 GitHub 통합을 개선했습니다. 새로운 빌드 파이프라인 마법사는 이제 GitHub Enterprise 리포지토리의 파이프라인을 만들 수 있습니다. 또한 리포지토리를 분석하여 추천 언어 템플릿을 제공합니다. 또한 선택한 GitHub 리포지토리에 대한 서비스 연결을 만들고 다시 사용할 수 있습니다.
자세한 내용은 아래 기능 목록을 확인하세요.
기능
일반:
Azure Boards:
Azure Pipelines:
- 파이프라인 마법사에서의 GitHub Enterprise 지원
- 파이프라인에서의 자동 GitHub 서비스 연결
- GitHub Checks에서 각 파이프라인 작업의 상태 표시
- GitHub에서 YAML 리소스의 기본 권한 부여
- YAML 파이프라인의 서비스 컨테이너
- 릴리스 요약에서 GitHub 커밋에 연결된 작업 항목
- YAML에 최적화된 새로운 Azure App Service 작업
- Azure SQL 작업에 대한 Azure AD(Active Directory) 인증 지원
- Grafana 주석 서비스 후크
- Azure Monitor 경고 쿼리 작업
- Kubernetes에 배포 작업에서 사양 파일의 인라인 입력
- Docker CLI 설치 관리자 작업
- Microsoft 호스트된 에이전트의 Java LTS(장기 지원)
- Bitbucket Cloud 파이프라인의 YAML 지원
- 끌어오기 요청의 여러 CI 빌드 트리거 방지
- 포크된 리포지토리 빌드의 빌드 번호 변경, 아티팩트 업로드 및 다운로드
- 실패한 테스트의 빌드를 실패시키는, 테스트 결과 게시 작업의 새 옵션
- Azure DevOps 프로젝트를 만들기 위해 Azure Portal에 업데이트
- Azure Portal을 사용하여 CosmosDB 데이터베이스 설정 및 배포
- Azure Portal에서 Functions에 대한 빌드 및 릴리스 파이프라인 설정
Azure Artifacts:
Wiki:
일반
삭제된 프로젝트 복원
이 업데이트에서는 Azure DevOps 포털에서 삭제된 프로젝트를 복원하는 기능을 추가했습니다. "프로젝트 삭제" 권한이 있는 경우 조직 설정 > 개요 페이지에서 삭제된 프로젝트를 복원할 수도 있습니다.
Azure Boards
기본 프로세스를 사용하여 작업 구성 간소화
Important
기본 프로세스는 미국 중부 지역에서 만든 새 조직 내의 새 프로젝트에 대한 기본 프로세스로 공개 미리 보기로 제공됩니다.
지금까지 Agile은 다양한 프로젝트 배달 방법에 맞게 강력하고 유연한 작업 항목 유형 및 상태 집합을 제공하는 새 프로젝트의 기본 프로세스였습니다. 다른 도구에 더 익숙하거나 성장하고 더 강력한 도구 집합을 채택하려는 일부 팀의 경우 더 친숙한 용어를 사용하여 빠르게 시작하려고 합니다.
새로운 기본 프로세스는 작업을 계획하고 추적하기 위한 세 가지 작업 항목 유형(에픽, 문제 및 작업)을 제공합니다. Epics를 사용하여 문제를 더 큰 작업 단위로 그룹화하면서 문제를 사용하여 사용자 스토리, 버그 및 기능과 같은 항목을 추적하는 것이 좋습니다. 작업을 진행할 때 할 일, 수행 및 완료의 간단한 상태 워크플로를 따라 항목을 이동합니다.
새 프로젝트를 시작하는 데 도움이 되는 문제 및 작업 추적 설명서를 참조하세요.
Azure Pipelines
파이프라인 마법사에서의 GitHub Enterprise 지원
이전에는 시각적 디자이너를 사용하여 GitHub Enterprise 리포지토리에 대한 파이프라인을 만들 수 있습니다. 이제 새 빌드 파이프라인 마법사를 사용하여 파이프라인 을 만들 수도 있습니다.
마법사는 GitHub Enterprise 리포지토리를 분석하여 프로젝트 언어와 일치하는 YAML 템플릿을 제안합니다. 그런 다음 YAML을 편집하고 기본 분기 직접 커밋 또는 끌어오기 요청으로 저장할 수 있습니다.
자세한 내용은 여기에서 첫 번째 파이프라인 을 만드는 방법에 대한 설명서를 참조하세요.
파이프라인에서의 자동 GitHub 서비스 연결
새 빌드 파이프라인 마법사를 사용하여 GitHub용 파이프라인을 만들 때 GitHub 서비스 연결을 선택하거나 만들기 위한 페이지가 목록에서 선택할 연결에 대한 혼동을 일으켰습니다. 이제 연결을 선택할 필요가 없습니다. 마법사는 선택한 리포지토리에 대한 서비스 연결을 자동으로 만들고 다시 사용합니다.
자동으로 선택된 연결 이외의 연결을 수동으로 선택하려면 연결 선택 하이퍼링크를 따릅니다. 자세한 내용은 GitHub 리포지토리 빌드를 참조 하세요.
참고 항목
선택은 Azure Pipelines GitHub 앱(리포지토리에 설치된 경우) 또는 개인 GitHub ID(OAuth 사용)를 기반으로 합니다.
GitHub Checks에서 각 파이프라인 작업의 상태 표시
이전에는 여러 플랫폼(예: Linux, macOS 및 Windows)에 대한 작업이 포함된 경우에도 파이프라인에 대한 단일 빌드 상태 GitHub Check에 게시되었습니다. 이제 상태 파이프라인의 각 작업에 대한 GitHub 검사에 게시됩니다. 또한 GitHub Check에서 전체 빌드 또는 실패한 개별 작업만 다시 실행할 수 있습니다. 이 기능을 사용하려면 Azure Pipelines GitHub 앱을 사용하도록 파이프라인을 구성해야 합니다. 자세한 내용은 GitHub 앱을 사용하여 통합을 참조 하세요. 여러 플랫폼에 대한 작업이 있는 파이프라인을 설정하려면 다중 플랫폼 파이프라인 만들기를 참조하세요.
GitHub에서 YAML 리소스의 기본 권한 부여
GitHub에서 소스 코드를 관리하고 YAML을 사용하여 파이프라인을 정의하는 경우 리소스 권한 부여 빌드 실패가 발생할 수 있습니다. YAML 파일을 편집하고 보호된 리소스 중 하나(예: 서비스 연결, 에이전트 풀, 변수 그룹 또는 보안 파일) 중 하나에 대한 참조를 추가한 경우 Azure Pipelines는 해당 변경을 수행하고 빌드에 실패한 사용자의 ID를 확인할 수 없습니다. 이 문제를 해결하려면 YAML 파일을 변경한 후 웹 편집기에서 빌드 파이프라인을 저장해야 했습니다. 이 문제를 해결한 많은 사용자는 모든 파이프라인에서 리소스를 사용하도록 허용하려고 했습니다.
리소스 권한 부여 빌드 실패를 방지하기 위해 모든 새 서비스 연결, 에이전트 풀 및 변수 그룹의 기본 동작을 모든 파이프라인에서 사용할 수 있도록 권한을 부여하도록 변경했습니다. 리소스에 대한 더 엄격한 제어를 원하는 경우 기본 권한 부여 모델을 사용하지 않도록 설정할 수 있습니다(아래 그림 참조). 이렇게 하면 리소스를 사용할 수 있는 권한이 있는 사용자가 YAML 파일에 리소스 참조를 추가한 후 웹 편집기에서 파이프라인을 저장해야 합니다.
YAML 파이프라인의 서비스 컨테이너
이전에는 YAML 파이프라인이 이러한 서비스를 사용하는 경우 데이터베이스 또는 메모리 캐시와 같은 서비스를 설치, 시작 및 중지해야 했습니다. 이 업데이트를 통해 이러한 작업을 처리할 수 있는 서비스 컨테이너를 추가했습니다. 예를 들어 파이프라인에서 통합 테스트에 redis 캐시를 사용하는 경우 redis 컨테이너 이미지를 파이프라인에 서비스로 포함할 수 있습니다. 에이전트는 이미지를 자동으로 가져오고, 시작하고, 네트워크로 연결하여 파이프라인 단계에서 호스트 이름 redis로 참조할 수 있도록 합니다. 파이프라인이 완료되면 에이전트는 클린 서비스 컨테이너를 스핀다운합니다.
릴리스 요약에서 GitHub 커밋에 연결된 작업 항목
12월에는 GitHub 커밋을 작업 항목에 연결하는 기능을 도입했습니다. 이제 릴리스 요약 페이지에서 GitHub 커밋에 연결된 모든 Azure Boards 작업 항목을 볼 수 있음을 알려드립니다. 이를 통해 팀은 환경에 배포된 커밋에 대한 자세한 정보를 추적하고 검색할 수 있습니다.
YAML에 최적화된 새 Azure 앱 서비스 작업
이제 최신 개발자를 염두에 두고 Azure 앱 Services를 배포하는 쉽고 강력한 방법을 제공하는 네 가지 새로운 작업을 지원합니다. 이러한 작업에는 최적화된 YAML 구문이 있으므로 Windows 및 Linux 플랫폼 모두에서 WebApps, FunctionApps, WebApps for Containers 및 컨테이너용 FunctionApp을 포함하여 Azure 앱 서비스에 대한 배포를 간단하고 직관적으로 작성할 수 있습니다.
또한 XML 및 JSON 형식에 대한 파일 변환 및 변수 대체를 위한 새 유틸리티 작업을 지원합니다.
Azure SQL 작업에 대한 Azure AD(Active Directory) 인증 지원
Azure SQL 작업은 SQL Server 인증에 대한 기존 지원 외에도 Azure AD(통합 및 암호) 및 연결 문자열 사용하여 데이터베이스에 연결할 수 있도록 지원하도록 향상되었습니다.
Grafana 주석 서비스 후크
이제 Grafana 대시보드에 배포 완료 이벤트에 대한 Grafana 주석을 추가할 수 있는 새 서비스 후크를 지원합니다. 이렇게 하면 Grafana 대시보드에서 시각화되는 애플리케이션 또는 인프라 메트릭의 변경 내용과 배포의 상관 관계를 지정할 수 있습니다.
Azure Monitor 경고 쿼리 작업
이전 버전의 Azure Monitors 쿼리 태스크 는 클래식 모니터링 환경에서만 경고 쿼리를 지원했습니다. 이 새 버전의 작업을 사용하면 Azure Monitor에서 최근에 도입한 통합 모니터링 환경에 대한 경고를 쿼리할 수 있습니다.
Kubernetes에 배포 작업에서 사양 파일의 인라인 입력
이전에는 Kubernetes 배포 작업에서 구성에 대한 파일 경로를 제공해야 했습니다. 이제 구성을 인라인으로 추가할 수도 있습니다.
Docker CLI 설치 관리자 작업
이 작업을 통해 사용자가 지정한 대로 에이전트에 모든 버전의 Docker CLI를 설치할 수 있습니다.
Microsoft 호스트된 에이전트의 Java LTS(장기 지원)
이전에는 Microsoft 호스팅 에이전트에 복잡한 라이선스, 최종 사용자 제한 및 장기 지원 부족으로 오버로드된 JDK가 미리 설치되어 있었습니다. 이 업데이트에서는 JDK를 Azul Systems의 테스트된 인증된 LTS OpenJDK 빌드로 대체했습니다. Azure를 사용하는 Java 개발자는 이제 추가 지원 비용 없이 OpenJDK의 Azul Systems Zulu Enterprise 빌드를 사용하여 프로덕션 Java 애플리케이션을 빌드하고 실행할 수 있습니다.
이 새로운 제품은 필요에 따라 중요한 대역 외 업데이트 및 패치뿐만 아니라 분기별 보안 업데이트 및 버그 수정을 통합하여 Microsoft 호스팅 Java 빌드 및 배포를 걱정 없이 만들도록 설계되었습니다. 현재 온-프레미스 또는 다른 JDK를 사용하여 Java 앱을 빌드하거나 실행하는 경우 무료 지원 및 기본 테넌트 지원을 위해 Azure의 Zulu로 이동하는 것이 좋습니다. 자세한 내용은 Microsoft 및 Azul Systems가 Azure에 무료 Java LTS 지원을 제공해 주는 블로그를 참조하세요.
Bitbucket Cloud 파이프라인의 YAML 지원
이전에는 YAML 기반 파이프라인이 Bitbucket Cloud를 지원하지 않았습니다. 이제 YAML을 사용하여 Bitbucket Cloud 파이프라인을 정의하거나 비주얼 디자이너를 사용하여 동일한 작업을 수행할 수 있습니다. YAML을 사용하려면 리포지토리에 azure-pipelines.yml 파일을 추가합니다. Azure Pipelines에서 새 빌드 파이프라인을 선택한 다음, 비주얼 디자이너 하이퍼링크 사용을 선택하고 "Bitbucket Cloud" 및 "YAML"을 선택합니다. 여기서 리포지토리의 YAML 파일 경로를 입력할 수 있습니다.
자세한 내용은 YAML 구문 가이드 및 YAML 샘플의 GitHub 리포지토리를 참조하세요.
끌어오기 요청의 여러 CI 빌드 트리거 방지
Azure Pipelines에 포함된 YAML 빌드 템플릿은 리포지토리 내의 모든 분기에 대한 빌드를 트리거하도록 구성되었습니다. 여기에는 끌어오기 요청 토픽 분기가 포함되었습니다. 결과적으로 끌어오기 요청을 만들 때 두 개의 빌드가 트리거되었습니다. 연속 통합 트리거에 대한 응답으로 끌어오기 요청 분기에 대한 빌드 하나와 끌어오기 요청 트리거에 대한 응답으로 끌어오기 요청 분기에 대한 두 번째 빌드입니다.
아래 YAML 코드 조각을 사용하면 기본 제공 YAML 템플릿이 마스터 분기에 대해서만 연속 통합 빌드를 트리거하도록 구성됩니다. 새 끌어오기 요청은 끌어오기 요청 트리거를 사용하여 빌드됩니다. 자세한 내용은 빌드 파이프라인 트리거에 대한 설명서를 참조하세요 .
trigger:
- main
포크된 리포지토리 빌드의 빌드 번호 변경, 아티팩트 업로드 및 다운로드
지금까지 포크된 리포지토리에 대한 끌어오기 요청 유효성 검사 빌드에는 빌드 아티팩트 업로드 및 다운로드 또는 빌드 번호를 변경할 수 있는 권한이 없었습니다. 알 수 없는 사용자가 트리거한 포크 빌드 중에 에이전트의 광범위한 사용 권한을 사용할 수 없도록 하기 위해 권한이 제한되었습니다. 이 업데이트를 사용하면 필요한 경우 파이프라인에서 이러한 작업을 수행할 수 있도록 에이전트 권한의 범위가 지정됩니다.
다음은 tar.gz 파일의 빌드 출력을 아티팩트 준비 디렉터리에 보관하는 데 사용할 수 있는 YAML의 예입니다. 그런 다음 빌드와 연결할 출력을 Azure Pipelines에 게시합니다. 자세한 내용은 파일 보관 태스크 및 빌드 아티팩트 게시 태스크에 대한 설명서를 참조하세요.
- task: ArchiveFiles@2
inputs:
archiveType: 'tar'
tarCompression: 'gz'
includeRootFolder: false
rootFolderOrFile: '$(build.sourcesDirectory)/target'
archiveFile: '$(build.artifactStagingDirectory)/$(build.buildId).tar.gz'
- task: PublishBuildArtifacts@1
inputs:
pathtoPublish: '$(build.artifactStagingDirectory)'
실패한 테스트의 빌드를 실패시키는, 테스트 결과 게시 작업의 새 옵션
테스트 결과 게시 작업은 선택한 테스트 실행기를 사용하여 테스트를 실행할 때 Azure Pipelines에 테스트 결과를 게시하는 데 사용됩니다. 지금까지 작업은 단순히 결과 파일의 결과를 게시하고 결과 파일에 실패한 테스트가 포함된 경우에도 빌드에 실패하지 않습니다. 즉, 테스트 실패 시 빌드가 실패하도록 사용자 지정 단계를 작성해야 했습니다.
이제 실패한 테스트가 있는 경우 빌드에 실패하는 옵션을 작업에 추가했습니다.
Azure DevOps 프로젝트를 만들기 위해 Azure Portal에 업데이트
이제 Azure Portal에는 Azure DevOps 프로젝트를 만들 때 더 많은 프레임워크 및 서비스를 지원하는 추가 기능이 포함되어 있습니다. 다음은 각 영역에 대한 변경 내용 목록입니다.
프레임워크
Azure IoT는 플랫폼 간 IoT 디바이스에서 로컬로 클라우드 인텔리전스를 제공하는 완전 관리형 서비스입니다. 이제 Azure Portal에서 Azure DevOps 프로젝트를 만들고 간단한 IoT를 애플리케이션 프레임워크로 사용할 수 있습니다.
서비스
이전에는 Azure Portal에서 Azure DevOps Project 만들기 워크플로에서 Kubernetes Service에 대한 옵션으로 새로 만들기만 지원했습니다. 파이프라인 설정의 배포 대상으로 기존 클러스터를 선택할 수 있도록 새 옵션이 추가되었습니다.
Azure Portal을 사용하여 CosmosDB 데이터베이스 설정 및 배포
현재 Azure Portal에서 Azure DevOps Project 워크플로를 사용하여 Git 리포지토리에 대한 빌드 및 릴리스 파이프라인을 설정할 수 있습니다. 이제 이러한 대상에서 앱을 지원하는 데이터베이스로 프로비전된 CosmosDB를 사용하여 Azure Web App for Containers(Linux) 또는 Azure Kubernetes Service에 배포할 수 있습니다. 이는 현재 모든 Node.js 템플릿에 사용할 수 있으며 향후 다른 템플릿에 대한 지원을 추가할 예정입니다.
Azure Portal에서 Functions에 대한 빌드 및 릴리스 파이프라인 설정
이제 Azure Portal에서 Azure DevOps Project 워크플로를 사용하여 Azure Functions 2.0(Windows)을 배포하는 Git 리포지토리에 대한 빌드 및 릴리스 파이프라인을 설정할 수 있습니다. 이 기능은 Node.js 및 .NET Core에서 사용할 수 있습니다.
Azure Artifacts
패키지 사용량 통계
지금까지 Azure Artifacts는 패키지의 사용량 또는 인기를 측정하는 방법을 제공하지 않았습니다. 이 업데이트를 통해 패키지 목록 및 패키지 세부 정보 페이지에 다운로드 및 사용자 수를 추가했습니다. 두 페이지의 오른쪽에서 통계를 볼 수 있습니다.
Wiki
Wiki Markdown 편집기용 모노스페이스 글꼴
위키 Markdown 편집기용 모노스페이스 글꼴이 도입되면 가독성이 더 이상 문제가 되지 않습니다. Markdown 원본은 클린 보기 쉽고 읽기 쉽습니다. 이 기능은 이 제안 티켓에 따라 우선 순위가 지정되었습니다.
굵게 위키 페이지 제목
이전에는 Wiki 페이지 제목과 헤더 1이 모두 동일하게 보였습니다. 이로 인해 독자가 구별하기가 어려웠습니다. 이제 위키 페이지 제목이 머리글 1과 굵게 구분되었습니다. 이 기능은 이 제안 티켓에 따라 우선 순위가 지정되었습니다.
Markdown 테이블 삽입
위키에서 Markdown 테이블을 만드는 것은 더 이상 문제가 되지 않습니다. 이제 단추를 클릭하여 Markdown 테이블을 추가할 수 있습니다. 이 기능은 이 기능 제안 티켓에 따라 우선 순위가 지정되었습니다.
Wiki에 Azure Boards 쿼리 결과 포함
이제 테이블 형식으로 위키 페이지에 Azure Boards 쿼리 결과를 포함할 수 있습니다. 아래 이미지는 릴리스된 모든 기능 목록과 위키에 포함된 현재 스프린트의 모든 활성 버그가 포함된 위키 페이지의 샘플을 보여 줍니다. 페이지에 표시되는 콘텐츠는 기존 작업 항목 쿼리를 사용하고 있습니다. 이 새로운 기능을 사용하면 동적 콘텐츠를 만들 수 있으며 위키 페이지를 수동으로 업데이트하는 것에 대해 걱정할 필요가 없습니다.
쿼리 결과는 두 단계로 추가할 수 있습니다.
- 편집 도구 모음에서 "쿼리 결과" 단추를 클릭합니다.
- 필요한 쿼리를 선택하고 "삽입" 단추를 클릭합니다.
이제 페이지를 저장한 후 쿼리 결과를 테이블 형식으로 볼 수 있습니다.
이는 다음 기능 제안에 따라 우선 순위가 지정되었습니다.
다음 단계
참고 항목
이러한 기능은 향후 2~3주 동안 출시될 예정입니다.
아래의 새로운 기능에 대해 읽고 Azure DevOps로 이동하여 직접 사용해 보세요.
피드백을 제공하는 방법
이러한 기능에 대해 어떻게 생각하는지 듣고 싶습니다. 피드백 메뉴를 사용하여 문제를 보고하거나 제안을 제공합니다.
Stack Overflow에서 커뮤니티에서 조언과 질문에 답변할 수도 있습니다.
감사합니다,
제레미 에블링