GitHub 커밋 및 끌어오기 요청을 Azure Boards 작업 항목에 연결 - 스프린트 144 업데이트
Azure DevOps의 스프린트 144 업데이트 에서는 GitHub와의 통합을 계속 확장합니다. 이제 GitHub 커밋 및 끌어오기 요청을 Azure Boards 작업 항목에 연결할 수 있습니다. GitHub 및 Azure Boards 연결하면 백로그, 보드, 스프린트 계획 도구 및 여러 작업 항목 유형과 같은 기능에 액세스할 수 있는 풍부한 프로젝트 관리 기능을 얻을 수 있습니다.
자세한 내용은 아래 기능 목록을 확인하세요.
기능
Azure Boards:
Azure Repos:
Azure Pipelines:
- 파이프라인을 사용하여 GitHub 릴리스 관리
- YAML 기반 파이프라인에 대한 VS Code 확장
- YAML 파이프라인용 IntelliSense를 사용하는 웹 편집기
- ServiceNow 변경 관리 통합
- 빌드 로그의 특정 줄에 대한 링크
- 단일 파일에서 다중 플랫폼 파이프라인 지정
- 실패 시 자동으로 다시 배포
Azure Artifacts:
일반:
Wiki:
관리:
Azure Boards
GitHub 커밋 및 끌어오기 요청을 Azure Boards 작업 항목에 연결
코드에 GitHub를 사용하고 풍부한 프로젝트 관리 기능을 원하는 팀은 이제 리포지토리를 Azure Boards 통합할 수 있습니다. GitHub 및 Azure Boards 연결하면 백로그, 보드, 스프린트 계획 도구, 여러 작업 항목 유형과 같은 모든 기능을 얻을 수 있으며 GitHub의 개발자 워크플로와 통합되는 워크플로를 계속 사용할 수 있습니다.
커밋 및 끌어오기 요청을 작업 항목에 쉽게 연결할 수 있습니다. 다음 구문을 사용하여 작업 항목을 언급합니다.
AB#{work item ID}
커밋 메시지 작업 항목, 끌어오기 요청 제목 또는 끌어오기 요청 설명을 언급하면 Azure Boards 해당 아티팩트 링크를 만듭니다. 예를 들어 다음과 같은 커밋 메시지 고려합니다.
Adds support for deleting connections. Fixes AB#20.
그러면 작업 항목 #20에서 GitHub의 커밋에 대한 링크가 만들어지며, 이 링크는 작업 항목의 개발 섹션에 표시됩니다.
위와 같이 작업 항목 멘션 앞에 "fix", "fixes" 또는 "fixed"라는 단어가 있으면 커밋이 기본 분기 병합될 때 작업 항목이 완료된 상태로 이동됩니다.
Azure Pipelines를 사용하여 GitHub에서 코드를 빌드하는 팀은 빌드 요약에서 GitHub 커밋에 연결된 작업 항목도 볼 수 있습니다.
서비스로 Azure Boards 획득
이제 Azure Boards 쉽게 획득하고 자체 서비스로 사용할 수 있습니다. 코드가 Azure Repos 또는 GitHub에 있든 관계없이 'Azure Boards 시작'으로 이동하여 https://www.azure.com/boards 빠르게 시작할 수 있습니다. 새 사용자는 Azure Boards 있는 프로젝트와 실행 중인 땅에 부딪히는 데 도움이 되는 소개를 받게 됩니다.
Azure Repos
자동 완성 끌어오기 요청에 대해 만료된 빌드 다시 실행
이제 Azure Repos 끌어오기 요청 정책에 의해 트리거된 만료된 빌드를 자동으로 큐에 대기합니다. 이는 다른 모든 정책을 통과하고 자동 완성으로 설정된 끌어오기 요청에 적용됩니다. 이전에는 끌어오기 요청에 필요한 검토자와 같은 정책이 있는 경우 승인 프로세스가 너무 오래 걸리고 검토자가 끌어오기 요청을 승인하기 전에 연결된 빌드가 만료될 수 있었습니다. 끌어오기 요청이 자동 완료로 설정된 경우 사용자가 만료된 빌드를 수동으로 큐에 대기할 때까지 차단된 상태로 유지됩니다. 이 변경을 사용하면 빌드가 성공적으로 빌드된 후 끌어오기 요청이 자동으로 완료될 수 있도록 빌드가 자동으로 큐에 대기됩니다.
참고
이 자동화는 끌어오기 요청당 최대 5개의 만료된 빌드만 큐에 대기하고 각 빌드를 한 번만 다시 큐에 대기하려고 시도합니다.
Azure Pipelines
파이프라인을 사용하여 GitHub 릴리스 관리
GitHub 릴리스는 사용자에게 소프트웨어를 패키지하고 제공하는 좋은 방법입니다. 이제 Azure Pipelines에서 GitHub 릴리스 작업을 사용하여 자동화할 수 있음을 발표하게 되어 기쁩니다. 작업을 사용하여 새 릴리스를 만들거나, 기존 초안/게시된 릴리스를 수정하거나, 이전 릴리스를 삭제할 수 있습니다. 여러 자산을 업로드하고, 릴리스를 시험판으로 표시하고, 릴리스를 초안으로 저장하는 등의 기능을 지원합니다. 이 작업은 릴리스 정보를 만드는 데도 도움이 됩니다. 또한 이 릴리스에서 수행된 변경 내용(커밋 및 관련 문제)을 자동으로 계산하고 사용자에게 친숙한 형식으로 릴리스 정보에 추가할 수도 있습니다.
작업에 대한 간단한 YAML은 다음과 같습니다.
task: GithubRelease@0
displayName: 'Create GitHub Release'
inputs:
githubConnection: zenithworks
repositoryName: zenithworks/pipelines-java
assets: $(build.artifactstagingdirectory)/*.jar
이 작업을 사용하여 만든 샘플 GitHub 릴리스:
YAML 기반 파이프라인에 대한 VS Code 확장
코딩 프로세스 속도를 높이기 위해 YAML 파이프라인에 대한 VS Code 확장을 추가했습니다. 확장은 구문 강조 표시 및 IntelliSense(코드 완성)를 지원하여 파일이 올바르게 구조화되고 유효한 키워드를 사용하는지 확인합니다. 또한 기본 제공 작업을 지원하고 필요한 입력의 유효성을 검사할 수 있습니다.
확장은 GitHub의 오픈 소스 프로젝트이며 커뮤니티의 피드백, 버그 보고서 및 기여 환영합니다.
YAML 파이프라인용 IntelliSense를 사용하는 웹 편집기
YAML을 사용하여 파이프라인을 정의하는 경우 이제 이 릴리스에 도입된 새 편집기 기능을 활용할 수 있습니다. 새 YAML 파이프라인을 만들든 기존 YAML 파이프라인을 편집하든 간에 파이프라인 웹 편집기 내에서 YAML 파일을 편집할 수 있습니다. YAML 파일을 편집할 때 IntelliSense용 Ctrl+Space 지원을 사용합니다. 구문 오류가 강조 표시되고 해당 오류를 수정하는 데도 도움이 됩니다.
ServiceNow 변경 관리 통합
ServiceNow와 원활하게 통합하여 프로덕션 배포의 지연을 제거합니다. ServiceNow와 협력하여 Azure Pipelines는 ServiceNow 변경 관리 확장의 공개 가용성을 발표하여 릴리스 파이프라인이 ServiceNow의 변경 관리 프로세스를 인식하게 합니다.
ServiceNow 변경 관리를 릴리스 게이트로 사용하면 ServiceNow에서 변경 관리 프로세스를 시작하고 변경 내용이 구현될 준비가 될 때까지 두 단계 간에 파이프라인을 유지할 수 있습니다.
또한 배포 프로세스에서 ServiceNow 변경 요청 작업을 업데이트할 수 있으며 ServiceNow 변경 요청은 배포의 상태 결과와 함께 업데이트됩니다. 이렇게 하면 ServiceNow와 Azure Pipelines 간에 전체 양방향 통합이 표시됩니다.
빌드 로그의 특정 줄에 대한 링크
이제 빌드 로그의 특정 줄에 대한 링크를 공유할 수 있습니다. 이렇게 하면 빌드 실패를 진단하는 데 다른 팀 구성원과 공동 작업할 때 도움이 됩니다. 결과 보기에서 로그 줄을 선택하여 링크 아이콘을 가져옵니다.
단일 파일에서 다중 플랫폼 파이프라인 지정
Azure Pipelines는 Linux, macOS 및 Windows 에이전트를 위한 호스트된 풀을 제공합니다. 이전에는 호스트된 세 풀에서 동일한 파이프라인 단계를 다시 사용하려면 별도의 템플릿 파일에서 단계를 지정해야 했습니다. 단일 파일에서 다중 플랫폼 파이프라인 및 행렬 전략을 지정할 수 있도록 해당 요구 사항을 제거했습니다.
strategy:
matrix:
win:
vm: windows-latest
mac:
vm: macOS-latest
linux:
vm: ubuntu-latest
pool:
vmImage: $(vm)
steps:
- script: npm install
- script: npm run test
실패 시 자동으로 다시 배포
스테이지에 대한 배포가 실패하면 이제 Azure Pipelines에서 마지막으로 성공한 배포를 자동으로 다시 배포할 수 있습니다. 배포 후 조건에서자동 재배포 트리거를 구성하여 마지막으로 성공한 릴리스를 자동으로 배포하도록 스테이지를 구성할 수 있습니다. 향후 스프린트에서 트리거된 이벤트 및 작업을 자동 재배포 구성에 추가할 계획입니다. 자세한 내용은 배포 그룹 설명서를 참조하세요.
Azure Artifacts
PyPI 공개 미리 보기
이제 Azure Artifacts에서 Python 패키지를 호스트할 수 있습니다. 여기에는 공용 PyPI에서 저장된 패키지를 생성하고 업스트림 패키지가 포함됩니다. 자세한 내용은 알림 블로그 게시물 및 설명서를 참조하세요.
이제 모든 NuGet, npm, Maven, Python 및 유니버설 패키지를 동일한 피드에 호스트할 수 있습니다.
일반
서비스 상태 포털
서비스의 상태를 따르기 위한 더 나은 환경을 제공하는 새 Azure DevOps Service 상태 포털을 추가했습니다. 서비스 상태에 문제가 발생하는 경우 여기에서 서비스 상태를 검사 수 있습니다.
자세한 내용은 알림 블로그 게시물 및 설명서를 참조하세요.
Wiki
수식 및 비디오에 대한 Markdown 템플릿
Wiki를 편집할 때 수식, 비디오 및 YAML 태그 를 추가하기 위한 Markdown 구문을 더 이상 기억할 필요가 없습니다. 이제 도구 모음에서 상황에 맞는 메뉴를 클릭하고 원하는 옵션을 선택할 수 있습니다.
관리
삭제된 프로젝트 복원
이 릴리스에서는 삭제된 프로젝트를 복원하는 기능을 추가했습니다. 현재 삭제 프로젝트 권한이 있는 사용자는 REST API를 통해 삭제된 프로젝트를 복원할 수 있습니다. 이렇게 하려면 { "state" : "wellFormed" }를 사용하여 업데이트 프로젝트 요청을 만듭니다. 이후 릴리스에서는 organization 개요 페이지에서 액세스할 수 있는 UI를 추가할 예정입니다. REST API에 대한 자세한 내용은 여기 설명서를 참조 하세요.
삭제된 프로젝트 목록을 얻으려면 다음 요청을 사용합니다.
GET https://dev.azure.com/{organization}/_apis/projects?stateFilter=deleted&api-version=5.0-preview.3
삭제된 프로젝트를 복원하려면 다음 요청을 사용합니다.
PATCH https://dev.azure.com/{organization}/_apis/projects/{projectId}?api-version=5.0-preview.3
요청 본문
{
"state" : "wellFormed"
}
참고
삭제된 프로젝트를 복원하는 데 최대 28일밖에 없습니다. 28일이 지나면 프로젝트가 영구적으로 삭제됩니다.
다음 단계
참고
이러한 기능은 향후 2~3주 동안 출시될 예정입니다.
아래의 새로운 기능에 대해 읽고 Azure DevOps로 이동하여 직접 사용해 보세요.
피드백을 제공하는 방법
이러한 기능에 대해 어떻게 생각하는지 듣고 싶습니다. 피드백 메뉴를 사용하여 문제를 보고하거나 제안을 제공합니다.
Stack Overflow에서 커뮤니티에서 조언과 질문에 답변할 수도 있습니다.
감사합니다,
아론 비요크