Azure DevOps의 Sprint 144 업데이트 에서는 GitHub와의 통합을 계속 확장합니다. 이제 GitHub 커밋을 연결하고 요청을 Azure Boards 작업 항목에 끌어올 수 있습니다. GitHub 및 Azure Boards를 연결하면 백로그, 보드, 스프린트 계획 도구 및 여러 작업 항목 유형과 같은 기능에 액세스할 수 있는 풍부한 프로젝트 관리 기능을 얻을 수 있습니다.
자세한 내용은 아래 기능 목록을 확인하세요.
기능
Azure Boards:
- GitHub 커밋 및 끌어오기 요청을 Azure Boards 작업 항목에 연결 - Sprint 144 업데이트
Azure Repos:
Azure Pipelines:
- GitHub 커밋 및 끌어오기 요청을 Azure Boards 작업 항목에 연결 - Sprint 144 업데이트
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에 있든 관계없이 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 Change Management 통합
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 (Azure의 아티팩트)
PyPI 공개 미리 보기
이제 Azure Artifacts에서 Python 패키지를 호스트할 수 있습니다. 여기에는 공용 PyPI에서 저장된 패키지를 생성하고 업스트림하는 패키지가 포함됩니다. 자세한 내용은 공지 블로그 게시물 및 설명서를 참조하세요.
이제 동일한 피드에서 모든 NuGet, npm, Maven, Python 및 유니버설 패키지를 호스트할 수 있습니다.
General
Service Health 포털
서비스의 상태를 따르기 위한 더 나은 환경을 제공하는 새 Azure DevOps Service 상태 포털을 추가했습니다. Microsoft 서비스에 문제가 발생하는 경우 여기에서 서비스 상태를 확인할 수 있습니다.
자세한 내용은 공지 블로그 게시물 및 설명서를 참조하세요.
Wiki
수식 및 비디오에 대한 Markdown 템플릿
Wiki를 편집할 때 수식, 비디오 및 YAML 태그 를 추가하기 위한 Markdown 구문을 더 이상 기억할 필요가 없습니다. 이제 도구 모음에서 상황에 맞는 메뉴를 클릭하고 원하는 옵션을 선택할 수 있습니다.
Administration
삭제된 프로젝트 복원
이 릴리스에서는 삭제된 프로젝트를 복원하는 기능을 추가했습니다. 현재 삭제 프로젝트 권한이 있는 사용자는 REST API를 통해 삭제된 프로젝트를 복원할 수 있습니다. 이렇게 하려면 { "state": "wellFormed" }를 사용하여 업데이트 프로젝트 요청을 만듭니다. 향후 릴리스에서는 조직 개요 페이지에서 액세스할 수 있는 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에서 커뮤니티로부터 조언을 받고 질문에 대한 답변을 얻을 수도 있습니다.
감사
아론 비요크