스프린트 132 VSTS(Visual Studio Team Services 업데이트)는 빌드 및 릴리스 파이프라인의 크기를 조정하는 데 도움이 되는 몇 가지 주요 기능을 제공합니다. 빌드에서 새 빌드 완료 트리거를 사용하여 서로 다른 팀이 소유할 수 있는 관련 빌드를 연결합니다. 릴리스에서는 프로덕션 환경을 포함하여 고가용성을 갖춘 여러 가상 머신에서 배포 크기를 조정하는 데 사용할 수 있는 배포 그룹의 일반 공급에 대해 발표합니다.
그 외 중요 사항은 다음과 같습니다.
VSTS의 새로운 기능
기능
코드
빌드 및 릴리스
패키지
Wiki
보고
코드
커밋 메시지를 사용하여 끌어오기 요청 빠르게 설명
설명이 포함된 커밋 메시지를 작성하면 Git 리포지토리의 기록에 값이 추가됩니다. 품질 커밋 메시지를 장려하기 위해 여러 커밋이 있는 새 PR(끌어오기 요청)을 사용하려면 기여자가 수동으로 타이틀을 입력해야 합니다.
끌어오기 요청 설명은 기본적으로 계속 비어 있지만 새 기능을 사용하면 PR 커밋의 커밋 메시지를 PR 설명에 더 쉽게 통합할 수 있습니다. 커밋 메시지를 추가하려면 커밋 메시지 추가 를 클릭하여 PR 설명 텍스트의 끝에 커밋 메시지를 추가하기만 하면 됩니다.
Windows 탐색기에서 바로 수행하는 TFVC 명령
Windows 파일 탐색기 통합된 경량 버전 제어 환경을 제공하는 TFVC Windows 셸 확장은 이제 VSTS 및 TFS 2018을 지원합니다. 이 도구는 Windows 탐색기 바로 가기 메뉴에서 직접 다양한 TFVC 명령에 편리하게 액세스할 수 있습니다.
TFS 성능 도구의 일부였던 이 도구는 Visual Studio Marketplace에서 독립 실행형 도구로 릴리스되었습니다.
빌드 및 릴리스
빌드 완료 트리거를 사용하여 관련 빌드를 함께 연결
대형 제품에는 서로 종속된 여러 구성 요소가 있습니다. 이러한 구성 요소는 종종 독립적으로 빌드됩니다. 업스트림 구성 요소(예: 라이브러리)가 변경되면 다운스트림 종속성을 다시 빌드하고 유효성을 다시 검사해야 합니다. 팀은 일반적으로 이러한 종속성을 수동으로 관리합니다.
이제 다른 빌드를 성공적으로 완료하면 빌드를 트리거할 수 있습니다. 업스트림 빌드에서 생성된 아티팩트를 다운로드하여 이후 빌드에서 사용할 수 있으며, Build.TriggeredBy.BuildId, Build.TriggeredBy.DefinitionId, Build.TriggeredBy.BuildDefinitionName 변수에서 데이터를 가져올 수도 있습니다. 자세한 내용은 빌드 트리거 설명서를 참조하세요.
이 기능은 현재 1,129표로 가장 높은 투표 제안 2위를 기록한 것에 따라 우선 순위가 지정되었습니다.
경우에 따라 단일 다단계 빌드 가 요구 사항을 충족할 수 있습니다. 그러나 빌드 완료 트리거는 요구 사항에 종속 프로세스를 소유하는 다른 구성 설정, 옵션 또는 다른 팀이 포함된 경우에 유용합니다.
배포 그룹을 사용하여 VM으로 배포 크기 조정
강력한 기본 제공 다중 컴퓨터 배포를 제공하는 배포 그룹이 이제 출시되었습니다. 배포 그룹을 사용하면 전체적으로 애플리케이션의 고가용성을 보장하면서 여러 서버에서 배포를 오케스트레이션하고 롤링 업데이트를 수행할 수 있습니다. 온-프레미스나 Azure 또는 클라우드의 가상 머신에 서버를 배포할 수도 있으며, 배포된 아티팩트 버전을 서버 수준까지 통합 추적할 수 있습니다.
에이전트 기반 배포 기능은 이미 사용 가능한 동일한 빌드 및 배포 에이전트에 의존합니다. 배포 그룹 단계에서 대상 컴퓨터의 전체 작업 카탈로그를 사용할 수 있습니다. 확장성 관점에서 프로그래밍 방식 액세스에 대해 배포 그룹 및 대상의 REST API를 사용할 수도 있습니다.
공유 배포 대상
동일한 서버를 사용하여 여러 애플리케이션을 호스트하는 경우 배포 풀을 사용하여 팀 프로젝트에서 서버(배포 대상이라고도 함)를 공유할 수 있습니다.
새 템플릿
이제 새 릴리스 정의 템플릿을 사용하여 여러 대상에 배포하는 것이 좋습니다. IIS 웹 사이트에 대한 여러 템플릿, 데이터베이스가 있는 IIS 웹 사이트 및 SQL DB용 여러 배포 템플릿을 기본으로 사용할 수 있습니다.
VM 프로비전
향상된 Azure 리소스 그룹 작업을 사용하여 Azure에서 새로 프로비전되거나 기존 Virtual Machines 에이전트를 동적으로 부트스트랩합니다.
지난 5월에 배포 그룹을 시작했을 때 몇 가지 주요 시나리오를 대상으로 하는 간단한 사용자 인터페이스를 제공했습니다. 이제 제품의 나머지 부분처럼 느껴지는 보다 일관된 인터페이스를 찾을 수 있습니다.
시작에 대한 자세한 내용은 배포 그룹 설명서를 참조하세요.
Go로 작성된 애플리케이션 빌드
이제 VSTS에서 Go 애플리케이션을 빌드할 수 있습니다.
Go 도구 설치 관리자 작업을 사용하여 하나 이상의 Go Tool 버전을 즉시 설치합니다. 이 작업은 프로젝트에 필요한 특정 버전의 Go Tool을 획득하고 빌드 에이전트의 PATH에 추가합니다. 대상 Go Tool 버전이 에이전트에 이미 설치된 경우 이 작업은 다운로드하여 다시 설치하는 프로세스를 건너뜁니다.
Go 작업은 종속성을 다운로드하거나, 애플리케이션을 빌드하거나, 테스트하는 데 도움이 됩니다. 이 작업을 사용하여 원하는 사용자 지정 Go 명령을 실행할 수도 있습니다.
작업 확장을 사용하여 릴리스 게이트 확장
릴리스 게이트 는 상태 신호 정보를 릴리스 파이프라인으로 바로 가져옵니다. 게이트는 배포 전후에 일련의 상태 신호를 반복적으로 수집하여 릴리스가 다음 단계로 진행되어야 하는지 여부를 결정합니다. 기본 제공 게이트 집합이 제공되며, 지금까지 다른 서비스를 통합하기 위해 Azure Function 호출 옵션이 권장되었습니다.
이제 게이트는 확장 형식으로 제공되며, 이를 통해 사용자 또는 확장 작성자가 새 서비스 또는 사용자 지정 서비스를 통합하고 게이트를 더 쉽게 구성할 수 있습니다.
자세한 내용은 작성 게이트 작업 설명서를 참조하세요.
패키지
VSTS의 다른 위치에서 업스트림 npm 패키지 사용
계속해서 업스트림 원본에 투자하여 모든 패키지 종속성을 단일 피드에 중앙 집중화하고 사용하는 모든 패키지의 저장된 복사본을 유지할 수 있습니다. npm 패키지가 포함된 VSTS 피드가 여러 개 있는 경우 이제 동일한 VSTS 계정 내에서 다른 피드를 업스트림 원본으로 추가할 수 있습니다. npm은 주로 프로젝트 구성에서 단일 피드/레지스트리로 제한되므로 업스트림 원본은 각 팀 또는 제품에 대해 하나씩과 같은 여러 npm 피드를 사용하는 데 필요한 유연성을 제공합니다.
또한 곧 VSTS NuGet 피드에 대한 업스트림 원본을 사용하도록 설정하기 위해 노력하고 있습니다. 자세한 내용은 업스트림 원본 설명서를 참조하세요.
보존 정책을 사용하여 피드 쿼리 속도 유지 관리
시간이 지남에 따라 패키지 버전 수가 광범위해질 수 있으며 이전 버전은 사용되지 않습니다. 빈번한 패키지 게시자의 경우 일부 버전을 수동으로 삭제할 때까지 NuGet 패키지 관리자 및 다른 클라이언트의 피드 쿼리 속도가 느려질 수 있습니다.
이제 피드에서 보존 정책을 사용하도록 설정할 수 있습니다. 보존 임계값이 충족되면 보존 정책에서 가장 오래된 버전의 패키지를 자동으로 삭제합니다. 보기로 승격된 패키지는 무기한 보존되므로 프로덕션 환경에서 사용되거나 조직 전체에서 널리 사용되는 버전을 보호할 수 있습니다.
보존 정책을 사용하도록 설정하려면 피드를 편집하고 보존 정책 섹션의 패키지당 최대 버전 수에 값을 입력합니다.
Wiki
Git 리포지토리에서 Markdown 파일을 Wiki로 게시
개발자는 코드 리포지토리에서 "API", "SDK" 및 "코드 설명 도움말 문서"에 대한 설명서를 만듭니다. 그런 다음 읽기 권한자는 올바른 설명서를 찾기 위해 코드를 검색해야 합니다. 이제 코드 리포지토리에서 Markdown 파일을 게시하고 Wiki에서 호스트할 수 있습니다.
Wiki 내에서 먼저 코드 게시를 wiki로 클릭합니다. 다음으로, 승격해야 하는 Git 리포지토리에 폴더를 지정할 수 있습니다.
게시를 클릭하면 선택한 폴더 아래의 모든 Markdown 파일이 wiki로 게시됩니다. 또한 Git 리포지토리에 대한 변경 내용이 즉시 반영되도록 분기의 헤드를 wiki에 매핑합니다.
제품의 여러 버전이 있고 이러한 버전의 설명서를 쉽게 살펴보려는 경우 다른 분기를 사용하여 새 버전의 설명서를 Wiki에 게시할 수도 있습니다.
Markdown 파일이 게시되면 위키 검색 허브에서도 페이지를 검색할 수 있습니다.
잘못된 리포지토리를 게시한 경우 위키를 게시 취소하면 기본 리포지토리가 변경되지 않습니다.
리포지토리에서 페이지의 순서를 변경하거나 폴더를 위키 페이지처럼 보이도록 변환할 수도 있습니다.
자세한 내용은 제품 설명서 블로그 게시물을 참조하세요. 이 기능은 제안에 따라 우선 순위가 지정되었습니다.
Wiki 페이지 제목에 특수 문자 유지
이제 와 같은 : < > * ? | -특수 문자를 사용하여 위키 페이지를 만들 수 있습니다. 이제 Wiki에서 "FAQ?" 또는 "설정 가이드"와 같은 제목이 있는 페이지를 만들 수 있습니다. 다음 문자는 UTF-8로 인코딩된 문자열로 변환됩니다.
| 문자 | 인코딩된 문자열 |
|---|---|
| : | %3A |
| < | %3C |
| > | %3E |
| * | %2A |
| ? | %3F |
| | | %7C |
| - | %2D |
이 기능은 제안에 따라 우선 순위가 지정되었습니다.
REST API를 사용하여 Wiki 확장
이제 Wiki REST API가 공개됩니다. 자세한 내용은 Wiki 함수 및 Wiki 검색 설명서를 참조하세요.
보고
보기를 사용하여 VSTS Analytics와 Power BI 통합
분석 뷰는 VSTS Power BI 데이터 커넥터에서 작동합니다. 함께 사용하면 사용자 지정 보고서 만들기를 시작할 수 있도록 VSTS 데이터를 Power BI로 쉽게 가져올 수 있습니다.
VSTS Analytics 확장을 설치할 때 Power BI에서 사용할 수 있는 기본 분석 뷰 집합을 만듭니다. 이제 기본 보기를 편집하고 새 보기를 만들어 Power BI로 반환된 레코드, 필드 및 기록을 미세 조정할 수 있습니다.
다음 단계 및 피드백
이러한 기능에 대해 어떻게 생각하는지 듣고 싶습니다. 피드백 메뉴를 통해 우선 순위를 지정하려는 항목에 대한 아이디어가 있는 경우 문제를 보고하거나 제안을 제공합니다.
Stack Overflow에서 커뮤니티에서 조언과 질문에 답변할 수도 있습니다.
감사합니다,
고피나스 치악카가리