Team Foundation Server 2018 릴리스 정보
Developer Community | 시스템 요구 사항 및 호환성 | 사용 조건 | TFS DevOps 블로그 | SHA-1 해시 | 최신 Visual Studio 2019 릴리스 정보
참고 항목
영어 이외의 언어 버전에서 이 페이지에 액세스하는 경우 최신 콘텐츠를 보려면 영문 릴리스 정보 페이지를 방문하십시오. 페이지 바닥글에서 지구본 아이콘을 클릭하고 원하는 언어를 선택하여 이 페이지의 언어를 변경할 수 있습니다.
이 아티클에서는 Team Foundation Server 2018에 대한 정보가 제공됩니다. 단추를 클릭하여 다운로드합니다.
Team Foundation Server 2018에 대한 자세한 내용은 Team Foundation Server 요구 사항 및 호환성 페이지를 참조하세요. visualstudio.com/downloads 페이지를 방문하여 다른 TFS 2018 제품을 다운로드하세요.
자세한 정보는 TFS 설치 페이지를 참조하세요.
릴리스 날짜: 2017년 11월 15일
TFS 2018의 새로운 기능에 대한 요약
Team Foundation Server 2018에는 새로운 가치가 많이 추가되었습니다. 몇 가지 중요한 기능은 다음과 같습니다.
- 웹의 프로젝트 만들기 마법사 및 프로세스 템플릿 관리자를 개선했습니다.
- 이제 작업 항목 폼 헤더를 사용자 지정할 수 있습니다.
- 모바일 작업 항목 폼을 최적화했습니다.
- Git 포크를 추가로 지원합니다.
- GVFS로 대규모 Git 리포지토리를 관리할 수 있습니다.
- Git 태그의 보안을 보고, 필터링하고, 삭제하고 설정할 수 있습니다.
- 웹 코드 편집에 파일 미니 맵, 대괄호 일치 및 공백 설정/해제를 추가했습니다.
- 끌어오기 요청을 대폭 개선했습니다.
- Wiki 환경을 새롭게 개선했습니다.
- Maven 패키지에 대한 지원을 추가했습니다.
- 빌드 정의를 가져오고 내보내고일시 중지할 수 있습니다.
- 새 릴리스 정의 편집기에 기본적으로 옵트인 기능이 제공됩니다.
- 가상 머신 배포를 사용하여 배포할 수 있습니다.
- 예비 테스트 추적 가능성을 개선했습니다.
- 테스트 일괄 처리를 추가했습니다.
- 이제 테스트 계획 및 테스트 도구 모음에 대한 차트 위젯을 볼 수 있습니다.
TFS 2018 비디오의 새로운 기능
XAML 빌드
원래 TFS 2018 RTW 및 업데이트 1부터 XAML 빌드가 제거된 것으로 나열되었습니다. 그러나 이로 인해 많은 고객들이 업그레이드하지 못하거나, 업그레이드 완료 후 다시 활성화하기 위해 지원에 문의해야 했습니다. TFS 2018 업데이트 2에서는 XAML 빌드가 활성화되어 있지만 사용되지는 않습니다. 즉 XAML 빌드에 대한 추가적인 투자가 없으며 MTM(Microsoft Test Manager)도 더 이상 XAML 빌드를 사용하여 지원하지 않습니다. 새 빌드 정의 형식 중 하나로 전환하는 것이 좋습니다. XAML 컨트롤러에 연결하여 TFS 2018 업데이트 2에서 계속 XAML 빌드를 실행할 수 있습니다. 추가 정보
TFS 2018 RTW에서 제거된 기능
- Microsoft Test Manager의 랩 센터 및 자동화된 테스트 흐름에 대한 지원을 제거했습니다.
- SharePoint에 대한 TFS 확장을 중단했습니다.
- 단체방 기능을 제거했습니다.
TFS 2018의 새로운 기능에 대한 세부 정보
작업 항목 추적
웹의 프로젝트 만들기 마법사
웹 액세스에서 팀 프로젝트를 만들기 위한 환경을 개선했습니다. 이제 Visual Studio 클라이언트에서 팀 프로젝트를 만들 때 사용할 수 있는 대부분의 기능이 포함되어 있습니다. 웹 인터페이스를 사용하여 얻을 수 있는 이점은 일치하는 Visual Studio 버전이 필요하지 않다는 것입니다. Visual Studio 또는 웹 버전을 사용할 때의 차이점은 웹 버전은 SSRS에서 보고서를 프로비전하지 않는다는 것입니다. 웹 버전의 팀 프로젝트 만들기를 사용하는 경우 애플리케이션 계층에서 tfsconfig 명령을 실행하여 SSRS 보고서를 프로비전하거나 업데이트할 수 있습니다.
웹의 프로세스 템플릿 관리자
TFS 2018에서는 웹 액세스를 사용하여 프로세스 템플릿을 업로드할 수 있습니다. 프로세스 템플릿과 상호 작용하기 위해 올바른 버전의 Visual Studio를 설치할 필요가 없으므로 웹 인터페이스가 훨씬 더 쉬운 환경이 됩니다. 웹 인터페이스를 사용하는 것이 좋지만 Visual Studio 2017 업데이트 4 및 이전 버전에는 프로세스 템플릿 관리자 대화 상자가 여전히 표시됩니다. Visual Studio 2017 업데이트 5 이상은 자동으로 사용자를 해당 웹으로 리디렉션합니다.
작업 항목 폼 헤더 사용자 지정
이제 기존 컨트롤을 바꾸거나 프로세스에 관련되지 않은 컨트롤을 숨겨 작업 항목 폼 헤더 영역을 사용자 지정할 수 있습니다. 이렇게 하면 팀이 Kanban에 집중한 경우 영역 경로를 사용자 지정 팀 필드와 바꾸고 반복을 숨기고, 이유를 사용자 지정 필드와 바꿀 수 있습니다. 상태 필드를 숨기거나 바꿀 수 없습니다.
팁
자세한 정보는 WebLayout 및 컨트롤 요소에 대한 설명서를 참조하세요.
모바일 작업 항목 폼
작업 항목 (그림 1)에 대해 최적화된 모양과 느낌을 포함하는 완벽한 엔드투엔드 환경을 제공합니다. 최근에 휴대 전화에서 사용자에게 할당되거나, 사용자가 팔로우하고 있거나, 방문하거나, 편집한 항목과 손쉽게 상호 작용할 수 있는 방법을 제공합니다.
이 환경은 화면 구성도 보기 좋으며 모든 필드 형식에 대해 최적화된 컨트롤을 지원합니다(그림 2).
새 모바일 탐색(그림 3)을 사용하여 사용자는 TFS의 모바일 지원 부분에 연결하고, 다른 허브와 상호 작용해야 할 경우 전체 데스크톱 사이트로 돌아갈 수 있습니다.
백로그, Kanban 보드, 스프린트 및 쿼리 필터링
이제 모든 작업 항목 추적 표 환경(쿼리, 백로그, Kanban 보드, 스프린트 백로그 및 테스트 사례 관리)에서는 일반적이고 일관된 필터링 구성 요소가 사용됩니다(그림 4). 표시된 열에 걸쳐 키워드 필터를 적용하고 태그를 선택하는 것 외에도, 작업 항목 형식, 상태, 할당 대상을 기준으로 필터링하여 원하는 작업 항목을 빠르게 얻을 수 있습니다.
Kanban 카드의 빈 필드를 표시하도록 확장
이제 카드에 필드를 더 추가한 다음, 보드 설정에서 빈 필드를 숨겨(그림 5) 불필요한 혼란을 제거할 수 있습니다. 이 기능의 단점은 빈 필드가 숨겨진 후 필드를 업데이트하기 위해서는 반드시 작업 항목 폼을 열어야 한다는 것입니다. 이제 Kanban 카드에서 새롭게 사용 가능해진 확장 옵션을 사용하여, 보드 전체에서 빈 필드를 숨기면서 클릭 한 번으로 액세스하여 카드의 특정 필드를 업데이트할 수 있습니다. 카드 위로 마우스를 가져가기만 하면 카드 아래쪽에 숨겨진 필드를 업데이트할 수 있는 아래쪽 펼침 단추가 표시됩니다.
카드 맨 아래에 있는 아래쪽 펼침 단추를 클릭하여 필드를 업데이트합니다(그림 6).
확장 기능으로 작업 항목 저장 차단
이제 작업 항목 폼 사용자 지정 컨트롤, 그룹 및 페이지에서 작업 항목 저장을 차단하여 작업 항목 폼을 저장하기 전에 데이터의 유효성을 검사하고 사용자가 필요한 정보를 모두 입력하도록 할 수 있습니다.
인라인 추가 배달 계획
새 기능 아이디어는 언제든지 도착할 수 있으므로 배달 계획에 새 기능을 직접 더 쉽게 추가할 수 있습니다(그림 7). 가리키기에서 사용할 수 있는 새 항목 단추를 클릭하고 이름을 입력하고 enter 키를 누릅니다. 새로운 기능이 예상한 영역 경로 및 반복 경로와 함께 생성됩니다.
버전 제어
포크
TFS 2018에서는 Git 포크를 추가로 지원합니다(그림 8). 포크는 리포지토리의 서버 쪽 복사본입니다. 포크를 사용하여 직접적인 커밋 액세스 권한이 없어도 광범위한 사용자들이 리포지토리에 기여하도록 할 수 있습니다. 대신, 사용자들은 리포지토리의 자체 포크로 작업을 커밋합니다. 이를 통해 해당 변경 내용을 중앙 리포지토리에 수락하기 전에 끌어오기 요청에서 검토할 수 있습니다.
GVFS
GVFS(Git 가상 파일 시스템)는 이제 지원됩니다. GVFS는 Git 리포지토리를 파일 시스템에서 Git의 작동 방식을 가상화하고 최적화하여 수백만 개의 파일로 확장할 수 있도록 합니다.
웹을 사용하여 리포지토리에 폴더 만들기
이제 Git 및 TFVC 리포지토리에서 웹을 통해 폴더를 만들 수 있습니다(그림 9). 이는 이제 사용 중단의 프로세스를 거칠 폴더 관리 확장을 바꿉니다.
폴더를 만들려면 명령 모음 또는 바로 가기 메뉴에서 새로 만들기 > 폴더를 클릭합니다.
TFVC의 경우 폴더 이름을 지정한 다음, 체크 인합니다. Git의 경우 빈 폴더가 허용되지 않으므로 파일 이름을 지정하고, 필요에 따라 파일을 편집한 다음, 커밋해야 합니다.
또한 Git의 경우 새 파일 대화 상자 (그림 10)가 하위 폴더를 만드는 슬래시를 허용하도록 향상되었습니다.
파일 미니 맵
이제 코드의 간략한 개요를 제공하는 보거나 편집하는 파일의 미니 맵을 볼 수 있습니다(그림 11). 미니 맵을 활성화하려면 명령 팔레트(F1 또는 마우스 오른쪽 단추로 클릭)를 열고 미니 맵 설정/해제를 선택합니다.
대괄호 일치
파일을 편집하거나 볼 때 대괄호를 쉽게 일치시킬 수 있는 지침이 왼쪽에 있습니다(그림 12).
공백 설정/해제
이제 파일을 보거나 편집할 때 공백을 설정 및 해제할 수 있습니다. diff할 때 공백을 설정/해제할 수 있도록 하는 기능을 개발 중입니다. 공백(그림 13)을 보려면 명령 팔레트(F1 또는 마우스 오른쪽 단추로 클릭)를 열고 공백과 탭을 구분할 수 있도록 하는 공백 설정/해제를 선택합니다.
TFVC 리포지토리에 대한 웹 편집 해제 설정
TFVC를 사용하는 팀은 종종 Visual Studio의 체크 인 정책을 사용하여 코드 품질을 보장합니다. 그러나 체크 인 정책은 클라이언트에서 적용되므로 웹에서 편집되는 코드에는 동일한 정책이 적용되지 않습니다.
일부 사용자는 웹 편집을 사용하지 않도록 설정하여 체크 인 정책을 우회하는 변경으로부터 보호할 수 있는 방안을 요청하고 있습니다. 프로젝트/리포지토리를 기준으로 TFVC에 대해 웹 편집(추가, 삭제, 이름 바꾸기, 편집)을 해제하는 방법을 사용할 수 있습니다.
웹 편집을 허용하지 않으려면 파일 페이지에서 설정으로 이동한 후 버전 제어(그림 14)로 이동합니다. 트리에서 TFVC 리포지토리를 클릭하고, 옵션 피벗으로 이동한 후 Enable web-editing for this TFVC repository(이 TFVC 리포지토리에 웹 편집 사용)를 선택 취소합니다. 기본적으로 웹 편집은 사용되도록 설정됩니다.
참고 항목
프로젝트 개요 페이지에서 README를 편집할 때는 영향을 받지 않습니다.
웹 편집이 사용되지 않도록 설정된 프로젝트에서 웹 편집을 사용하려고 하면 웹 편집이 허용되지 않는다는 알림이 표시됩니다(그림 15).
부실 분기 식별
더 이상 필요하지 않은 분기를 삭제하여 리포지토리를 정리하면 팀에서 관심 있는 분기를 찾고 적절한 세분성으로 즐겨찾기를 설정할 수 있습니다. 그러나 리포지토리에 많은 분기가 있으면 비활성 상태여서 삭제할 수 있는 분기를 파악하기 어려울 수 있습니다. 이제 "부실" 분기(3개월보다 오래된 커밋을 가리키는 분기)를 더 쉽게 식별할 수 있습니다. 부실 분기를 확인하려면 분기 페이지의 부실 피벗으로 이동합니다(그림 16).
삭제된 분기 검색 및 다시 만들기
서버에서 실수로 분기가 삭제되면 발생된 상황을 파악하기 어려울 수 있습니다. 이제 삭제된 분기를 검색하고, 삭제한 사용자 및 시간을 확인하고, 원할 경우 다시 만들 수 있습니다.
삭제된 분기를 검색하려면 분기 검색 상자에 전체 분기 이름을 입력합니다. 해당 텍스트와 일치하는 기존의 모든 분기가 반환됩니다. 삭제된 분기 목록에서 정확한 일치 항목을 검색하는 옵션도 제공됩니다. 삭제된 분기를 검색하기 위한 링크를 클릭합니다(그림 17).
일치 항목이 있는 경우 삭제한 사용자 및 시간을 확인합니다. 분기를 복원할 수도 있습니다(그림 18).
분기를 복원하면 마지막에 가리킨 커밋에서 다시 만들어집니다. 그러나 정책 및 사용 권한은 복원되지 않습니다.
접두사로 시작하는 분기에서 커밋 검색
모든 분기에 접두사가 지정된 계층 구조 형식으로 분기가 구성된 경우 이 기능을 사용하면 해당 접두사 텍스트로 시작되는 모든 분기에서 커밋을 찾을 수 있습니다. 예를 들어 커밋이 접두사 “dev”가 붙은 모든 분기로 연결되어 있는지 확인하려는 경우 검색 상자에 간단히 “dev”를 입력하고 “dev”로 시작하는 분기 검색을 선택합니다(그림 19).
커밋 세부 정보 페이지의 다양한 끌어오기 요청 설명
커밋 세부 정보 페이지의 끌어오기 요청 설명선은 더 잘 진단할 수 있는 관련 정보를 표시합니다(그림 20). 또한 이제 분기에 커밋을 도입한 첫 번째 끌어오기 요청과 기본 분기와 연결된 끌어오기 요청이 설명이 표시됩니다.
코드의 트리 뷰 필터링
이제 파일로 이동하기 위해 커밋이 수정되었을 수 있는 모든 파일을 스크롤할 필요가 없습니다. 이제 커밋 세부 정보, 끌어오기 요청, 보류 집합 정보, 변경 집합 정보 페이지의 트리 뷰에서 파일 및 폴더 필터링을 지원합니다. 이 필터는 폴더 이름으로 필터링할 때는 폴더의 자식 파일을 표시하고, 파일 이름으로 필터링할 때는 축소된 트리 뷰를 통해 파일 계층 구조를 표시하는 스마트 필터입니다.
커밋 트리에서 파일 또는 폴더 필터 찾기(그림 21) 및 (그림 22):
분기 업데이트 페이지가 이제 푸시로 표시됩니다.
분기 업데이트 페이지에는 상당히 큰 값이 있습니다. 그러나 기록 허브 아래에 피벗으로 숨겨져 있습니다. 이제 분기 업데이트 페이지가 코드 아래에 커밋, 분기, 태그 및 끌어오기 요청과 함께 푸시(그림 23)라는 허브로 표시됩니다. 푸시 페이지의 새 URL은 \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/pushes입니다. 이전 URL은 계속 작동합니다.
동시에 기록 허브의 이름이 커밋(그림 24)으로 바뀌었습니다. 이 허브에는 커밋만 표시되기 때문입니다. 커밋 목록 보기에 커서를 놓으면 자세한 시간만 표시되었으므로 커밋 관련 문제를 해결하는 것이 어렵다는 의견이 있었습니다. 이제 인스턴스 전체의 커밋 목록 보기에는 dd/mm/yy hh:mm 형식으로 날짜 및 시간이 표시됩니다. 커밋 페이지의 새 URL은 \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/commits입니다. 이전 URL은 계속 작동합니다.
파일에서 커밋으로 이동할 때 파일 이름 유지
코드 허브의 파일 피벗에서 디렉터리를 특정 파일로 필터링한 다음, 나중에 기록 피벗으로 전환하면 커밋이 1,000개를 초과하는 파일을 변경할 경우 파일 이름이 지속되지 않는다는 의견이 있었습니다. 이로 인해 사용자가 파일을 찾기 위해 더 많은 파일을 로드하고 콘텐츠를 필터링해야 했으며, 이는 생산성에 영향을 미쳤습니다. 개발자들은 일반적으로 동일한 디렉터리에서 작동하므로 변경 내용을 추적할 때 작업하든 디렉터리를 유지하려고 합니다. 이제 커밋에서 변경된 파일 수와 관계없이 코드 허브 피벗 간을 전환할 때 파일 이름이 유지됩니다. 즉, 원하는 파일을 찾기 위해 추가 로드를 클릭할 필요가 없습니다.
Git 태그 보기
태그 페이지에서 리포지토리의 모든 태그를 볼 수 있습니다(그림 25). 모든 태그를 릴리스로 관리하는 경우 사용자는 태그 페이지를 방문하여 모든 제품 릴리스의 조감도를 볼 수 있습니다.
경량 태그와 주석이 추가된 태그를 쉽게 구별할 수 있습니다. 주석이 추가된 태그는 관련된 커밋과 함께 태거와 생성 날짜를 표시하지만 경량 태그는 커밋 정보만 표시합니다.
Git 태그 삭제
원격 리포지토리에서 태그를 삭제하려는 경우가 있을 수 있습니다. 태그 이름에 철자 오류가 있거나 잘못된 커밋에 태그를 지정했을 수 있습니다. 태그 페이지에서 태그의 상황에 맞는 메뉴를 클릭하고 태그 삭제를 선택하여 웹 UI에서 태그를 쉽게 삭제할 수 있습니다(그림 26).
Warning
원격 리포지토리에서 태그를 삭제할 때는 주의해야 합니다.
Git 태그 필터링
이전 리포지토리의 경우, 시간에 따라 태그 수가 많이 늘어날 수 있습니다. 또한 태그가 계층 구조로 생성된 리포지토리가 있어서 태그를 찾기 어려운 경우도 있었습니다.
태그 페이지에서 찾으려는 태그를 찾을 수 없으면 태그 페이지 맨 위에 있는 필터를 사용하여 태그를 이름을 간단히 검색할 수 있습니다(그림 27).
Git 태그 보안
이제 리포지토리의 사용자에게 태그를 관리하기 위한 보다 세분화된 권한을 부여할 수 있습니다. 사용자에게 이 인터페이스에서 태그를 삭제하거나 관리할 수 있는 권한을 부여할 수 있습니다(그림 28).
팁
Git 태그에 대한 자세한 내용은 Microsoft DevOps 블로그를 참조하세요.
끌어오기 요청을 완료할 때 작업 항목 자동 완료
끌어오기 요청에 작업 항목을 연결하는 경우 모든 항목을 간단하게 최신 상태로 유지할 수 있습니다. 이제 PR을 완료하면 PR이 성공적으로 병합된 후에 연결된 작업 항목을 자동으로 완료할 수 있는 옵션이 제공됩니다(그림 29). 정책을 사용하고 끌어오기 요청이 자동으로 완료되도록 설정하는 경우에도 동일한 옵션이 표시됩니다. 끌어오기 요청이 완료되면 작업 항목으로 다시 가서 상태를 업데이트할 필요가 없습니다. 이러한 작업이 모두 자동으로 진행됩니다.
푸시/새 반복 시 투표 다시 설정
PR에서 더욱 엄격한 승인 워크플로를 선택한 팀은 이제 새 변경이 푸시될 때 투표를 다시 설정하도록 옵트인할 수 있습니다(그림 30). 새 설정은 최소 인원의 검토자가 필요함 정책에 따라 표시되는 옵션입니다.
이 옵션이 설정되면 PR의 소스 분기가 업데이트될 때마다 모든 검토자의 모든 투표가 다시 설정됩니다. PR 타임라인은 이 옵션의 결과로 투표가 다시 설정될 때마다 항목을 기록합니다(그림 31).
파일 이름으로 끌어오기 요청 트리 필터링
끌어오기 요청에서 특정 파일을 찾는 것이 이전보다 더 쉬워졌습니다. 사용자는 파일 뷰의 새 필터 상자로 트리 뷰의 파일 목록을 필터링할 수 있습니다(그림 32).
필터는 끌어오기 요청에서 일치하는 파일 경로 부분이 있는지 검색하므로 폴더 이름, 부분 경로, 파일 이름 또는 확장명으로 검색할 수 있습니다(그림 33).
추가 끌어오기 요청 주석 필터링 옵션
이제 끌어오기 요청 개요 및 파일 보기의 주석 모두 동일한 옵션을 제공합니다(그림 34). 본인이 참여한 토론만 표시되도록 필터링할 수도 있습니다.
끌어오기 요청 세부 정보에서 코드 주석의 원래 차이점 보기
경우에 따라 참조하는 코드가 변경되면(요청된 변경이 여러 번 수행된 경우) PR 주석을 이해하기 어렵습니다(그림 35).
이 경우 업데이트 번호가 있는 배지가 표시되며, 이를 클릭하여 주석을 처음 만들었을 때의 코드를 확인할 수 있습니다(그림 36).
축소 가능한 끌어오기 요청 주석
코드 검토는 끌어오기 요청 환경의 중요한 부분이므로 검토자들이 코드에 좀 더 쉽게 집중할 수 있도록 새로운 기능을 추가했습니다. 코드 검토자는 새 코드를 처음 검토할 때 주석을 숨겨서 전체적인 코드를 쉽게 파악할 수 있습니다(그림 37).
주석을 숨기면(그림 38) 트리 뷰에서 숨겨지고 파일 보기에서는 주석 스레드가 축소됩니다.
주석이 축소되면 여백에 있는 아이콘을 클릭하여 쉽게 확장할 수 있으며 한 번 더 클릭하면 다시 축소됩니다. 도구 설명(그림 39)을 보면 전체 스레드를 보지 않고도 주석을 쉽게 확인할 수 있습니다.
끌어오기 요청 설명 및 주석의 작업 목록
PR을 준비하거나 주석을 달 때, 경우에 따라 추적하려는 항목 목록이 짧아서 텍스트를 편집하거나 여러 주석을 추가하게 됩니다. 간단한 작업 목록은 설명 또는 단일 통합 주석에서 PR 작성자 또는 검토자 자격으로 할 일 목록의 진행 상태를 추적하는 유용한 방법입니다. Markdown 도구 모음을 클릭하여 시작하거나 선택한 텍스트에 서식을 적용합니다(그림 40).
작업 목록이 추가되면(그림 41) 항목을 완료로 표시하기 위해 확인란을 선택하기만 하면 됩니다. 이러한 사항은 Markdown에서 [ ] 및 [x]로 주석 내에 표시되고 저장됩니다. 자세한 내용은 Markdown 지침을 참조하세요.
끌어오기 요청의 "좋아요" 주석에 대한 기능
좋아요 단추를 한 번 클릭하여 PR 주석에 대한 지원을 표시합니다(그림 42). 단추 위로 마우스를 가져가 주석에 좋아요를 표시한 모든 사용자의 목록을 볼 수 있습니다.
제안과 함께 승인을 사용할 때 향상된 워크플로 제공
끌어오기 요청에 자동 완성 옵션(그림 43)을 사용하면 생산성을 향상할 수 있지만 코드 검토자와의 활성 토론이 갑자기 중단되는 것은 바람직하지 않습니다. 이러한 토론을 보다 편리하게 활용하기 위해 이제 제안과 함께 승인 투표에서는 끌어오기 요청이 자동으로 완료되도록 설정된 경우 메시지를 표시합니다. 사용자는 해당 피드백을 읽을 수 있게 자동 완성을 취소하거나, 자동 완성 설정을 유지하고 모든 정책이 충족될 때 끌어오기 요청이 자동으로 완료되도록 허용하는 옵션을 선택할 수 있습니다.
Git 알림에 대한 경로 필터링 지원
리포지토리의 모든 폴더에 대해 알림을 받는 대신, 이제 팀 구성원이 사용자에게 관심 있는 폴더에서만 끌어오기 요청 또는 푸시 코드를 만들 때 알림을 받도록 선택할 수 있습니다. 사용자 지정 Git 푸시 또는 Git 끌어오기 요청 전자 메일 알림 구독을 만들 경우 이러한 알림을 폴더 경로별로 필터링하는 새로운 옵션이 표시됩니다(그림 44).
끌어오기 요청 워크플로에 대한 업데이트된 전자 메일 템플릿
끌어오기 요청 전자 메일 알림은 명확하고 간결하며 실행 가능하도록 새로 고쳐졌습니다(그림 45). 제목 줄은 이제 PR 제목으로 시작되고, 보조 정보(예: 리포지토리 이름 및 ID)는 끝으로 보냅니다. PR을 만든 사람을 기준으로 규칙 및 필터를 더욱 쉽게 적용할 수 있도록 제목에 작성자의 이름이 추가되었습니다.
경고 전자 메일의 본문에는 경고를 보낸 이유를 요약하고 중요한 메타데이터(제목, 분기 이름 및 설명) 및 기본 행동 요구 지침 단추를 제공하는 새로 고친 템플릿이 포함되어 있습니다. 검토자, 파일 및 커밋 같은 추가 세부 정보는 전자 메일 아래쪽에 포함되어 있습니다.
대부분의 경고는 웹에서 끌어오기 요청을 확인해야 합니다(그림 46). 그러나 특정 주석에 대한 알림이 제공되는 경우에는 컨텍스트에 대한 코드 및 사전 대화를 쉽게 찾을 수 있도록 해당 주석에 직접 연결해야 합니다.
푸시 알림에 대한 업데이트된 전자 메일 템플릿
명백하고 간결하고 조치 가능하도록 최적화된 새 전자 메일 템플릿을 일치시키도록 푸시 알림이 업데이트되었습니다(그림 47). 제목 줄을 사용하면 푸시 알림을 구분하고, 분기, 리포지토리 및 작성자를 식별하고, 푸시에 포함된 커밋의 수를 요약할 수 있습니다. 또한 이러한 변경 내용을 통해 이러한 전자 메일 알림을 관리할 수 있도록 돕는 규칙 및 필터를 쉽게 만들 수 있습니다.
전자 메일 본문은 전자 메일이 전송된 이유, 작업을 시작한 사람 및 정확히 무슨 상황이 발생했는지를 강조 표시하는 다른 전자 메일로 구성됩니다. 변경 내용의 범위에 대해 받는 사람에게 알릴 수 있도록 푸시 경고에 관련된 리포지토리, 분기, 파일 및 커밋에 대한 세부 정보가 모두 포함됩니다. 푸시 경고의 작업에 대한 기본 호출은 푸시 보기이며 경고를 생성하는 특정 푸시에 대한 푸시 보기를 엽니다.
Wiki
각 프로젝트는 이제 자체 Wiki를 지원합니다(그림 48). 이제 팀 구성원이 프로젝트를 이해하고 사용하고 참여하는 데 도움이 되는 페이지를 편리하게 작성할 수 있습니다.
새 Wiki의 주요 기능 중 일부는 다음과 같습니다.
- Markdown 구문을 사용한 간편한 편집 환경
- 새 페이지에서 제목을 지정하고 콘텐츠를 추가할 수 있습니다. 그림 49
- Markdown에서 HTML 태그 지원(그림 50).
- Markdown 폴더에서 이미지 크기를 편리하게 조정(그림 51).
- 페이지 순서와 페이지 부모를 다시 지정하고, 페이지를 관리할 수 있는 강력한 페이지 관리 창.
- 큰 Wiki의 경우 제목으로 페이지를 필터링하는 기능(그림 52).
- 고급 사용자를 위해 Wiki 오프라인 업데이트.
팁
Wiki 시작에 대해 자세히 알아봅니다.
Wiki를 더 많이 사용함에 따라 의도치 않은 변경 내용을 저장하는 경우가 있습니다. 이제 수정 세부 정보를 클릭하고 되돌리기 단추를 클릭하여 수정 버전을 Wiki 페이지로 되돌릴 수 있습니다(그림 53).
끊어진 링크에서 Wiki 페이지 만들기
Wiki 생성 도중 Wiki 페이지의 목차에 존재하지 않는 링크가 포함된 패턴이 관찰되었습니다(그림 54). 사용자는 실제 페이지를 만들기 위해 이러한 링크를 클릭합니다. 이전에는 링크가 끊어졌거나 페이지가 존재하지 않는다는 경고를 표시하여 이 시나리오를 처리했습니다. 이제는 사용자들이 대신 페이지를 만들 수 있도록 하여 이러한 문제를 Wiki에 대한 주요 시나리오로 처리하고 있습니다.
Wiki 페이지 딥 링크 설정
Wiki는 이제 페이지 내 및 페이지 전체에서 딥 링크 설정 섹션을 지원하므로 목차를 만드는 데 매우 유용합니다. 다음 구문을 사용하여 같은 페이지 또는 다른 페이지에서 제목을 참조할 수 있습니다.
- 같은 페이지:
[text to display](#section-name) - 다른 페이지:
[text to display](/page-name#section-name)
이제 Marketplace의 Wiki 확장이 더 이상 사용되지 않습니다. 기존 Wiki 확장 사용자는 이 마이그레이션 도구를 사용하여 wiki 페이지를 새 wiki로 마이그레이션할 수 있습니다. 기존 Wiki 페이지를 새 Wiki로 마이그레이션하는 방법에 대해 자세히 알아봅니다.
패키지 관리
패키지 관리 환경 업데이트
이제 패키지 URL은 GUID를 사용하는 대신 패키지 이름 및 버전을 사용합니다. 따라서 패키지 URL을 더욱 쉽게 직접 만들 수 있습니다(그림 55). 형식은 \<tfsserverurl\>/\<project|team\>/_packaging?feed=\<feed\>&package=\<package\>&version=\<version\>&protocolType=\<NuGet|Npm|Maven\>&_a=package입니다.
이제 모든 피드 사용자의 삭제된 패키지 버전(그림 56)을 숨길 수 있습니다(취소선이 그어진 패키지가 더 이상 표시되지 않음).
이제 패키지 세부 정보 페이지에서 수행할 수 있는 모든 작업을 패키지 목록의 상황에 맞는 메뉴에서 수행할 수 있습니다.
패키지 목록에는 사용자 중심 날짜가 포함된 새 마지막으로 푸시됨 열(그림 57)이 포함되어 있으므로 최근에 업데이트한 패키지를 쉽게 찾을 수 있습니다.
Maven 패키지
TFS 2018에 Maven 아티팩트를 호스트하는 지원이 시작되었습니다(그림 58). Maven 아티팩트를 사용하도록 설정하여 Java 개발자가 코드와 구성 요소를 원활하게 공유할 수 있습니다. 패키지 관리를 사용하여 Maven 아티팩트를 공유하는 방법에 대해서는 시작 가이드를 참조하세요.
통합된 새 NuGet 작업
나머지 빌드 작업 라이브러리에 잘 맞도록 NuGet 복원, NuGet 패키지 작성 도구 및 NuGet 게시자 작업을 통합 NuGet 빌드 작업에 결합했습니다. 새 작업은 기본적으로 NuGet 4.0.0을 사용합니다. 따라서 이전 작업은 더 이상 사용되지 않습니다. 시간이 있을 때 새 NuGet 작업으로 전환하는 것이 좋습니다. 이러한 변경은 아래에서 설명하는 향상된 기능과 부합하여 결합된 작업을 통해서만 액세스할 수 있습니다.
이러한 작업의 일부로 PATH에서 사용할 수 있으며 새 NuGet 작업에서 사용되는 NuGet 버전을 제어하는 새로운 NuGet 도구 설치 관리자 작업을 릴리스했습니다. 따라서 최신 버전의 NuGet을 사용하려면 빌드 시작 부분에 NuGet 도구 설치 관리자 작업을 추가하기만 하면 됩니다(그림 59).
팁
Microsoft DevOps 블로그의 빌드에서 최신 NuGet을 사용하는 방법에 대해 자세히 알아보세요.
NuGet "중복을 건너뛸 수 있음" 옵션
많은 NuGet 고객이 업데이트(및 업데이트된 버전 번호)만 있는 패키지 집합을 생성하고 있다는 정보를 들었습니다. NuGet 빌드 작업에는 해당 버전이 이미 사용 중인 VSTS/TFS 피드에 패키지를 푸시하려고 할 때 작업을 계속할 수 있도록 하는 새로운 중복을 건너뛸 수 있음 옵션이 있습니다.
npm 빌드 작업 업데이트
Windows, Linux 또는 Mac에서 npm 프로젝트를 빌드하는 경우 새 NPM 빌드 작업이 원활하게 작동합니다. 또한 npm 설치 및 npm 게시가 보다 쉽게 진행될 수 있게 작업을 다시 구성했습니다. 설치 및 게시의 경우 자격 증명 획득을 간소화하여 프로젝트의 .npmrc 파일에 나열된 레지스트리에 대한 자격 증명이 서비스 엔드포인트에 안전하게 저장됩니다. 또는 VSTS/TFS 피드를 사용하는 경우 피드를 선택할 수 있는 선택기가 있으며, 이를 통해 빌드 에이전트에서 사용하는 필수 자격 증명으로 .npmrc를 생성합니다.
이제 Maven에서 인증된 피드가 지원됨
NuGet 및 npm과 달리 Maven 빌드 작업은 이전에는 인증된 피드와 쉽게 연동되지 않았습니다. 이제 Maven 작업이 업데이트되어, VSTS/TFS 피드를 쉽게 사용할 수 있습니다(그림 60).
dotnet 작업이 인증된 피드, 웹 프로젝트를 지원함
dotnet 작업의 다음 주 버전(2.x)은 많은 피드백 요청을 해결하고 그동안 추적한 버그 집합을 수정합니다. 여기에는 다음과 같은 사항이 포함됩니다.
- 첫째, dotnet은 패키지 관리와 같은 인증된 패키지 소스를 지원하므로 이제 더 이상 개인 패키지 소스에서 패키지를 복원하기 위해 NuGet 작업을 사용할 필요가 없습니다.
- 프로젝트 경로 필드의 동작이 작업의 2.0 버전에서는 변경되었습니다. 작업의 이전 버전에서는 지정된 패턴과 일치하는 프로젝트 파일을 찾을 수 없으면 작업은 경고를 로그한 후 성공 결과를 나타냈습니다. 이러한 시나리오에서는 경우에 따라 빌드는 성공했으나 종속성은 복원되지 않은 이유를 이해하기 어려울 수 있습니다. 이제 지정한 패턴과 일치하는 프로젝트 파일을 찾을 수 없는 경우 작업이 실패합니다. 이러한 과정이 다른 작업의 동작에 맞게 진행되며 이해하고 사용하기 쉽습니다.
- 이전 버전의 작업 게시 명령에서는 명시적인 출력 경로를 입력한 경우에도 프로젝트 파일 이름을 따라 명명된 폴더에 모든 파일이 추가되는 방식으로 출력 경로가 수정되었습니다. 이로 인해 명령을 연결해서 실행하기 어렵습니다. 이제 출력 파일 경로를 제어할 수 있습니다.
PATH에서 사용할 수 있으며 새 dotnet 작업에서 사용되는 dotnet 버전을 제어하는 새로운 dotnet 도구 설치 관리자 작업을 릴리스했습니다. 따라서 최신 버전의 dotnet을 사용하려면 빌드 시작 부분에 dotnet 도구 설치 관리자 작업을 추가하기만 하면 됩니다.
사용자 계정/컬렉션 외부에서 작업
이제 사용자의 TFS 서버 또는 VSTS 계정 외부의 피드(그림 61)를 사용하기가 더 쉬워졌습니다. 예를 들어 다른 VSTS 계정이나 TFS 서버의 패키지 관리 피드나 NuGet.org/npmjs.com, Artifactory 또는 MyGet과 같은 비패키지 관리 피드를 사용할 수 있습니다(그림 60). NuGet 및 npm에 대해 전용 서비스 엔드포인트 유형을 사용하면 올바른 자격 증명을 쉽게 입력할 수 있으며 다운로드 패키지 및 패키지 푸시 작업에서 빌드 작업을 원활하게 수행할 수 있습니다.
VSTS/TFS 피드용 피드 선택
항상 구성 파일(예: NuGet.Config, .npmrc 등)을 확인하여 소스 리포지토리에서 패키지의 원본 위치에 대한 기록이 있는지 점검하는 것이 좋습니다. 그러나 이러한 방식이 이상적이지 않은 경우가 여러 차례 확인되었으므로 피드를 선택하고 해당 빌드 단계에 사용할 구성 파일을 자동으로 생성할 수 있는 새로운 이 VSTS/TFS 피드의 패키지 사용 옵션을 추가했습니다(그림 62).
빌드 및 릴리스
XAML 빌드
TFS 2015에는 웹 기반, 플랫폼 간 빌드 시스템을 도입했습니다. XAML 빌드는 TFS 2018 RTW 또는 업데이트 1에서 지원되지 않지만 TFS 2018 업데이트 2에서 XAML 빌드를 활성화했습니다. 따라서 XAML 빌드를 마이그레이션하는 것이 좋습니다. 마이그레이션할 준비가 되지 않았고 XAML 빌드를 계속 사용해야 할 경우 TFS 2018 업데이트 2로 업그레이드합니다.
TFS 2018 RTW 또는 업데이트 1로 업그레이드하는 경우:
팀 프로젝트 컬렉션에 XAML 빌드 데이터가 있는 경우 XAML 빌드 기능의 제거에 대한 경고 메시지가 표시됩니다.
완료된 XAML 빌드는 볼 수 있지만, 새 빌드는 큐에 넣을 수 없습니다.
TFS 2018에는 XAML 빌드 컨트롤러 또는 에이전트의 새 버전이 없습니다.
TFS 2018 업데이트 2로 업그레이드하는 경우:
팀 프로젝트 컬렉션에 XAML 빌드 데이터가 있는 경우 XAML 빌드 기능의 사용 중지에 대한 경고 메시지가 표시됩니다.
Visual Studio 또는 Team Explorer 2017을 사용하여 XAML 빌드 정의를 편집하거나 새 XAML 빌드를 큐에 넣어야 합니다.
새 XAML 빌드 에이전트를 만들어야 하는 경우 TFS 2015 빌드 에이전트 설치 관리자를 사용하여 에이전트를 설치해야 합니다.
팁
XAML 빌드 사용 중단 계획에 대한 설명은 진화하는 TFS/Team Services 빌드 자동화 기능 블로그 게시물을 참조하세요.
빌드 정의 내보내기 및 가져오기
빌드 정의는 내부적으로 .json 파일로 구현되므로 파일 기록에서 변경 내용에 세부 정보를 볼 수 있습니다. 빌드 정의를 복제하고 빌드 정의에서 템플릿을 만들 수 있지만 많은 사용자가 CI 빌드 논리 복사본를 만든 후 다른 팀 프로젝트에서 다시 사용하는 것을 선호했습니다. 이는 UserVoice의 상위 10개 요청입니다.
이제 이렇게 하는 것이 가능해졌습니다(그림 63) 및 (그림 64)!
빌드 템플릿을 사용하여 확장
빌드 템플릿으로 사용자가 빌드 프로세스를 정의하는 기준을 만들 수 있습니다. 오늘날 제품 상자에는 많은 제품이 담겨 있으며 계정에 새 제품을 업로드할 수 있지만 확장 작성자가 확장의 일부로 새 템플릿을 포함할 수는 없었습니다. 이제 확장에 빌드 템플릿을 포함할 수 있습니다. 예시:
{ "id": "Template1",
"type": "ms.vss-build.template",
"targets": [ "ms.vss-build.templates" ],
"properties": { "name": "Template1" } }
전체 예제를 보려면 https://github.com/Microsoft/vsts-extension-samples/tree/master/fabrikam-build-extension을 참조하세요.
팁
이 기능을 사용하여 모든 팀 프로젝트에서 동일한 사용자 지정 템플릿을 제공하고 공유할 수 있습니다.
확장의 작업 사용 중단
이제 확장의 작업이 더 이상 사용되지 않게 할 수 있습니다. 이를 위해서는 작업의 최신 버전에 다음 변수를 추가해야 합니다.
"deprecated": true
사용자가 더 이상 사용되지 않는 작업을 검색하면(그림 65), 이러한 작업이 끝으로 푸시되고 기본적으로 접혀 있는 접기 가능한 섹션 아래에 그룹화됩니다. 사용되지 않는 작업이 정의에 이미 사용된 경우, 사용되지 않는 작업의 배지를 표시하여 사용자에게 대체 작업으로 전환할 것을 권장합니다.
작업 설명에서 대체 작업을 언급하여 사용자에게 관련 정보를 제공할 수 있습니다(그림 66). 그런 다음, 설명은 작업 카탈로그와 기존 빌드/릴리스 정의 모두에서 올바른 방향으로 작업을 사용하는 사용자를 나타냅니다.
적용된 빌드 섹션으로 섹션 가시성 제어
이전에는 빌드 작업 및 빌드 요약 섹션이 있는 확장을 사용할 경우 해당 빌드에서 빌드 작업을 사용하지 않더라도 빌드 요약 섹션이 표시됩니다. 이제 확장 코드에 다음 줄을 추가하고 해당 값을 true 또는 false로 설정하여 빌드 요약 페이지에 해당 섹션을 숨기거나 표시하도록 선택할 수 있습니다.
VSS.getConfiguration().setSectionVisibility("$(publisherId).$(extensionId).$(sectionId)", false);
Microsoft vsts-extension-samples 리포지토리에 포함된 샘플을 참조하세요.
변수 그룹 지원
변수 그룹을 릴리스 정의에서 사용할 수 있으며 이제 빌드 정의에서도 사용할 수 있습니다. 변수 그룹 만들기에 대해 자세히 알아보세요. 변수 그룹은 프로젝트 수준 빌드/릴리스 변수 및 빌드 정의의 변수 그룹에 대한 관련 제안에 따라 개발되고 우선 순위가 지정되었습니다.
Apple 인증서와 같은 보안 파일 사용
범용 보안 파일 라이브러리를 추가했습니다(그림 67).
보안 파일 라이브러리를 사용하여 인증서 서명, Apple 권한 설정 프로파일, Android 키 저장소 파일 및 SSH 키와 같은 파일을 소스 리포지토리에 커밋할 필요 없이 서버에 저장할 수 있습니다.
보안 파일의 내용은 암호화되며 빌드 또는 릴리스 프로세스 동안에만 작업에서 참조하는 방식으로 사용할 수 있습니다. 보안 파일은 보안 설정에 따라 팀 프로젝트의 여러 빌드 및 릴리스 정의에서 사용할 수 있습니다. 보안 파일은 라이브러리 보안 모델을 따릅니다.
이 새로운 기능을 활용하는 다음과 같은 몇 가지 Apple 작업도 추가했습니다.
빌드 정의 일시 중지
이제 빌드 정의를 일시 중지하거나 사용하지 않을 수 있습니다. 빌드 정의를 변경하고 완료될 때까지 모든 새 빌드의 큐를 방지하려는 경우 빌드 정의를 사용하지 않도록 합니다. 마찬가지로, 에이전트 컴퓨터를 업그레이드하려는 경우 빌드 정의를 일시 중지하도록 선택할 수 있습니다. 이는 VSTS에서 새 빌드 요청을 여전히 수락하지만 정의를 다시 시작할 때까지 실행하지 않고 큐에 보관하도록 합니다.
작업 입력 유효성 검사 지원
빌드 정의 작업에 매개 변수를 입력하면 경우에 따라 오류가 발생할 수 있습니다. 작업 입력 유효성 검사를 통해 작업 작성자는 적절한 값이 지정되도록 할 수 있습니다. 유효성 검사 식은 작업 조건에 사용되는 친숙한 식 구문을 따르고 URL, IPV4, 전자 메일, 번호 범위, sha1, 길이 또는 일치를 포함하여 작업 조건에서 지원하는 일반 함수 외에도 지원되는 함수를 사용할 수 있습니다.
팁
vsts 작업 리포지토리 페이지의 목표 및 사용에 대해 자세히 읽어보세요.
새 릴리스 정의 편집기
빌드 및 릴리스 환경의 지속적인 재정비의 일환으로, 더욱 직관적인 환경을 제공하고, 일부 문제점을 해결하고, 새 기능을 추가할 수 있도록 릴리스 정의 편집기를 혁신했습니다. 새 편집기의 가장 강력한 기능 중 하나는 환경에 대한 배포가 진행되는 방식을 시각화하는 기능입니다. 그뿐 아니라 이제 상황에 맞는 승인, 환경 속성 및 배포 설정이 제공되며 이러한 설정을 쉽게 구성할 수 있습니다.
파이프라인의 시각화
편집기의 파이프라인(그림 68)은 릴리스에서 배포가 진행되는 방식에 대한 그래픽 뷰를 제공합니다. 아티팩트는 해당 릴리스에서 사용되며 환경에 배포됩니다. 환경의 레이아웃 및 연결은 각 환경에 대해 정의된 트리거 설정을 반영합니다.
상황에 맞는 구성 UI
아티팩트, 릴리스 트리거, 배포 전 및 배포 후 승인, 환경 속성 및 배포 설정은 이제 상황에 맞게 제공되며 쉽게 구성할 수 있습니다(그림 69).
배포 템플릿 시작
모든 기본 제공 배포 템플릿에는 작업에 깊이 개입할 필요 없이 가장 중요한 매개 변수를 지정하여 사용자가 시작하는 프로세스를 간소화할 수 있는 프로세스 매개 변수가 있습니다(그림 70).
릴리스 및 환경 변수의 간편한 관리
목록 보기를 사용하여 신속하게 릴리스 또는 환경 변수를 추가하고 그리드 보기를 사용하여 병렬 범위에서 변수를 비교하고 편집합니다. 또한 필터 및 키워드 검색을 사용하여 두 보기에 사용하는 변수 집합을 관리할 수 있습니다.
향상된 작업 및 단계 편집기
새 빌드 정의 편집기의 모든 향상된 기능을 릴리스 정의 편집기에서도 사용할 수 있습니다(그림 72). 작업을 검색하고 추가 단추를 사용하거나 끌어서 놓기를 사용하여 추가할 수 있습니다. 끌어서 놓기를 사용하여 작업 순서를 변경하거나 복제할 수 있습니다.
변수 그룹, 보존 및 옵션 탭
이제 변수 그룹에 연결/연결을 해제할 수 있습니다(그림 73). 개별 환경에 대한 보존 정책을 설정하고 옵션 탭에서 릴리스 번호 형식과 같은 릴리스 정의 수준 설정을 수정할 수 있습니다. 환경을 배포 템플릿으로 저장하고, 환경 수준 권한을 설정하고, 작업 탭 내에서 단계를 다시 정렬할 수도 있습니다.
환경 수준 작업을 사용하여 템플릿으로 저장하고 보안을 설정합니다(그림 74).
배포 그룹을 사용하여 Virtual Machine 배포
이제 Release Management는 강력한 기본 다중 컴퓨터 배포를 지원합니다. 이제 전체적으로 애플리케이션의 고가용성을 보장하면서 여러 컴퓨터에서 배포를 오케스트레이션하고 롤링 업데이트를 수행할 수 있습니다.
에이전트 기반 배포 기능은 동일한 빌드 및 배포 에이전트에 의존합니다. 그러나 빌드 및 배포 에이전트를 에이전트 풀의 프록시 서버 집합에 설치하고 원격 대상 서버로의 배포를 구동하는 현재의 접근 방식과 달리, 대상 서버 각각에 에이전트를 직접 설치하고 해당 서버로의 롤링 배포를 구동합니다. 대상 컴퓨터에서 전체 작업 카탈로그를 사용할 수 있습니다.
배포 그룹(그림 75)은 각각에 에이전트가 설치된 대상(컴퓨터)의 논리적 그룹입니다. 배포 그룹은 단일 상자 개발, 다중 컴퓨터 QA 및 UAT/Prod용 컴퓨터 팜과 같은 물리적 환경을 나타냅니다. 또한 물리적 환경에 대한 보안 컨텍스트를 지정합니다.
이 에이전트를 등록하는 모든 가상 머신에 대해 사용할 수 있습니다. 또한 가상 머신이 스핀업할 때 에이전트를 자동으로 설치하는 Azure 가상 머신 확장을 지원하여 Azure에 더욱 쉽게 등록할 수 있습니다. Azure 가상 머신이 등록되면 해당 머신에 태그가 자동으로 상속됩니다.
배포 그룹이 지정되면 해당 배포 그룹에 대해 실행할 작업을 간단히 구성할 수 있습니다(그림 76). 태그를 사용하여 어떤 컴퓨터에서 어떤 작업을 실행할지 제어하고 롤아웃의 속도도 제어할 수 있습니다.
배포를 실행할 때 대상이 되는 전체 컴퓨터 그룹의 진행 상태가 로그에 표시됩니다(그림 77).
이 기능은 이제 Release Management에 통합되었으며 추가 라이선스는 필요하지 않습니다.
향상된 배포 그룹 UI
빌드 및 릴리스 환경의 지속적인 재정비의 일환으로,더욱 명확하고 직관적인 환경을 만들도록 배포 그룹 페이지를 혁신했습니다(그림 78). 시작 페이지의 배포 그룹에서 대상의 상태를 볼 수 있습니다. 개별 배포 그룹에 대한 보안을 관리하거나 배포 그룹에 걸쳐 기본 사용 권한을 설정할 수 있습니다.
배포 그룹 내 대상의 경우 요약, 최근 배포 및 대상의 기능을 볼 수 있습니다(그림 79). 대상에 태그를 설정할 수 있으며 각 대상에서 실행되는 작업을 제어할 수 있습니다. 이후 릴리스에서 배포 그룹에 대한 필터 지원을 추가할 예정입니다.
작업 그룹 참조
작업 그룹을 사용하여 빌드 및 릴리스 정의에 추가할 수 있는 작업 집합을 정의할 수 있습니다(그림 80). 여러 빌드 또는 릴리스에서 동일한 작업 그룹을 사용해야 할 경우에 유용합니다. 작업 그룹의 소비자를 좀 더 쉽게 추적할 수 있도록 빌드 정의, 릴리스 정의 및 작업 그룹을 참조하는 작업 그룹에 대한 뷰를 제공합니다(그림 79).
여전히 참조되는 작업 그룹을 삭제하려고 하면 경고 메시지가 표시되고 이 페이지에 대한 링크가 제공됩니다.
작업 그룹 버전 관리
작업 그룹을 변경할 경우 해당 작업 그룹을 사용하는 모든 정의에 영향을 미칠 수 있으므로 위험하다고 생각될 수 있습니다. 작업 그룹 버전 관리를 사용하면 전환 준비가 될 때까지 가장 중요한 정의에 대한 안전한 버전을 제공하면서 작업 그룹 버전의 초안을 만들고 미리 볼 수 있습니다. 초안 작성 및 반복 작업을 어느 정도 진행한 후에는 안전한 버전을 게시할 수 있으며, 게시하는 동안 변경이 진행될 경우 해당 작업 그룹을 미리 보기(새로운 주 버전)로 게시하도록 선택할 수 있습니다. 또는 업데이트된 안전한 버전으로서 직접 게시할 수 있습니다(그림 81).
작업 그룹의 새로운 주(또는 미리 보기) 버전을 사용할 수 있으면 정의 편집기에 새 버전이 있다는 알림이 표시됩니다. 해당 주 버전이 미리 보기인 경우 "사용해 보세요" 메시지도 표시됩니다. 미리 보기에서 가져온 작업 그룹인 경우 해당 작업 그룹을 사용하는 정의가 자동으로 업데이트되며 주 채널로 제공됩니다(그림 82).
작업 그룹 가져오기 및 내보내기
작업 그룹이 프로젝트 내에서 재사용되도록 설정되어 있으나 다른 프로젝트 및 계정 간에 작업 그룹을 다시 만드는 작업은 까다로운 일일 수 있습니다. 작업 그룹 가져오기/내보내기(그림 83)를 사용하면 릴리스 정의에 대해 수행했듯이 JSON 파일로 내보내고 원하는 위치로 가져올 수 있습니다. 또한 중첩된 작업 그룹도 사용하도록 설정할 수 있습니다. 이 작업 그룹은 내보낼 때 맨 먼저 확장됩니다.
서버 쪽(에이전트 없는) 작업에서 다중 구성 지원
서버 쪽(에이전트 없는) 작업에 대해 변수 승수를 지정하여(그림 84) 병렬로 실행되는 여러 구성에서 동일한 작업 집합을 한 단계로 실행할 수 있습니다.
수동 개입 작업의 변수 지원
수동 개입 작업(그림 85)은 이제 작업이 실행될 때 사용자에게 표시되는 명령 텍스트 내에서 변수를 사용할 수 있도록 지원합니다. 이 시점에서 사용자는 릴리스 프로세스의 실행을 계속하거나 거부할 수 있습니다. 릴리스에서 정의되고 사용 가능한 모든 변수가 포함되며 해당 값은 사용자에게 전송되는 이메일 뿐만 아니라 알림에서도 사용됩니다(그림 86).
소스 분기에 따라 환경에 대한 릴리스 제어
새 릴리스가 만들어질 때, 일반적으로 소스 빌드가 성공적으로 진행된 이후에 자동으로 배포를 트리거하도록 릴리스 정의를 구성할 수 있습니다. 그러나 성공적으로 수행된 빌드를 무조건 배포하기보다 소스의 특정 분기에서 가져온 빌드만 배포하고 싶을 수 있습니다.
예를 들어, 개발 및 테스트 환경에는 모든 빌드를 배포하고 프로덕션 환경에는 특정 빌드만 배포하려고 할 수 있습니다. 이전에는 이 목적으로 개발 및 테스트 환경용 1개, 프로덕션 환경용 1개씩 2개의 릴리스 파이프라인을 유지해야 했습니다.
이제 Release Management를 사용하여 각 환경에 대해 아티팩트 필터를 사용할 수 있습니다. 즉, 배포 트리거 조건(예: 빌드 성공 및 새 릴리스 생성)이 충족될 때 각 환경에 배포되는 릴리스를 지정할 수 있습니다. 환경 배포 조건 대화 상자의 트리거 섹션에서(그림 87) 해당 환경에 대한 새 배포를 트리거하는 아티팩트 조건(예: 빌드에 대한 소스 분기 및 태그)을 선택합니다.
또한 릴리스 요약(그림 88) 페이지에는 이제 "시작되지 않은" 모든 배포가 해당 상태로 있는 이유를 제공하고 배포를 시작하는 방법 또는 시기를 제안하는 팝업 팁이 포함되어 있습니다.
아티팩트 소스로서 Git 리포지토리에 대해 릴리스 트리거 제공
이제 Release Management는 동일한 계정의 모든 팀 프로젝트에 포함된 릴리스 정의에 연결된 Git 리포지토리에 대해 연속 배포 트리거를 구성할 수 있도록 지원합니다(그림 89). 이렇게 하면 리포지토리에 대한 새 커밋이 수행될 때 릴리스를 자동으로 트리거할 수 있습니다. 또한 커밋이 릴리스를 트리거하는 Git 리포지토리의 분기를 지정할 수 있습니다.
릴리스 트리거: Git 리포지토리로 푸시되는 변경 내용에 대한 연속 배포
Release Management는 빌드가 완료될 때 연속 배포를 구성하는 기능을 항상 제공해왔습니다. 그러나 이제 Git 푸시에 대해서도 연속 배포를 구성할 수 있습니다. 즉, GitHub 및 Team Foundation Git 리포지토리를 아티팩트 소스로서 릴리스 정의에 연결한 다음, 빌드에서 생성되지 않아 연속 배포를 위해 빌드 작업이 필요하지 않은 Node.JS 및 PHP와 같은 애플리케이션에 대해 자동으로 릴리스를 트리거할 수 있습니다.
환경 트리거의 분기 필터
이제 새 릴리스 정의 편집기에서 특정 환경에 대한 아티팩트 조건을 지정할 수 있습니다. 이러한 아티팩트 조건을 사용하여 특정 환경에 배포되어야 할 아티팩트에 대한 보다 세부적인 제어를 갖습니다. 예를 들어 프로덕션 환경의 경우 기본 분기에서만 생성된 빌드가 배포되었는지 확인하려고 할 수 있습니다. 이 필터는 이 조건을 충족해야 하는 것으로 예상하는 모든 아티팩트에 대해 설정되어야 합니다.
릴리스 정의에 연결된 각 아티팩트에 대해 여러 필터를 추가할 수도 있습니다(그림 90). 모든 아티팩트 조건이 성공적으로 충족되는 경우에만 이 환경에 배포가 트리거됩니다.
향상된 서버 쪽 작업 기능
서버 쪽 작업(서버 단계 내에서 실행되는 작업)이 2가지 측면에서 개선되었습니다.
제네릭 HTTP REST API(그림 91)를 자동화된 파이프라인의 일부로 호출하는 새 작업이 추가되었습니다. 예를 들어 Azure 함수를 포함하는 특정 처리를 호출하고 완료될 때까지 기다리는 데 이 작업을 사용할 수 있습니다.
또한 모든 서버 쪽 작업에 제어 옵션(그림 92) 섹션을 추가했습니다. 이제 작업 동작에는 사용, 오류 발생 시 계속, 항상 실행 및 시간 제한 옵션 설정이 포함됩니다.
코드 허브의 릴리스 상태 배지
현재, 고객 프로덕션 환경으로 커밋을 배포할지 여부를 알고 싶은 경우 먼저 해당 커밋을 사용할 빌드를 식별하고 이 빌드가 배포되는 모든 릴리스 환경을 확인해야 합니다. 이제 코드가 배포되는 환경 목록을 보여 주는 코드 허브 상태 배지에 배포 상태를 통합할 수 있으므로 이러한 확인이 훨씬 쉬워졌습니다. 모든 배포에서 배포에 속하는 최신 커밋에 상태가 게시됩니다. 커밋이 여러 릴리스 정의(여러 환경 포함)에 배포되면 배지에 각각에 대한 항목이 표시되며 각 환경에 대한 상태가 표시됩니다(그림 93). 이를 통해 배포에 대한 코드 커밋을 쉽게 추적할 수 있습니다.
기본적으로 릴리스 정의를 만들 때 모든 환경에 대한 배포 상태가 게시됩니다. 그러나 상태 배지에 배포 상태가 표시되어야 하는 환경을 선택적으로 표시할 수 있습니다(예: 프로덕션 환경만 표시)(그림 94).
아티팩트를 추가할 때 향상된 빌드 정의 메뉴 기능
이제 릴리스 정의에 빌드 아티팩트를 추가할 때 폴더 조직 정보를 포함하는 정의를 볼 수 있으며 원하는 정의를 간편하게 선택할 수 있습니다(그림 95). 따라서 다른 폴더에 있는 같은 이름의 빌드 정의를 쉽게 구분할 수 있습니다.
정의 목록은 필터 용어를 포함하는 정의에 따라 필터링됩니다.
릴리스 정의를 이전 버전으로 되돌리기
현재, 릴리스 정의가 업데이트될 경우 이전 버전으로 직접 되돌릴 수 없습니다. 유일한 방법은 릴리스 정의 기록을 조회하여 변경된 차이점을 찾아낸 다음 릴리스 정의를 수동으로 편집하는 것입니다. 이제 정의 되돌리기 기능을 사용하여(그림 96) 릴리스 정의 기록 탭에서 릴리스 정의를 선택한 후 이전 버전의 릴리스 정의로 되돌릴 수 있습니다.
릴리스에 대해 개인 설정된 알림
릴리스 알림은 이제 VSTS 알림 설정 환경과 통합됩니다. 이러한 관리 릴리스는 이제 보류 중인 작업(승인 또는 수동 개입) 및 중요한 배포 오류를 자동으로 알립니다. 프로필 메뉴 아래의 알림 설정으로 이동하고 릴리스 구독을 꺼서 이러한 알림을 끌 수 있습니다. 사용자 지정 구독을 만들어 추가 알림에 대해 구독할 수도 있습니다. 관리자는 팀 및 계정 설정 아래의 알림 설정에서 팀 및 그룹에 대한 구독을 제어할 수 있습니다.
릴리스 정의 작성자는 더 이상 승인 및 배포 완료에 대한 이메일을 수동으로 보낼 필요가 없습니다.
이 기능은 릴리스에 대해 여러 이해 관계자가 있는 큰 계정과 알림을 받기 원하는 승인자, 릴리스 작성자 및 환경 소유자 이외의 사람에게 특히 유용합니다(그림 97).
팁
자세한 내용은 릴리스 알림 관리에 대한 게시물을 참조하세요.
테스트
Microsoft Test Manager의 랩 센터 및 자동화된 테스트 흐름에 대한 지원 제거
빌드 및 릴리스 관리가 발전하면서 XAML 빌드는 TFS 2018에서 더 이상 지원되지 않으며 TFS에서 MTM(Microsoft Test Manager)을 사용하기 위해 지원을 업데이트할 예정입니다. MTM의 테스트 센터/랩 센터를 자동 테스트에 사용하는 것도 TFS 2018부터 TFS에서 더 이상 지원되지 않습니다. XAML 빌드 및 랩 센터에서 마이그레이션할 준비가 되지 않은 경우 TFS 2018로 업그레이드하지 않도록 합니다.
아래와 같이 TFS 2018로 업그레이드할 때 미치는 영향을 확인하세요.
랩 센터:
- 더 이상 지원되지 않습니다.
- 랩 환경을 만들고 관리하기 위해 TFS에 Test Controller를 등록할 수 없습니다.
- TFS에 등록된 모든 기존 Test Controller는 오프라인 상태가 되며 기존 랩 환경은 ‘준비되지 않음’으로 표시됩니다.
- 권장되는 대안:
- SCVMM TFS 확장을 사용하여 SCVMM 서버에 연결하고, 가상 머신을 만들고 관리하고, 워크플로를 실행할 수 있습니다. 자세한 내용은 How to perform Lab management operations in Build and Release(빌드 및 릴리스에서 Lab Management 작업을 수행하는 방법)를 참조하세요.
자동화된 테스트:
- 더 이상 지원되지 않습니다.
- Test Controller 및 랩 환경(예: XAML 빌드-배포-테스트 워크플로)에 의존하는 자동화된 테스트 워크플로나 MTM을 사용하여 테스트 계획에서 실행되는 자동화된 테스트는 더 이상 지원되지 않습니다.
- 권장되는 대안:
- 빌드 및 릴리스에서 자동화된 테스트를 실행할 수 있습니다.
- 테스트 허브를 사용하여 테스트 계획에서 자동화된 테스트를 실행할 수 있습니다.
수동 테스트:
- 모든 수동 테스트 시나리오는 계속 완벽하게 지원됩니다. TFS 2018에서 MTM을 사용하여 수동 테스트를 실행할 수 있지만 수동 테스트를 실행하는 데 랩 환경은 사용할 수 없습니다.
- 모든 수동 테스트 시나리오에서는 TFS 웹 액세스의 테스트 허브를 사용할 것을 강력히 권장합니다.
작업 항목 링크, 반복 및 영역 경로에 대한 예비 테스트 추적 가능성 개선
예비 테스트를 수행하는 팀에서 얻은 의견에 따라, 테스트 및 피드백 확장에서 얻은 버그, 작업 또는 테스트 사례를 정리하면서 추적 가능 링크를 개선하고 있습니다. 요구 사항을 탐색하면서 만든 버그 및 작업은 이제 팀 기본값 대신 요구 사항과 동일한 영역 경로 및 반복을 사용하여 만들어집니다. 이제 요구 사항을 확인하면서 만드는 테스트 사례는 부모 <-> 자식 링크가 아닌 테스트 <-> 테스트한 사람 링크에 연결되므로 만드는 테스트 사례가 요구 사항 기반의 테스트 도구 모음에 자동으로 추가됩니다. 마지막으로 요구 사항을 특별히 확인하지 않으면서 만드는 작업 항목은 현재 반복 대신 팀의 기본 반복에 정리되므로 스프린트 계획이 완료된 후에는 새 작업 항목이 현재 반복에 포함되지 않습니다.
테스트 허브의 테스트 계획 및 테스트 도구 모음에 제공되는 테스트 사례 작업 항목용 필터
테스트 필드(예: 결과, 구성 및 테스터) 외에도 테스트 사례 작업 항목 필드(예: 제목, 상태 및 할당 대상)에 대해서도 필터링할 수 있습니다(그림 98).
릴리스 환경 및 테스트 실행에 대한 테스트 추세 차트
테스트 결과 추세 위젯에 릴리스 환경에 대한 지원을 추가하고 있으므로(그림 99) VSTS 대시보드에서 테스트 환경의 상태를 추적할 수 있습니다. 빌드에서 테스트 결과에 대해 수행하는 것과 같은 방식으로, 이제 릴리스 환경에 대한 테스트 통과 비율, 총 테스트 수, 통과 또는 실패한 테스트, 테스트 기간을 보여 주는 추세 차트를 만들 수 있습니다. 테스트 실행 제목 필터를 사용하여 환경 내의 특정 테스트 실행으로 차트를 필터링할 수도 있습니다.
테스트 실행 및 테스트 결과 주석에 대한 Markdown 형식 지원
Markdown 구문을 사용하여 테스트 실행 및 테스트 결과 주석의 형식을 지정할 수 있습니다. 이 기능을 사용하여 주석에서 형식이 지정된 텍스트를 만들거나 URL에 대한 빠른 링크를 만들 수 있습니다. 테스트 결과 주석은 업데이트 분석을 사용하여 결과 요약 페이지에서 업데이트할 수 있고, 테스트 실행 주석은 테스트 허브의 업데이트 주석을 사용하여 실행 요약 페이지에서 업데이트할 수 있습니다.
실패한 테스트에 대한 기존 버그 링크 추가
빌드 또는 릴리스 요약 페이지나 테스트 허브에서 테스트 결과를 분석하는 동안 기존 버그를 실패한 테스트에 연결할 수 있습니다. 이 기능은 버그가 이미 보고된 알려진 원인으로 인해 테스트가 실패한 경우 유용합니다.
테스트 실행 및 테스트 결과에 첨부 파일 업로드
이제 추가 정보로 테스트 실행 또는 테스트 결과에 스크린샷과 로그 파일과 같은 파일을 첨부할 수 있습니다. 이 시점까지 이 기능은 VSTS/TFS 및 MTM 클라이언트에서 테스트 허브 간 컨텍스트를 전환하도록 강요하는 MTM(Microsoft Test Manager) 클라이언트를 통해서만 사용할 수 있었습니다.
테스트 일괄 처리
빌드/릴리스 관리의 Visual Studio 테스트 작업에서 테스트가 효율적인 실행을 위해 그룹화(일괄 처리)되어야 하는 방식을 제어하는 데 옵션을 사용할 수 있습니다. 두 가지 방법으로 테스트를 그룹화할 수 있습니다.
- 실행에 참여하는 테스트 에이전트의 수에 따라 테스트를 지정된 크기의 일괄 처리 수로 단순히 그룹화합니다.
- 과거 테스트의 실행 시간을 기반으로 테스트의 일괄 처리를 만드는 과거 실행 시간을 각 일괄 처리에 거의 동일한 실행 시간이 있다고 간주합니다(그림 100). 빠른 테스트 실행은 함께 일괄 처리되지만, 더 긴 테스트 실행은 별도의 일괄 처리에 속할 수 있습니다. 이 옵션은 총 테스트 시간을 최소한으로 줄이기 위해 여러 에이전트 단계 설정으로 구성될 수 있습니다.
VSTest 작업을 사용하여 웹 테스트 실행
Visual Studio 테스트 작업을 사용하여 웹 성능 테스트라고도 알려진 웹 테스트를 이제 CI/CD 파이프라인에서 실행할 수 있습니다. 테스트를 작업 어셈블리 입력에서 실행하도록 지정하여 웹 테스트를 실행할 수 있습니다. 웹 테스트에 연결된 "관련된 자동화"가 있는 테스트 사례 작업 항목은 작업에서 테스트 계획/테스트 도구 모음을 선택하여 실행할 수도 있습니다(그림 101).
웹 테스트 결과를 테스트 결과에 대한 첨부 파일로 사용할 수 있습니다(그림 102). Visual Studio에서 오프라인 분석을 위해 다운로드할 수 있습니다.
이 기능은 Visual Studio 테스트 플랫폼의 변경에 따라 달라지며, 빌드/릴리스 에이전트에 Visual Studio 2017 업데이트 4가 설치되어 있어야 합니다. 이전 버전의 Visual Studio를 사용하여 웹 테스트를 실행할 수 없습니다.
마찬가지로, 기능 테스트 실행 작업을 사용하여 웹 테스트를 실행할 수 있습니다. 이 기능은 Visual Studio 2017 업데이트 5에서 사용할 수 있는 테스트 에이전트의 변경 내용에 따라 달라집니다.
팁
이 기능을 부하 테스트와 함께 사용할 수 있는 방법의 예제로 Visual Studio 및 VSTS 빠른 시작을 사용하여 클라우드에서 앱 부하 테스트를 참조하세요.
테스트 계획 및 테스트 도구 모음에 대한 차트 위젯
이전에 테스트 허브에서 테스트 계획 및 도구 모음에 대한 차트를 만들고 대시보드에 고정할 수 있었습니다. 이제 대시보드의 위젯 카탈로그에서 테스트 계획 및 도구 모음에 대한 차트를 만들 수 있도록 하는 위젯을 추가했습니다. 테스트 작성 상태 또는 테스트 실행 상태에 대한 차트를 만들 수 있습니다. 또한 위젯에서 차트를 추가하여 차트에 표시할 데이터가 많은 경우 더 큰 차트를 만들 수 있습니다(그림 103).
수동 테스트를 위해 Chrome 브라우저를 사용하여 데스크톱 앱에 대한 스크린샷 및 주석 지원
수동 테스트에서 상위 제안 중 하나에 대해 테스트 허브의 웹 Test Runner에서 데스크톱 애플리케이션의 스크린샷을 캡처하는 지원을 추가합니다. 지금까지 Microsoft Test Manager의 Test Runner를 사용하여 데스크톱 앱의 스크린샷을 캡처해야 했습니다. 이 기능을 사용하기 위해 테스트 및 피드백 확장을 설치해야 합니다. Chrome 브라우저에 대한 지원을 공개하며 Firefox에서 그 후에 즉시 따를 예정입니다.
SharePoint에 대한 TFS 확장 중단
TFS 2018 이상 버전은 SharePoint에 대한 TFS 확장을 더 이상 지원하지 않습니다. 또한 TFS 서버와 SharePoint 서버 간에 통합을 구성하는 데 사용되는 화면이 Team Foundation 관리 콘솔에서 제거되었습니다.
참고 항목
SharePoint와 통합하도록 구성된 이전 버전에서 TFS 2018로 업그레이드하는 경우 업그레이드 후 SharePoint 통합을 사용하지 않도록 설정해야 합니다. 그렇지 않으면 TFS SharePoint 사이트에서 로드에 실패합니다.
SharePoint 서버에서 통합을 사용하지 않도록 할 수 있는 솔루션을 만들었습니다. 자세한 내용은 TFS/SharePoint 통합의 미래에 대한 게시물을 참조하세요.
단체방 중단
최신 개발 팀은 협업에 대한 업무가 가중되어 있습니다. 사용자는 작업(알림)을 모니터링하고 이에 대해 대화(채팅)할 장소를 원하며 필요합니다. 몇 년 전에 이러한 추세를 인식하고 이러한 시나리오를 지원하기 위한 단체방을 빌드했습니다. 그 이후에 공동 작업을 위한 다양한 솔루션이 등장했습니다. 가장 주목할 만한 것은 Slack의 등장입니다. 또 좀 더 최근에는 Microsoft Teams가 발표되었습니다.
TFS 및 Visual Studio Team Services와 원활하게 통합되는 다양한 솔루션이 제공되면서 TFS 2018과 Visual Studio Team Services에서 단체방 기능을 제거할 예정임을 1월에 발표하게 되었습니다.
어떠셨나요?
많은 의견 부탁드립니다! 개발자 커뮤니티를 통해 문제를 보고 및 추적하고 Stack Overflow에서 조언을 얻을 수 있습니다.