Team Foundation Server 2017 릴리스 정보
Developer Community | 시스템 요구 사항 및 호환성 | 사용 조건 | TFS DevOps 블로그 | SHA-1 해시 | | 최신 Visual Studio 2019 릴리스 정보|
참고
최신 버전의 Team Foundation Server가 아닙니다. 최신 릴리스를 다운로드하려면 Team Foundation Server 2018 업데이트 3용 현재 릴리스 정보를 방문하세요. 페이지 바닥글에서 지구본 아이콘을 클릭하고 원하는 언어를 선택하여 이 페이지의 언어를 변경할 수 있습니다.
이 문서에는 Team Foundation Server 2017에 대한 정보가 제공됩니다. 단추를 클릭하여 다운로드합니다.
Team Foundation Server 2017에 대한 자세한 내용은 Foundation Server 요구 사항 및 호환성 페이지를 참조하세요.
자세한 정보는 TFS 설치 페이지를 참조하세요.
릴리스 날짜: 2018년 2월 28일
이 업데이트는 잠재적인 교차 사이트 스크립팅(XSS) 및 기타 보안 취약점을 해결합니다. 자세한 내용은 블로그 게시물을 참조하세요. 전체 업그레이드이므로 TFS 2017.0.1로 직접 업그레이드할 수 있습니다.
릴리스 날짜: 2016년 11월 16일
Team Foundation Server 2017의 새로운 기능에 대한 요약
- 코드 검색
- 패키지 관리
- Agile 기능 향상
- 대시보드 및 위젯 개선
- Git 기능 향상
- 빌드 기능 향상
- Release Management 기능 향상
- 테스트 기능 향상
- 마켓플레이스기능 향상
- 관리 기능 향상
- 개인용 액세스 토큰
알려진 문제
Team Foundation Server 2017의 새로운 기능에 대한 세부 정보
코드 검색
코드 검색 기능은 전체 코드를 빠르고 유연하며 정확하게 검색할 수 있게 해줍니다. 코드베이스가 여러 프로젝트와 리포지토리로 분할되어 확장되기 때문에 필요한 항목을 찾기가 점점 더 어렵습니다. 코드 검색은 팀 간 협업과 코드 공유를 극대화하기 위해 모든 프로젝트에서 관련 정보를 빠르고 효율적으로 찾습니다.
코드 검색은 구현된 API 예제 찾기부터 정의 검색, 오류 텍스트 검색까지 코드 탐색과 문제 해결에 필요한 모든 사항을 해결해주는 원스톱 솔루션입니다 (그림 1) .
코드 검색에서는 다음이 가능합니다.
- 하나 이상의 프로젝트를 범위로 검색
- 의미 체계 순위 지정
- 기능이 풍부한 필터링
- 코드 협업
자세한 내용은 참조하세요.
패키지 관리
패키지를 사용하면 조직에서 코드를 공유할 수 있습니다. 대규모 제품을 작성하거나 공통 공유 프레임워크를 기반으로 다양한 제품을 개발하거나 재사용 가능한 구성 요소 및 라이브러리를 만들고 공유할 수 있습니다. 패키지 관리 (그림 2) 를 사용하면 패키지를 호스트한 후 선택한 사용자와 공유하여 사용자가 Team Build와 Release Management에 쉽게 액세스할 수 있도록 함으로써 코드를 쉽게 공유할 수 있게 해줍니다.
패키지 관리에서는 Team Foundation Server에서 직접 NuGet 패키지를 호스팅하기 때문에 별도의 NuGet 서버 또는 파일 공유를 호스팅할 필요가 없습니다. 또한 NuGet 2.x 레거시 클라이언트뿐만 아니라 NuGet 3.x을(를) 최상의 수준으로 지원합니다. 기존의 TFS 인프라, 팀 및 권한과 원활하게 작동하므로 ID 동기화, 여러 위치에서 그룹 관리 등을 처리할 필요가 없습니다. 그뿐만 아니라 팀 빌드와 쉽게 통합되기 때문에 연속 통합 워크플로에서 패키지를 만들어 사용할 수 있습니다.
자세한 내용은 패키지 관리 개요를 참조하세요.
Agile 기능 향상
Team Foundation Server 2017에는 작업 항목 및 Kanban 보드에 새로운 특징과 기능이 추가되었습니다.
새 작업 항목 폼
새 작업 항목 (그림 3) 폼의 모양과 느낌이 새로워졌습니다. 또한 다음과 같은 멋진 새로운 특징이 추가되었습니다.
- 기능이 풍부한 작업 항목 토론 환경
- 첨부 파일에 대해 끌어서 놓기 지원.
- 향상된 기록 환경(기록 및 감사).
- 향상된 코드 및 빌드 통합
- 상태 색 지정.
- 반응이 빠른 디자인.
참고
새 작업 항목 폼은 새 컬렉션에 대해서만 기본값입니다. 기존 컬렉션을 마이그레이션하는 경우 관리 설정에서 새 작업 항목 폼을 사용하도록 설정해야 합니다. 자세한 내용은 Manage roll out of the new web form(새 웹 폼의 출시 관리)을 참조하세요.
작업 항목 추적
이제 폼에서 새 “팔로우” 단추 (그림 4) 클릭만으로 단일 작업 항목의 변경 내용을 추적할 수 있는 알림을 설정할 수 있습니다. 한 작업 항목을 추적하면 필드 업데이트, 링크, 첨부 파일 및 주석을 포함하여 작업 항목이 변경될 때마다 알림을 받게 됩니다.
자세한 내용은 팔로우를 참조하세요.
Kanban 보드의 실시간 업데이트
이제 Kanban 보드 상황을 실시간으로 알 수 있습니다.
그날의 Kanban 보드를 사용하여 하루 동안 진행되는 상황을 파악하기 위해 F5 키를 누른 적이 있나요? 아래 스크린샷에 나온 아이콘을 사용해 보세요 (그림 5) .
팀 구성원이 보드에서 작업 항목을 만들거나 업데이트하거나 삭제하면 그 즉시 보드에 대한 실시간 업데이트를 받게 됩니다. 또한 관리자가 새 열 추가 또는 백로그에 버그 사용과 같은 보드 또는 팀 수준 업데이트를 수행하는 경우 보드를 새로 고쳐 보드 레이아웃을 업데이트하라는 알림을 받습니다. 이 경우 Kanban 보드에서 타워 모양의 아이콘을 사용하도록 설정하고 팀과의 공동 작업을 시작하기만 하면 됩니다.
자세한 내용은 Kanban 기본 사항을 참조하세요.
검사 목록 개선
검사 목록 작동 방식과 관련하여 몇 가지 기능이 향상되었습니다.
이제 검사 목록 제목이 하이퍼링크로 나타납니다 (그림 6) . 제목을 클릭하여 작업 항목 폼을 열 수 있습니다.
또한 검사 목록 항목을 열거나 편집하거나 삭제할 수 있는 상황에 맞는 메뉴가 지원됩니다 (그림 7) .
자세한 내용은 작업 검사 목록 추가를 참조하세요.
에픽 및 기능 보드 드릴다운
이제 에픽 및 기능 보드에서 드릴다운할 수 있습니다 (그림 8) . 검사 목록 형식을 사용하면 작업을 완료됨으로 쉽게 표시할 수 있고, 완료된 작업과 처리되지 않은 작업을 비교한 조감 형태의 편리한 뷰가 제공됩니다.
자세한 내용은 Kanban 기능 및 에픽을 참조하세요.
보드 주석 설정/해제
보드의 카드에 표시되는 추가 정보를 더 세밀하게 조정할 수 있습니다. 이제 Kanban 카드에서 볼 주석을 선택할 수 있습니다 (그림 9) . 간단히 주석을 선택 취소하면 Kanban 보드의 카드에서 주석이 사라집니다. 여기에 나타난 첫 번째 주석 두 개는 자식 작업 항목(이 예에서는 작업)과 테스트 주석입니다.
자세한 내용은 카드 사용자 지정을 참조하세요.
서식 지우기 명령
선택한 텍스트에서 모든 서식을 지울 수 있는 새로운 명령이 작업 항목의 모든 서식 있는 텍스트 컨트롤에 추가되었습니다. 대부분의 사용자와 마찬가지로 이전에 서식 있는 텍스트를 복사하여 필드에 붙여넣었다가 실행 취소하거나 지울 수 없어 속을 끓인 적이 있을 것입니다. 이제 텍스트를 강조 표시하고 [서식 지우기] 도구 모음 단추를 선택하거나 Ctrl+스페이스바를 누르기만 하면 텍스트가 기본 서식으로 돌아갑니다.
Kanban 보드의 필터링 기능
사용자, 반복, 작업 항목 형식 및 태그에 필터를 설정하여 Kanban 보드를 개인 설정할 수 있습니다 (그림 10) . 이러한 필터는 여러 디바이스에서 연결하는 경우에도 계속 유지되므로 개인 설정된 보드를 볼 수 있습니다.
또한 이제 팀 멤버가 보드를 필터링하여 특정 부모 작업 항목에 발생하는 진행률을 볼 수 있습니다. 예를 들어 사용자는 기능에 연결된 사용자 스토리를 보거나, 에픽에 롤업되는 두 개 이상의 기능에 걸친 작업을 볼 수 있습니다. 검사 목록과 매우 유사한 이 기능은 여러 백로그 수준의 가시성을 제공하려는 우리의 노력에 추가된 하나의 단계입니다.
자세한 내용은 필터 Kanban 보드를 참조하세요.
새 작업 항목에 대한 기본 반복 경로
쿼리 탭이나 새 작업 항목 대시보드 위젯에서 새 작업 항목을 만들면 해당 작업 항목의 반복 경로가 언제나 현재의 반복 경로로 설정됩니다. 이 경우 버그가 작업 보드에 바로 표시될 수 있으므로 이 기능을 원하지 않는 팀도 있습니다. 이 점을 개선하여 이제 팀에서 새 작업 항목에 사용할 기본 반복 경로(특정 경로 또는 현재의 반복 경로)를 선택할 수 있습니다. 팀의 관리 영역으로 이동하여 기본 반복 경로를 선택하면 됩니다.
자세한 내용은 Customize area and iteration paths(영역 및 반복 경로 사용자 지정) 페이지를 참조하세요.
CheckBox 컨트롤
이제 작업 항목에 Checkbox 컨트롤을 추가할 수 있습니다 (그림 11) . 이 새 필드 형식(부울)은 일반 필드의 모든 속성을 갖고 있기 때문에 프로세스의 모든 형식에 추가할 수 있습니다. 카드 또는 쿼리 결과에 나타나는 값은 True/False로 표시됩니다.
자세한 내용은 필드 사용자 지정을 참조하세요.
태그 일괄 편집
이제 [대량 편집] 대화 상자를 사용하여 여러 작업 항목에서 태그를 추가 및 제거할 수 있습니다 (그림 12) .
자세한 내용은 작업 항목에 태그 추가를 참조하세요.
새 확장점
[보드/백로그/용량] 탭 옆에 있는 [피벗] 탭으로 확장을 작성할 수 있도록 보드 및 백로그 페이지에 새로운 기여 지점이 추가되었습니다.
백로그에 새 확장 지점을 도입했습니다. 확장은 현재 매핑 및 작업 세부 정보가 있는 오른쪽 창을 대상으로 지정할 수 있습니다 (그림 13) .
전자 메일 기능 향상
TFS에서 보낸 작업 항목 경고, 팔로우 및 @mention 이메일의 서식과 유용성이 크게 향상되었습니다(그림 14). 이제 전자 메일은 헤더가 일관되고 행동 유도 문구가 명확하며 서식이 개선되어 메일 정보를 사용하고 이해하기가 더 쉬워졌습니다. 또한 이러한 모든 전자 메일이 모바일 디바이스에서 제대로 렌더링되도록 디자인 중입니다.
자세한 내용은 작업 항목 경고를 참조하세요.
작업 항목 템플릿
다양한 작업 항목 템플릿을 만들 수 있는 기능을 기본 웹 환경에 직접 추가했습니다 (그림 15) . 이전에는 이 기능이 웹에서 매우 제한되었으며 이 새 폼에서 Visual Studio 파워 도구를 통해서만 사용할 수 있었습니다. 이제 팀에서 템플릿 집합을 만들고 관리하여 공용 필드를 빠르게 수정할 수 있습니다.
자세한 내용은 작업 항목 템플릿을 참조하세요.
Project Server 통합이 더 이상 지원되지 않음
Team Foundation Server 2017 이상 버전에서는 Project Server 통합을 더 이상 지원하지 않습니다. RC2부터 Project Server 통합이 구성된 TFS 데이터베이스를 업그레이드하면 다음과 같은 경고가 표시됩니다.
이 데이터베이스에 대해 Project Server 통합이 구성되어 있음을 발견했습니다. Team Foundation Server 2017 이상 버전에서는 Project Server 통합을 더 이상 지원하지 않습니다.
업그레이드한 후에는 Project Server 통합이 더 이상 작동하지 않습니다.
향후 파트너가 통합 솔루션을 제공합니다.
이 변경 내용에 대한 자세한 내용은 다음 항목을 참조하세요. 프로젝트 서버와 TFS 동기화.
대시보드 및 위젯 개선
Team Foundation Server 2017에서는 쿼리 타일이나 끌어오기 요청 위젯과 같은 여러 위젯을 개선했습니다.
새로 디자인한 위젯 카탈로그
증가하는 위젯 수를 수용하고 더 나은 전반적인 환경을 제공하기 위해 위젯 카탈로그가 다시 디자인되었습니다 (그림 16) . 새 디자인은 위젯 구성 패널의 디자인에 맞도록 스타일을 조정한 것으로, 검색 환경 등이 새로워졌습니다.
자세한 내용은 위젯 카탈로그를 참조하세요.
위젯 업데이트
[쿼리 타일] 위젯에서 최대 10개의 조건부 규칙을 사용할 수 있고 색을 선택할 수 있습니다 (그림 17) . 이는 이러한 타일을 KPI(핵심 성과 지표)로 사용하여 필요할 수 있는 상태 및/또는 작업을 식별하려는 경우에 매우 편리합니다.
끌어오기 요청 위젯에서 다양한 크기를 사용할 수 있어 위젯의 높이를 조정할 수 있습니다. 제공하는 대부분의 위젯을 크기 조정할 수 있도록 만들려고 노력하고 있으며, 이 업데이트에서 자세한 내용을 살펴보세요.
이제 새 작업 항목 위젯을 사용하면, 드롭다운 목록에서 반복하여 만드는 가장 일반적인 형식을 선택하도록 강요하는 대신, 기본 작업 항목 형식을 선택할 수 있습니다.
WIT 차트 위젯의 크기는 조정할 수 있습니다. 따라서 사용자가 원래 크기에 관계없이 대시보드에서 WIT 차트의 확장된 보기를 볼 수 있습니다.
다른 사람을 팀에 쉽게 추가할 수 있도록 [팀 멤버] 위젯이 업데이트되었습니다 (그림 18) .
이제 팀이 더 많은 결과를 표시하도록 대시보드의 쿼리 결과 위젯 크기를 구성할 수 있습니다.
팀에서 작업이 정상적으로 진행되고 있는지 더 쉽게 확인할 수 있도록 [스프린트 개요] 위젯이 다시 디자인되었습니다.
사용자는 [내게 할당됨] 위젯을 통해 대시보드 컨텍스트를 벗어나지 않고 할당받은 작업을 관리할 수 있습니다 (그림 19) . 팀 관리자는 이 용도로만 사용되는 위젯을 제공하므로 컨텍스트 전환이나 입력을 할 필요 없이 16번 미만의 클릭으로 대시보드에 이 기능을 추가할 수 있습니다. 이제 사용자는 위젯 컨텍스트 내에서 할당받은 작업을 보고, 정렬, 필터링 및 관리할 수 있습니다.
대시보드 REST API
이제 REST API를 사용하여, 대시보드에서 프로그래밍 방식으로 정보를 추가하고 삭제하고 가져올 수 있습니다. 또한 API에서 대시보드에 있는 위젯 또는 위젯 목록에 대한 정보를 추가, 제거, 업데이트, 바꾸고 가져올 수도 있습니다. 해당 설명서는 Visual Studio online docs(Visual Studio 온라인 문서)에 있습니다.
허용 가능한 대시보드
이제 관리자가 아닌 사용자가 팀 대시보드를 만들고 관리할 수 있습니다. 팀 관리자는 대시보드 관리자를 통해 관리자가 아닌 사용 권한을 제한할 수 있습니다.
자세한 내용은 대시보드를 참조하세요.
Git 기능 향상
Team Foundation Server 2017에서는 Git 관련 주요 변경 사항이 몇 가지 있습니다. [분기] 페이지가 다시 디자인되고 "Squash 병합"에 대한 새 옵션이 추가되었습니다.
새로 디자인한 분기 페이지
분기 페이지가 완전히 새롭게 디자인되었습니다. 이제 분기 페이지에는 사용자가 만들고 즐겨찾기에 추가했거나 푸시 목적지가 된 분기를 보여 주는 “내 항목” 피벗이 있습니다 (그림 20) . 각 분기는 삭제와 같은 기타 명령뿐만 아니라 빌드와 끌어오기 요청 상태도 보여 줍니다. 분기 이름에 "features/jeremy/fix-bug"와 같이 슬래시가 있으면 분기가 트리로 표시되기 때문에 대형 목록으로 구성된 분기를 쉽게 검색할 수 있습니다. 분기 이름을 알고 있으면 신속하게 원하는 분기를 검색하여 찾을 수 있습니다.
분기에 대한 자세한 내용은 분기 관리를 참조하세요.
새로운 끌어오기 요청 환경
이번 릴리스에서 끌어오기 요청 환경에 몇 가지 주요 업데이트가 포함되어, 매우 강력한 diff 기능, 새로운 주석 처리 환경 및 디자인이 완전히 새로워진 UI를 제공합니다.
자세한 내용은 끌어오기 요청을 사용하여 코드 검토를 참조하세요.
새롭게 디자인된 UI
끌어오기 요청을 열면 새로운 모양과 느낌을 금방 알 수 있습니다 (그림 21) . 환경의 모든 보기에서 액세스할 수 있도록 중요한 상태와 작업을 모두 요약하는 헤더가 다시 구성되었습니다.
개요
개요에서는 이제 PR 설명을 강조 표시하며 이전보다 쉽게 피드백을 제공할 수 있습니다 (그림 22) . 이벤트 및 주석에서는 최신 항목이 맨 위에 표시되므로 검토자가 최신 변경 내용 및 주석을 전면 중앙에서 볼 수 있습니다. 정책, 작업 항목 및 검토자가 모두 자세히 제공되며 더 깔끔하고 간결하게 다시 구성되었습니다.
파일
이 릴리스에서 가장 중요한 새 기능은 끌어오기 요청에 대한 이전 업데이트를 볼 수 있는 기능입니다 (그림 23) . 이전 미리 보기에서 PR이 변경 내용으로 업데이트될 때 주석을 제대로 추적할 수 있는 기능을 릴리스했습니다. 하지만 업데이트 사이의 내용을 확인하는 일이 쉽지만은 않습니다. 이제 파일 보기에서 새 코드가 PR로 푸시될 때마다 변경된 내용을 정확히 확인할 수 있습니다. 일부 코드에서 피드백을 받았는데 코드 변경 내용을 검토의 다른 모든 변경 내용과 분리해서 정확히 확인하려는 경우 이 기능이 매우 유용합니다.
Updates
새로운 [업데이트] 보기에는 시간이 지남에 따라 PR이 변경되는 방식이 표시됩니다 (그림 24) . 파일 보기에 파일이 시간에 따라 어떻게 변경되는지 표시된다면 업데이트 보기에는 각 업데이트에서 추가된 주석이 표시됩니다. 강제 보내기가 발생하는 경우 업데이트 보기에는 과거에 발생한 이전 업데이트가 계속 표시됩니다.
이제 마크다운과 이모지를 사용하는 주석
모든 토론에서 서식 지정, 구문 강조 표시를 사용한 코드, 링크, 이미지, 이모지 등과 같은 markdown의 기능을 최대한 활용하세요 (그림 25) . 또한, 주석 처리 컨트롤에서는 여러 주석을 한 번에 편집한 다음 저장할 수 있는, 사용자에게 더 친숙한 편집 환경을 제공합니다.
끌어오기 요청에서 검토자 추가 및 제거
이제 끌어오기 요청에서 검토자를 쉽게 추가하고 제거할 수 있습니다. 끌어오기 요청에 검토자 또는 그룹을 추가하려면 검토자 섹션의 검색 상자에 해당 이름을 입력하면 됩니다. 검토자를 제거하려면 검토자 섹션에서 해당 타일을 마우스로 가리킨 후 X를 클릭하여 제거하면 됩니다 (그림 26) .
빌드와 끌어오기 요청 간의 추적 가능성 향상
빌드와 끌어오기 요청 간의 추적 가능성이 향상되어 PR에서 빌드까지 쉽게 이동하고 다시 돌아갈 수 있습니다. 끌어오기 요청으로 트리거된 빌드의 빌드 정보 뷰에는 빌드를 큐에 대기하게 한 끌어오기 요청의 링크가 소스에 표시됩니다. 빌드 정의 뷰에는 끌어오기 요청으로 트리거된 빌드의 "트리거 기준" 열에 끌어오기 요청 링크가 나타납니다. 마지막으로, 빌드 탐색기 뷰의 소스 열에는 끌어오기 요청이 나열됩니다.
끌어오기 요청에 대한 주석 추적
주석이 추가된 이후에 파일이 변경된 경우에도 파일에 남아 있는 주석이 적절한 줄에 표시되도록 VSTS의 끌어오기 요청이 향상되었습니다. 이전에는 파일 내용이 변경된 경우에도 주석이 항상 원래 추가된 파일의 줄에 표시되었습니다. 즉, 줄 10의 주석이 항상 줄 10에 표시되었습니다. 향상된 최신 기능에 따라 주석은 사용자가 기대하는 결과를 표시하는 코드를 따릅니다. 즉, 주석이 10번째 줄에 추가되고, 나중에 파일의 시작 부분에 두 줄이 새로 추가되면 해당 주석이 12번째 줄에 표시됩니다.
다음은 13번째 줄에 주석이 배치되는 변경 예제입니다 (그림 27) .
원래 주석이 있는 줄이 13에서 14로 이동하도록 코드가 변경된 후에도 주석은 예상된 위치(줄 14)에 표시됩니다 (그림 28) .
자동 완성 끌어오기 요청이 정책에서 대기 중
분기 정책을 사용하여 분기를 보호하는 팀은 자동 완성 작업을 체크 아웃하려고 합니다. 대부분의 경우 끌어오기 요청을 만드는 작성자는 자신의 PR을 병합할 준비가 되어 있지만 빌드가 완료될 때까지 기다린 후에 완료를 클릭할 수 있습니다. 때로는 빌드가 통과되었지만 최종 승인을 받지 않은 한 명의 검토자가 있습니다. 이러한 경우에 만든 이는 자동 완성 작업을 사용하여 정책이 모두 승인되는 즉시 PR이 자동으로 완료되도록 설정할 수 있습니다 (그림 29) .
수동 완성 작업과 마찬가지로 만든 이는 병합 커밋의 메시지를 사용자 지정하고 적절한 병합 옵션을 선택할 수 있습니다 (그림 30) .
자동 완성이 설정되면 PR에 자동 완성이 설정되었고 정책이 완료될 때까지 대기 중임을 확인하는 배너가 표시됩니다 (그림 31) .
모든 정책이 충족되면(예: 빌드가 완료되거나 해당 최종 승인이 부여되는 경우) PR이 지정된 옵션과 주석을 사용하여 병합됩니다. 예상대로 빌드 오류가 발생하거나 검토자가 승인하지 않으면 정책이 통과될 때까지 PR이 활성 상태로 유지됩니다.
끌어오기 요청에 대한 Squash 병합
끌어오기 요청을 작성할 때 Squash 병합을 할 수 있습니다 (그림 32) . 이 새 옵션을 사용하면 대상 분기에 적용할 토픽 분기의 변경 내용이 포함된 단일 커밋이 생성됩니다. 일반 병합과 Squash 병합의 가장 중요한 차이는 Squash 병합 커밋의 부모 커밋이 단 한 개라는 점입니다. 따라서 토픽 분기에 대한 중간 커밋이 결과 커밋 그래프에 연결될 수 없기 때문에 기록 그래프가 단순해집니다.
끌어오기 요청에 대한 Squash 병합에서 더 많은 정보를 확인할 수 있습니다.
커밋 추적 가능성
빌드 상태(성공 또는 실패)를 [코드 탐색기] 및 [커밋 정보] 뷰에서 명확하게 볼 수 있습니다 (그림 33) . 단지 클릭하기만 하면 자세한 내용이 표시되므로 언제든지 커밋의 변경 내용이 빌드에서 통과했는지 알 수 있습니다. 또한 빌드 정의에 대한 상태를 리포지토리 옵션에 게시할 빌드를 사용자 지정할 수도 있습니다. 그 외에도 커밋 정보 뷰가 최근에 변경되어 변경 항목에 대한 심층 정보를 제공합니다. 끌어오기 요청을 사용하여 변경 내용을 병합하는 경우 변경 내용을 기본 분기에 도입하는 끌어오기 요청에 대한 링크(또는 병합 커밋의 경우 끌어오기 요청을 만든 PR)가 표시됩니다. 변경 내용이 기본 분기에 도달하면 변경 내용이 적용되었음을 확인할 수 있는 분기 링크가 나타납니다.
웹에서 Git LFS 파일 보기
이미 Git의 대형 파일(오디오, 비디오, 데이터 세트 등)을 사용하고 있는 경우, Git LFS(대형 파일 스토리지)에서 원격 서버에 파일 내용을 저장하면서 이러한 파일을 Git 내부의 포인터로 바꾼다는 것을 알고 있습니다. 따라서 리포지토리에서 간단히 파일을 클릭하여 이러한 대형 파일의 전체 콘텐츠를 볼 수 있습니다.
자세한 내용은 Git을 사용하여 대용량 파일 관리를 참조하세요.
특정 코드 섹션의 링크 만들기 및 전송
코드 링크와 함께 코드 참조를 쉽게 공유할 수 있습니다 (그림 34) . 파일에서 텍스트를 선택하고 링크 아이콘을 클릭하면 됩니다. 그러면 링크가 선택한 코드에 복사됩니다. 다른 사람이 이 링크를 볼 때는 사용자가 강조 표시한 코드가 금색 배경으로 처리됩니다. 이 기능은 부분 줄을 선택하는 경우에도 유용합니다.
상태 API
이제 빌드의 성공 또는 실패를 [코드 탐색기] 및 [커밋 정보] 뷰에서 명확하게 볼 수 있습니다 (그림 35) . 단지 클릭하기만 하면 자세한 내용이 표시되므로 언제든지 커밋의 변경 내용이 빌드에서 통과했는지 알 수 있습니다. 또한 빌드 정의를 위해 리포지토리 옵션에 빌드 상태를 게시할 빌드를 사용자 지정할 수도 있습니다.
파일 형식 아이콘
탐색기의 파일 확장명, 끌어오기 요청, 커밋 세부 정보, shelveset, 변경 집합 또는 파일의 목록을 보여 주는 다른 뷰와 일치하는 새 파일 아이콘이 표시됩니다 (그림 36) .
리포지토리를 만드는 동안 추가 정보 추가
사용자가 추가 정보 파일을 추가할 수 있는 기능을 제공함으로써 새 Git 리포지토리 만들기가 향상되었습니다 (그림 37) . 리포지토리에 추가 정보를 추가하면 리포지토리를 즉시 복제할 수 있을 뿐만 아니라 다른 사용자가 코드베이스의 용도를 이해하는 데 도움이 됩니다.
빌드 기능 향상
이 릴리스에서는 몇 가지 변경 내용을 제시하기 위해 로그 크기가 증가되고, Java 빌드 템플릿이 추가되고, Xamarin 지원이 향상되었습니다.
새로 디자인된 빌드 큐 탭
큐에 대기 중인 빌드와 실행 중인 빌드의 목록을 더 길고 직관적인 방식으로 표시하도록 [큐에 넣음] 빌드 페이지에 대한 새로운 디자인이 구현되었습니다 (그림 38) .
자세한 내용은 빌드 시스템 관리를 참조하세요.
빌드 결과 확장을 사용하여 열과 순서 지정
빌드 결과 섹션 확장을 통해 표시할 열과 그 순서를 지정할 수 있습니다 (그림 39) . 결과 보기에는 두 개의 열이 있으며, 기본적으로 모든 확장이 첫 번째 열에 있습니다. 참고: 모든 타사 확장은 포함하는 빌드 결과 섹션 다음에 표시됩니다.
빌드에서 줄 번호로 이동
이제 빌드 오류에서 그 오류를 야기한 코드 줄로 바로 이동할 수 있습니다. 내부에서 끌어오기 요청 정책으로 사용하는 기본 빌드에서 최근에 다음과 같은 오류가 발생했습니다 (그림 40) .
빌드 로그 뷰에서 크기가 더 큰 로그 지원
이전 로그 뷰에서는 최대 10,000개 줄의 로그만 지원했습니다. 새 뷰는 VS Code에 사용되는 모나코(Monaco) 편집기를 기반으로 하며 최대 150,000개 줄의 로그를 지원합니다.
Java 빌드 템플릿
Java 개발자가 훨씬 쉽게 빌드를 시작할 수 있도록 Ant, Maven 및 Gradle에 대한 빌드 템플릿이 추가되었습니다 (그림 41) .
템플릿에 대한 자세한 내용은 빌드 단계를 참조하세요.
Xamarin 빌드 작업
Xamarin 지원 사항이 다음과 같이 몇 가지 크게 개선되었습니다.
- Xamarin.Android 단계에서 Mac과 Linux를 지원합니다.
- Xamarin.iOS 단계에서 서명과 패키징을 지원합니다.
- Xamarin Test Cloud 결과를 빌드 요약 페이지에 표시할 수 있습니다.
- Xamarin 구성 요소 복원 단계가 새로 추가되었습니다.
- NuGet 설치 관리자 단계에서 Mac OS를 지원합니다.
Xamarin 라이선스 단계가 더 이상 필요하지 않으며 빌드 템플릿에서 제거되었습니다. 이러한 노력의 일환으로 해당 작업이 사용 중단됩니다. 이 작업을 최종적으로 제거될 때 중단이 발생하지 않도록 이 작업을 사용하는 모든 빌드 정의를 업데이트하여 해당 작업을 제거해야 합니다.
마지막으로, 이러한 새 작업을 사용할 수 있도록 Xamarin 빌드 정의 템플릿이 향상되었습니다. Xamarin 앱을 빌드하세요.
Docker를 빌드와 릴리스 관리에 통합
빌드 기능을 활용하여 Docker 이미지를 빌드한 후 연속 통합 흐름의 일환으로 Docker 허브에 업로드할 수 있습니다 (그림 42) . 그런 다음 릴리스 관리의 일환으로 이미지를 몇몇 Docker 호스트에 배포할 수 있습니다. 마켓플레이스 확장을 사용하여 Docker로 작업하는 데 필요한 서비스 엔드포인트 유형과 작업을 추가할 수 있습니다.
끌어오기 요청 뷰에 SonarQube 결과 표시
끌어오기 요청을 병합하기 위해 실행하는 빌드에 SonarQube MSBuild 작업이 들어 있으면 새 코드 분석 문제가 끌어오기 요청에서 토론식 설명으로 나타납니다 (그림 43) . 이 환경은 SonarQube 서버에 설치된 플러그 인의 언어 종류에 상관없습니다. 자세한 내용은 SonarQube Code Analysis issues integration into Pull Requests(SonarQube 코드 분석 문제를 끌어오기 요청에 통합) 블로그 게시물을 참조하세요.
빌드 정의에 대한 상태 API 보고 구성
Git 상태 API에 빌드 정의 상태를 보고할 빌드 정의를 선택할 수 있습니다. 이 기능은 해당 리포지토리 또는 분기를 빌드하는 정의는 많지만 실제 상태를 나타내는 정의는 한 개밖에 없는 경우에 특히 유용합니다.
자세한 내용은 REST API 구축 참조를 참조하세요.
단체방에서 vNext 빌드 지원
언제든지 단체방에서 XAML 빌드 알림을 추가할 수 있었습니다. 또한 사용자는 이 스프린트를 사용하여 빌드 vNext 완료에서 알림을 받을 수도 있습니다.
Git CI 트리거에 대한 경로 필터 사용
호스트되는 Git 리포지토리에 대한 CI 트리거에서 특정 경로를 포함하거나 제외할 수 있습니다. 이를 통해 특정 경로의 파일이 변경된 경우에만 실행되도록 빌드 정의를 구성할 수 있습니다 (그림 44) .
Release Management 기능 향상
Team Foundation Server 2015에 통합 웹 기반 Release Management가 도입된 이후에 이 버전에서 여러 기능을 개선했습니다.
릴리스 정의 복제, 내보내기 및 가져오기
확장 프로그램을 설치할 필요 없이 릴리스 허브 내에서 릴리스 정의를 복제하고 내보내고 가져올 수 있는 기능이 통합되었습니다 (그림 45) .
자세한 내용은 Clone, export, and import a release definition(릴리스 정의 복제, 내보내기 및 가져오기) 설명서를 참조하세요.
릴리스 요약에 테스트 결과 표시
릴리스 요약 페이지에는 환경 정보를 나타내는 외부 서비스에 대한 기여 지점이 설정되었습니다.
Team Services에서 이 기능을 사용하면 릴리스 환경의 일부로 테스트를 실행할 때 테스트 결과 요약이 표시됩니다 (그림 46) .
자세한 내용은 Understand the summary view of a release(릴리스의 요약 뷰 이해) 설명서를 참조하세요.
스크립트에 OAuth 토큰 전달
Team Services에서 REST API를 호출하는 사용자 지정 PowerShell 스크립트를 실행하거나 작업 항목을 만들거나 정보에 대한 쿼리를 작성하려면 스크립트에서 OAuth 토큰을 전달해야 합니다.
환경을 구성할 때 새 옵션을 사용하면 스크립트가 환경에서 작업으로 실행되어 현재 OAuth 토큰에 액세스할 수 있게 됩니다 (그림 47) .
자세한 내용은 Environment general options(환경 일반 옵션) 설명서를 참조하세요.
다음은 빌드 정의를 가져오는 간단한 예제 방법입니다 (그림 48) .
부분 성공 배포에 대한 트리거
빌드 및 릴리스 작업에는 각 작업에 대한 제어 옵션 매개 변수에 오류 발생 시 계속 옵션이 있습니다.
빌드 정의에서 이는 이 옵션이 설정된 작업이 실패한 경우 빌드 부분 성공 결과가 됩니다.
이제 동일한 동작을 릴리스 정의에서 사용할 수 있습니다. 작업에 실패한 경우 전체 릴리스 결과가 “릴리스 부분 성공”으로 표시됩니다 (그림 49) .
기본적으로 부분 성공 릴리스는 환경 배포 옵션에 이 동작이 지정된 경우에도 릴리스를 후속 환경으로 트리거하지 않습니다.
그러나 이전 릴리스가 부분적으로 성공한 경우 후속 환경으로 릴리스를 트리거하도록 Release Management에 지시하는 새 옵션을 각 릴리스 환경에 설정할 수 있습니다 (그림 50) .
자세한 내용은 Environment deployment triggers(환경 배포 트리거) 설명서를 참조하세요.
GitHub에 저장된 아티팩트 직접 사용
이 항목에서 설명한 것처럼, 버전 제어 시스템에 저장된 아티팩트를 빌드 프로세스를 통해 전달하지 않고 직접 사용하려는 경우가 있을 수 있습니다.
이제 코드가 GitHub 리포지토리에 저장된 경우 이 작업을 수행할 수 있습니다 (그림 51) .
자세한 내용은 TFVC, Git, and GitHub sources(TFVC, Git 및 GitHub 소스) 설명서를 참조하세요.
ARM을 사용하여 웹앱 배포
Azure 웹앱 배포 작업의 새 버전이 AzureRM 웹앱 배포라는 이름으로 제공됩니다.
이 작업은 MSDeploy 및 Azure Resource Manager의 서비스 엔드포인트 연결을 사용합니다. ASP.NET 4, Node 및 Python 기반의 웹앱 외에도 Azure 웹 작업과 Azure API 앱도 배포할 수 있습니다.
또한 일반적인 게시 옵션을 지원하는데 앱 데이터를 유지하고 앱을 오프라인으로 전환하고 대상에서 추가 파일을 제거할 수 있습니다.
구성 변환 같은 더 다양한 기능도 향후 버전에 포함될 수 있습니다 (그림 52) .
작업 그룹
작업 그룹을 사용하면 빌드 또는 릴리스 정의에서 이미 정의된 작업 시퀀스를 재사용 가능한 단일 작업으로 캡슐화할 수 있습니다. 이 단일 작업은 다른 작업처럼 빌드나 릴리스 정의에 추가할 수 있습니다 (그림 53) .
캡슐화된 작업에서 매개 변수를 구성 변수로 추출하고 나머지 작업 정보를 추상화할 수도 있습니다.
새 작업 그룹은 다른 릴리스와 빌드 정의에 추가할 수 있도록 작업 카탈로그에 자동으로 추가됩니다.
자세한 내용은 Task Groups(작업 그룹) 설명서를 참조하세요.
릴리스 일시 삭제
릴리스는 사용자가 직접 삭제하거나 보존 정책에 의해 자동으로 삭제되는 경우 개요 및 세부 정보 목록에서 제거됩니다.
하지만 영구 삭제되기 전 일정 기간(일반적으로 14일) 동안 릴리스 정의와 함께 보관됩니다.
이 기간에 릴리스는 개요 및 세부 정보 목록의 삭제됨 탭에 표시됩니다.
이러한 릴리스를 복원하려면 바로 가기 메뉴를 열어 삭제 취소를 선택하면 됩니다(그림 54).
자세한 내용은 Restore deleted releases(삭제된 릴리스 복원) 설명서를 참조하세요.
각 환경의 릴리스 및 빌드 보존
릴리스 정의에 대한 릴리스 보존 정책은 릴리스 및 연결된 빌드의 보존 기간을 결정합니다.
기본적으로 릴리스는 60일 동안 보존됩니다. 이 기간 동안 배포되거나 수정되지 않은 릴리스는 자동으로 삭제됩니다.
그러나 특정 환경(예: 프로덕션 환경)에 배포된 릴리스를 더 많이 보존하거나 다른 환경(예: 테스트, 스테이징, QA)에 배포된 릴리스보다 더 오래 보존할 수 있습니다.
또한 릴리스에 연결된 빌드를 해당 릴리스와 동일한 기간 동안 보존할 수 있기 때문에 릴리스를 다시 배포해야 할 때 아티팩트를 사용할 수 있습니다 (그림 55) .
자세한 내용은 Release and build retention(릴리스 및 빌드 보존) 설명서를 참조하세요.
연결된 아티팩트의 향상된 기능
두 가지 새로운 기능으로 아티팩트와 아티팩트 소스 사용이 더 쉬워졌습니다.
- 아티팩트 소스를 릴리스 정의에 여러 개 연결할 수 있습니다 (그림 56) . 각 아티팩트는 소스 별칭이라는 에이전트의 폴더에 다운로드됩니다. 이제 연결된 아티팩트의 소스 별칭을 편집할 수 있습니다. 예를 들어, 빌드 정의의 이름을 변경할 때 빌드 정의의 이름을 반영하도록 소스 별칭을 편집할 수 있습니다.
- Build.* 형식의 여러 변수(예: Build.BuildId, Build.BuildNumber)가 작업 매개 변수에서 사용할 수 있도록 노출됩니다. 여러 소스가 릴리스에 연결되어 있으면 이러한 변수는 기본 소스로 지정한 아티팩트 소스의 값으로 채워집니다. 자세한 내용은 Artifact variables(아티팩트 변수) 설명서를 참조하세요.
배포 - 수동 작업
환경에 배포하는 동안 실행을 일시 중지할 수 있습니다.
환경에 수동 작업을 포함하면 배포를 일시적으로 중단한 후 수동 단계를 수행한 다음 자동화된 단계를 다시 추가로 시작할 수 있습니다.
또한 수동 작업 후 배포를 취소하고 추가 단계를 실행하지 못하도록 방지할 수도 있습니다 (그림 57) .
자세한 내용은 Manual intervention(수동 작업) 설명서를 참조하세요.
SQL Database 배포 작업 스크립트
Azure SQL Database에 대해 SQL 스크립트를 실행할 수 있도록 Azure SQL Database 배포(그림 58) 작업을 강화했습니다. 스크립트는 파일 형태로 제공하거나 작업 내에서 인라인 형태로 제공할 수 있습니다.
릴리스 정의 요약 - 대시보드 위젯
대시보드에 릴리스 정의를 고정하면 모든 팀이 해당 정의에 대한 릴리스 요약을 손쉽게 볼 수 있도록 할 수 있습니다.
자세한 내용은 Add release information to the dashboard(대시보드에 릴리스 정보 추가) 설명서를 참조하세요.
특정 시간에 환경으로 릴리스 승격
모든 프로덕션 배포를 자정에 실행하고 싶으신가요? 다른 환경에서의 성공적인 배포(또는 최신 배포만)를 선택하여 지정된 시간에 배포하는 조건을 환경에 구성할 수 있습니다 (그림 59) .
여러 환경에서 조건에 따라 배포
이전 버전까지는 병렬 배포(분기 배포)를 수행할 수 있었지만 여러 환경의 상태를 기반으로 환경으로의 배포(조인 배포)를 시작하지 못했습니다. 이제 다음과 같은 작업을 수행할 수 있습니다.
자세한 내용은 Parallel forked and joined deployments(병렬 분기 및 조인 배포) 설명서를 참조하세요.
Release Management용 REST API
Release Management 서비스용 REST API를 사용하여 릴리스 정의 및 릴리스를 만들고 릴리스 배포의 다양한 측면을 관리할 수 있습니다.
자세한 내용은 API 참조 설명서를 참조하세요.
서비스 후크 통합
새 릴리스가 만들어지거나, 배포가 시작 또는 완료되거나, 승인이 보류 중 또는 완료된 경우 릴리스 알림을 보냅니다. 이러한 알림을 받으려면 Slack과 같은 타사 도구와 통합하세요.
국가별 Azure 클라우드에 배포
Azure 클래식 서비스 엔드포인트에서 새 환경 설정을 사용하여 특정 Azure 클라우드(Azure 중국 클라우드, Azure 미국 정부 클라우드, Azure 독일 클라우드 등 미리 정의된 국가별 클라우드 포함)를 대상으로 지정할 수 있습니다 (그림 60) .
자세한 내용은 Azure Classic service endpoint(Azure 클래식 서비스 엔드포인트) 설명서를 참조하세요.
테스트 기능 향상
주요 테스트 기능 향상이 Team Foundation Server 2017에 추가되었습니다.
업데이트된 테스트 결과 스토리지 스키마
현재 Microsoft는 이 릴리스에서 테스트 결과 아티팩트를 효율적인 새 소형 스토리지 스키마에 마이그레이션하는 중입니다. 테스트 결과가 TFS 데이터베이스의 스토리지 공간을 차지하는 상위 항목이므로 이 기능을 통해 TFS 데이터베이스의 스토리지 사용 공간이 줄어들 것으로 기대됩니다. 이전 TFS 버전에서 업그레이드하는 고객은 TFS를 업그레이드하는 동안 테스트 결과가 새 스키마로 마이그레이션됩니다. 이 같은 업그레이드 때문에 데이터베이스에 있는 테스트 결과 데이터의 크기에 따라 업그레이드 시간이 오래 걸릴 수 있습니다. TFS 업그레이드가 더 빨라지도록 테스트 보존 정책을 구성하고 정책이 시작되고 테스트 결과에서 사용되는 스토리지를 줄일 때까지 기다리는 것이 좋습니다. TFS를 설치한 후 TFS instance 업그레이드하기 전에 TFSConfig.exe 도구를 사용하여 테스트 결과를 클린 수 있습니다. 자세한 내용은 TFSConfig.exe 도움말을 참조하세요. 업그레이드하기 전에 테스트 보존을 구성하거나 테스트 결과를 정리할 수 있는 유연성이 없는 경우 업그레이드 기간을 적절하게 계획해야 합니다. 테스트 보존 정책 구성에 대한 자세한 예제 에서 Team Foundation Server 2015 테스트 결과 데이터 보존 을 사용하여 결과 데이터 보존 테스트를 참조하세요.
테스트 허브 기능 향상
테스트 허브에 위치하는 테스트 구성 관리
테스트 구성 관리를 웹 UI로 이동하기 위해 [테스트 허브] 내에 새 [구성] 탭이 추가되었습니다 (그림 61) . 따라서 이제 테스트 허브에서 테스트 구성과 테스트 구성 변수를 만들고 관리할 수 있습니다.
자세한 내용은 Create configurations and configuration variables(구성 및 구성 변수 만들기)를 참조하세요.
테스트 계획, 테스트 도구 모음 및 테스트 사례에 구성 할당
구성 할당이 더 쉬워졌습니다. 테스트 구성은 [테스트 허브] 내에서 직접 테스트 계획, 테스트 도구 모음 또는 테스트 사례에 할당할 수 있습니다 (그림 62) . 항목을 마우스 오른쪽 단추로 클릭하고 ...에 구성 할당을 선택하면 해당 항목이 해제되어 실행됩니다. 또한 테스트 허브에서 구성을 기준으로 필터링할 수 있습니다 (그림 63) .
자세한 내용은 Assign configurations to Test plans and Test suites(테스트 계획과 테스트 도구 모음에 구성 할당)를 참조하세요.
[테스트 결과] 창에서 테스트 계획/테스트 도구 모음 열 보기
테스트 결과 창에 테스트 결과가 실행된 테스트 계획과 테스트 도구 모음을 보여 주는 새로운 열이 추가되었습니다. 이러한 열을 통해, 테스트 결과를 드릴할 때 꼭 필요한 컨텍스트를 알 수 있습니다 (그림 64) .
테스트 허브와 카드에서 테스트 순서 지정
이제 수동 테스트가 포함된 도구 모음 유형, 즉, 정적, 요구 사항 기반 또는 쿼리 기반 도구 모음에 관계없이 [테스트 허브] 내에서 수동 테스트를 정렬할 수 있습니다 (그림 65) . 그리고 하나 이상의 테스트를 끌어서 놓거나 상황에 맞는 메뉴를 사용하여 테스트 순서를 간단히 변경할 수 있습니다. 순서를 모두 지정하면 순서 필드에 따라 테스트를 정렬한 후 웹 러너에서 그 순서대로 실행할 수 있습니다. Kanban 보드의 사용자 스토리 카드에서 직접 테스트 순서를 지정할 수도 있습니다 (그림 66) .
테스트 허브에서 테스트 도구 모음 순서 지정
테스트 팀은 이제 자체의 요구 사항에 따라 테스트 도구 모음을 정렬할 수 있습니다. 이 기능을 사용하기 전에는 도구 모음이 사전순으로만 정렬되었습니다. 이제 테스트 허브에서 끌어서 놓기 기능을 사용하여 피어 도구 모음 간에 도구 모음 순서를 변경하거나 계층의 다른 도구 모음으로 도구 모음을 이동할 수 있습니다 (그림 67) .
테스터 할당의 일부로 사용자 검색
여러 허브에 걸친 새 ID 선택기 컨트롤 출시의 일부로 테스트 허브에서 하나 이상의 테스트에 테스터를 할당할 때 사용자를 검색할 수 있는 옵션을 설정했습니다 (그림 68) . 이는 팀 멤버가 많지만 상황에 맞는 메뉴에는 제한된 항목 집합만 표시되는 시나리오에서 매우 유용합니다*(그림 69).
테스트할 빌드 선택
이제 [테스트 허브]에서 '옵션과 함께 실행'을 사용하여 테스트할 "빌드"를 선택한 다음, 웹 실행기를 시작할 수 있습니다 (그림 70) . 실행 중에 제출된 모든 버그는 선택한 빌드에 자동으로 연결됩니다. 또한 테스트 결과가 해당 특정 빌드에 대해 게시됩니다.
데이터 수집기와 함께 테스트 허브에서 Microsoft Test Runner 클라이언트 시작
이제 Microsoft Test Manager 클라이언트에서 구성하지 않고도 테스트 실행에 연결할 데이터 수집기 및 빌드를 선택 (그림 71) 한 후 테스트 허브에서 효율적으로 Microsoft Test Runner 2017(클라이언트)을 시작할 수 있습니다. Microsoft Test Runner는 전체 Microsoft Test Manager 셸을 열지 않고 시작되며, 테스트 실행이 완료되면 종료됩니다.
자세한 내용은 Run tests for desktop apps(데스크톱 앱에 대한 테스트 실행)를 참조하세요.
데이터 수집기 선택 및 테스트 허브에서 Exploratory Runner 클라이언트 시작
이제 Microsoft Test Manager 클라이언트에서 구성하지 않고도 데이터 수집기를 선택한 후 테스트 허브에서 효율적으로 Exploratory Runner 2017(클라이언트)을 시작할 수 있습니다. 요구 사항 기반 도구 모음의 상황에 맞는 메뉴에서 ‘옵션과 함께 실행’을 호출 (그림 72) 하고 Exploratory Runner와 필요한 데이터 수집기를 선택합니다. 위에서 설명한 대로 Exploratory Runner는 Microsoft Test Runner와 비슷한 방식으로 시작됩니다.
여러 테스트 도구 모음의 테스트에 대한 테스트 결과 구성
이제 동일한 테스트 계획의 여러 테스트 도구 모음에서 공유되는 테스트에 대한 테스트 결과의 동작을 구성할 수 있는 기능을 추가했습니다 (그림 73) . 이 옵션을 선택하고 테스트 결과를 설정하면(테스트 허브, 웹 실행기, Microsoft Test Runner 또는 Kanban 보드의 카드에서 통과/실패/차단됨으로 표시) 해당 결과가 동일한 테스트 계획에서 동일한 구성을 사용하는 여러 테스트 도구 모음에 있는 다른 모든 테스트에 전파됩니다. 사용자는 테스트 허브 테스트 계획 바로 가기 메뉴 또는 Kanban 보드 테스트 페이지의 일반 설정 구성 대화 상자에서 특정 테스트 계획에 대한 "테스트 결과 구성" 옵션을 설정할 수 있습니다. 이 옵션은 기본적으로 해제되어 있으며 명시적으로 사용하도록 설정해야만 적용됩니다.
작업 항목에서 버그 확인
버그를 찾은 테스트를 다시 실행하여 버그를 확인할 수 있습니다 (그림 74) . 버그 작업 항목 양식의 상황에 맞는 메뉴에서 확인 옵션을 호출하여 웹 실행기에서 관련 테스트 사례를 실행할 수 있습니다. 또한 웹 실행기에서 유효성 검사를 수행하고 바로 버그 작업 항목을 업데이트할 수 있습니다.
테스트 계획과 테스트 도구 모음의 복제를 위한 REST API
테스트 계획 및 테스트 도구 모음을 복제하기 위한 REST API가 추가되었습니다. 이 REST API는 Team Services Integrate 사이트의 Test Management(테스트 관리) 섹션에서 확인할 수 있습니다.
Kanban 카드에서 테스트 진행률 확인
테스트 사례를 추가하고 확인할 수 있으며 Kanban 보드의 스토리에서 바로 조작할 수도 있습니다. 새로운 테스트 추가 메뉴 옵션을 사용하여 연결된 테스트 사례를 만든 후 진행 상태를 카드에서 바로 모니터링할 수 있습니다 (그림 75) .
이 새 기능으로 이제 보드의 카드에서 다음 작업을 바로 수행할 수 있습니다.
- 테스트를 추가할 수 있습니다.
- 테스트를 열 수 있습니다.
- 테스트를 한 사용자 스토리에서 다른 사용자 스토리로 끌어서 놓아 테스트의 부모를 재지정할 수 있습니다.
- Ctrl+끌어서 놓기를 사용하여 같은 테스트를 다른 사용자 스토리에 복사할 수 있습니다(같은 테스트 사례에서 두 개 이상의 사용자 스토리를 테스트하는 시나리오인 경우).
- 테스트 상태를 신속하게 통과/실패 등으로 표시하여 테스트 상태를 업데이트할 수 있습니다.
- 웹 테스트 러너에서 테스트를 시작하여 실행할 수 있습니다. 사용자는 웹 테스트 러너에서 개별 단계를 통과 또는 실패로 평가하거나 버그를 제출하는 등의 작업을 할 수 있습니다.
- 통과한 테스트 수와 해당 스토리에 남은 테스트 수를 알려주는 롤업 상태 요약을 볼 수 있습니다.
고급 테스트 관리 기능(예: 테스터 할당, 구성 할당, 중앙 매개 변수, 테스트 결과 내보내기)이 필요하면 테스트 허브로 전환하여 자동 생성되는 기본 테스트 계획/요구 사항 기반의 도구 모음을 사용할 수 있습니다. 자세한 내용은 인라인 테스트 추가, 실행 및 업데이트를 참조하세요.
카드에서 테스트 계획/테스트 도구 모음으로 트래버스
이제 Kanban 보드의 카드에서 직접 테스트가 만들어진 기본 테스트 계획/테스트 도구 모음으로 손쉽게 트래버스할 수 있습니다. 이 링크를 클릭하면 (그림 76) 테스트 허브로 이동하여 올바른 테스트 계획을 열고 해당 인라인 테스트를 제어하는 특정 도구 모음을 선택할 수 있습니다.
Kanban 보드 일반 설정 구성의 테스트 페이지
Kanban 보드의 [일반 설정 구성] 대화 상자에 있는 새 테스트 페이지를 사용하여 인라인 테스트가 만들어지는 테스트 계획을 제어합니다 (그림 77) . 이전에는 카드의 영역 및 반복 경로와 일치하는 테스트 계획이 없는 경우 카드에 만들어진 모든 테스트가 새로 만들어진 테스트 계획에 자동으로 추가되었습니다. 이제 선택한 기존 테스트 계획을 구성하여 이 동작을 재정의할 수 있습니다. 그러면 모든 테스트가 선택한 테스트 계획에 추가됩니다. 이 기능은 테스트 주석이 켜진 경우에만 사용하도록 설정됩니다.
웹 Runner 기능 향상
수동 테스트 중 테스트 단계 첨부 파일 추가
수동 테스트 중에 테스트 단계 첨부 파일을 추가할 수 있도록 웹 테스트 실행기가 향상되었습니다 (그림 78) . 이러한 단계 결과 첨부 파일은 세션에서 제출하는 버그와 이후에 테스트 결과 창에서 자동으로 표시됩니다.
웹 실행에서 스크린샷, 화면 녹화, 이미지 작업 로그 및 시스템 정보 지원(Chrome 브라우저 사용 시)
Chrome에서 웹 실행기를 사용하는 경우 스크린샷을 찍고 인라인 주석을 달 수 있습니다 (그림 79) . 웹앱뿐만 아니라 데스크톱 앱에서 주문형 화면 녹화를 캡처할 수 있습니다. 이러한 스크린샷 및 화면 녹화는 현재 테스트 단계에 자동으로 추가됩니다. 스크린샷 및 화면 녹화 외에도 웹앱의 주문형 이미지 작업 로그를 캡처할 수 있습니다. 작업을 캡처할 브라우저 창을 지정해야 합니다. 해당 창의 모든 작업(해당 창에 열려 있는 모든 기존 또는 새 탭) 또는 사용자가 시작한 모든 새 하위 브라우저 창이 자동으로 캡처되고 웹 Runner에서 테스트 중인 테스트 단계에 대해 상관 관계가 지정됩니다. 그런 다음 이러한 스크린샷, 화면 녹화 및 이미지 작업 로그는 실행 중에 제출하는 모든 버그에 추가되며 현재 테스트 결과에 연결됩니다. 이와 마찬가지로, 시스템 정보 데이터도 자동으로 캡처되고 웹 러너에서 제출하는 버그의 일부로도 포함됩니다. 이러한 모든 작업은 크롬 기반의 테스트 및 피드백 확장 기능을 활용하는 것입니다.
For more information, see Collect diagnostic data during tests(테스트하는 동안 진단 데이터 수집)를 참조하세요.
자식 항목으로 제출되는 버그 – 웹 실행기/테스트 및 피드백 확장
웹 러너에서 테스트를 실행할 때 보드의 카드에서 시작하거나 테스트 허브의 요구 사항 기반 도구 모음에서 시작하면 제출하는 새 버그가 해당 사용자 스토리의 자식으로 자동으로 생성됩니다. 마찬가지로, 예비 테스트 확장에서 사용자 스토리를 탐색하는 경우 사용자가 제출하는 새 버그도 해당 사용자 스토리의 자식으로 만들어집니다. 이 새로운 동작 때문에 스토리와 버그를 더 간단하게 추적할 수 있습니다. [일반 설정 구성] 페이지에서 "버그 작업" 설정이 "버그가 백로그 또는 보드에 표시되지 않음" 또는 "버그가 백로그와 보드에 작업과 함께 표시됨"으로 설정된 경우에만 이 동작이 적용됩니다. "버그 작업" 옵션에 대한 다른 모든 설정과 특정 시나리오(예: 이미 정의된 부모가 있는 기존 버그에 추가)에서는 관련 링크가 대신 만들어집니다.
웹 실행기에서 기존 버그 업데이트
웹 실행기에서 새 버그를 만들 수 있을 뿐만 아니라 이제 기존 버그를 업데이트할 수도 있습니다 (그림 80) . 수집한 모든 진단 데이터, 버그가 발견된 경위, 현재 세션의 추적 가능성 링크가 기존 버그에 자동으로 추가됩니다.
테스트 및 피드백 확장 - 향상된 기능
브라우저 기반의 테스트 및 피드백 확장을 Visual Studio 마켓플레이스에서 설치할 수 있습니다. 이 테스트 및 피드백 확장은 Visual Studio Team Services와 Team Foundation Server(2015 이상)를 모두 지원합니다.
작업 항목 탐색
특정 작업 항목에 대해 예비 테스트를 수행할 수 있습니다 (그림 81) . 그러면 선택한 작업 항목을 진행 중인 테스트 세션과 연결하고 확장 내에서 수용 기준 및 설명을 볼 수 있습니다. 또한, 작성하는 버그 또는 작업과 선택한 작업 항목 사이에 엔드투엔드 추적 가능성을 만듭니다. 작업 항목 또는 확장 내에서 바로 작업 항목을 탐색할 수 있습니다.
• 작업 항목에서 직접 수행(그림 81): 바로 가기 메뉴의 “예비 테스트 수행” 옵션을 사용하여 제품 내에서 직접 특정 작업 항목에 대한 예비 테스트 세션을 시작합니다. 모든 카드, 그리드 및 [테스트] 허브에 진입점이 추가되었습니다.
• 확장 내에서 수행(그림 82): XT 세션 내에서 작업 항목을 검색한 다음, 진행 중인 세션과 연결합니다.
자세한 내용은 Explore work items with the Test & Feedback extension(테스트 및 피드백 확장으로 작업 항목 탐색)을 참조하세요.
테스트 및 피드백을 사용하여 이미지 작업 로그, 화면 녹화 및 웹 페이지 데이터 로드 캡처
이미지 작업 로그: 확장은 클릭 한 번으로 자동으로 버그로 연결하는 단계를 추가할 수 있는 새 옵션을 제공합니다. "이미지 작업 로그 포함" 옵션 (그림 83) 을 선택하여 마우스, 키보드 및 터치 작업을 캡처하고 해당 텍스트 및 이미지를 버그 또는 작업에 직접 추가할 수 있습니다.
비디오로 화면 녹화: 확장을 사용하여 주문형 화면 녹화를 캡처할 수도 있습니다. 이러한 화면 녹화는 웹앱뿐만 아니라 데스크톱 앱에서도 캡처할 수 있습니다. 확장의 "옵션" 페이지를 사용하여 자동으로 화면 녹화를 중지하고 제출 중인 버그에 해당 화면 녹화를 첨부하도록 확장을 구성할 수 있습니다.
페이지 로드 데이터: 확장에 "웹 페이지 로드" 데이터를 캡처하는 확장 기능에 새 백그라운드 캡처 기능을 추가했습니다. 탐색 중인 웹앱에서 수행된 작업을 백그라운드에서 이미지 형식으로 캡처한 "이미지 작업 로그"와 마찬가지로, "페이지 로드" 기능은 웹 페이지에 대한 세부 정보를 자동으로 캡처하여 로드 작업을 완료합니다. 주관적이거나 인지된 웹 페이지 로드 속도 저하에 의존하는 대신 이제 버그에서 속도 저하를 객관적으로 정량화할 수 있습니다. 버그가 제출되면 Tile 보기 외에 상세 보고서도 버그에 연결됩니다. 이는 초기 조사 집합과 함께 개발자에게 유용한 정보를 제공할 수 있습니다.
이미지 작업 로그 데이터를 기반으로 테스트 사례 만들기
이제 예비 세션 중에 테스트 사례를 만들 경우 이미지와 함께 테스트 단계가 자동으로 채워집니다 (그림 84) . 동시 테스트 디자인 및 테스트 실행은 진정한 예비 테스트의 기본 항목이며 이 새 기능 때문에 동시 테스트 디자인과 테스트 실행이 가능해졌습니다. 캡처한 텍스트를 편집하고 예상 결과를 추가하며 관련 없는 행을 배제하고 향후 테스트 통과 및 실행을 위해 텍스트를 저장할 수 있습니다.
자세한 내용은 Create test cases based in image action log data(이미지 작업 로그 데이터를 기반으로 테스트 사례 만들기)를 참조하세요.
예비 테스트 세션 정보
이제 테스트 및 피드백 확장을 사용하여 만든 지정된 기간에 팀이나 개인 수준으로 완료한 예비 테스트 세션을 볼 수 있습니다. 웹 액세스에서 [테스트 허브] 그룹 내의 [실행] 허브에서 "최근 예비 세션" 링크를 클릭하여 이 인사이트 페이지로 이동할 수 있습니다. 이 새 뷰에서는 다음과 같이 의미 있는 정보를 얻을 수 있습니다.
- 요약 뷰에서는 총 세션 시간과 함께 탐색한 작업 항목, 생성한 작업 항목, 세션 소유자를 분석하여 보여 줍니다 (그림 85) .
- 그룹별 뷰는 탐색한 작업 항목, 세션 또는 세션 소유자를 기준으로 피벗하거나 아무런 기준 없이 피벗할 수 있습니다. 피벗의 경우 생성된 전체 작업 항목(예: 버그, 작업, 테스트 사례) 목록을 보거나 목록 범위를 특정 작업 항목 형식으로 좁힐 수 있습니다.
- 세부 정보 창 뷰에는 그룹별 뷰에서 선택한 항목을 기준으로 정보가 표시됩니다. 선택한 피벗 행(예: 탐색한 작업 항목)의 경우 세부 정보 창에서 해당 요약 정보를 볼 수 있으며 예를 들어 세션 상태와 우선 순위, 총 세션 수, 총 세션 시간, 세션에서 만든 버그/작업/테스트 사례를 볼 수 있습니다. 선택한 작업 항목 행의 인라인 작업 항목 폼을 볼 수 있으며 적절하게 변경할 수 있습니다.
자세한 내용은 Get insights across your exploratory testing sessions(예비 테스트 세션에서 통찰력 얻기)를 참조하세요.
예비 테스트 세션: 탐색하지 않은 작업 항목 보기
"최근 예비 세션" 뷰에서 탐색된 모든 작업 항목의 세부 정보를 지정된 날짜 범위의 모든 세션 또는 내 세션별로 필터링하여 표시하는 것 외에도, 이제 동일한 뷰에서 탐색되지 않은 모든 작업 항목의 목록을 표시하는 기능이 추가되었습니다 (그림 86) . 먼저 관심 있는 작업 항목에 대한 공유 쿼리를 지정하면 해당 쿼리의 모든 작업 항목 목록이 세션 페이지에 표시되며 탐색된 항목과 탐색되지 않은 항목의 분석 결과가 요약 섹션에 함께 표시됩니다. 또한 피벗별로 "탐색하지 않은 작업 항목" 그룹을 사용하면 아직 탐색되지 않은 항목 목록도 확인할 수 있습니다. 이는 아직 탐색되지 않았거나 버그 수정 과정을 거치지 않은 스토리 수를 추적하는 데 매우 유용합니다.
종단 간의 관련자 피드백 흐름
피드백 요청
기본 액세스 수준의 사용자는 작업 항목 메뉴에서 피드백 요청 옵션을 사용하여 진행 중이거나 완료된 기능/스토리에 대한 피드백을 관련자에게 직접 요청할 수 있습니다 (그림 87) . 이렇게 하면 피드백 요청 양식이 열립니다. 여기서는 피드백을 원하는 관련자를 선택할 수 있고, 필요에 따라 입력하려는 제품 영역에 대해 묻는 간단한 일단의 지침이 제공될 수 있습니다. 양식을 모두 작성하면 개별 메일이 제공된 지침(있는 경우)과 함께 해당 관련자에게 전송됩니다.
자세한 내용은 Request stakeholder feedback using the Test & Feedback extension(테스트 및 피드백 확장을 사용하여 관련자 피드백 요청)을 참조하세요.
피드백 제공
관련자는 받은 메일에서 피드백 제공 링크를 클릭하여 피드백 요청에 응할 수 있습니다. 이 링크를 클릭하면 해당 피드백 요청과 함께 테스트 및 피드백 확장(이전의 예비 테스트 확장)이 자동으로 구성됩니다(확장을 아직 설치하지 않은 경우에만 확장 설치 메시지가 나타남). 그런 다음 관련자는 발견한 정보를 확장의 전체 캡처 기능으로 캡처한 후 피드백 응답/버그/작업 항목의 형태로 피드백을 제출할 수 있습니다. 또한 관련자가 "피드백 요청" 페이지로 이동하여 받은 피드백 요청을 모두 한 곳에서 볼 수 있습니다. 목록에서 피드백을 제공하려는 피드백 요청을 선택할 수 있고, 피드백 요청을 완료로 표시하거나 거부하여 "보류 중인 피드백 요청"을 관리할 수 있으며 (그림 88) , 원하는 라디오 단추를 클릭하여 다양한 형식의 피드백 요청 간에 전환할 수 있습니다 (그림 89) .
자세한 내용은 Provide feedback using the Test & Feedback extension(테스트 및 피드백 확장을 사용하여 피드백 제공)을 참조하세요.
자발적 피드백
위에서 언급한 요청된 흐름 외에 관련자는 확장을 사용하여 자발적으로도 피드백을 제공할 수 있습니다 (그림 90) . 확장을 열고, [연결 설정] 페이지에서 "연결됨" 모드를 선택하고, 피드백을 제공하려는 계정과 프로젝트/팀에 연결하면 됩니다. 그런 다음 발견한 정보를 확장을 사용하여 캡처한 후 피드백 응답/버그/작업 항목의 형태로 피드백을 제출하면 됩니다.
자세한 내용은 Provide voluntary feedback using the Test & Feedback extension(테스트 및 피드백 확장을 사용하여 자발적으로 피드백 제공)을 참조하세요.
자동화된 테스트 기능 향상
빌드/릴리스 요약의 [테스트] 탭에 콘솔 로그 및 테스트 기간 표시
.trx 파일에서 캡처한 테스트 결과 콘솔 로그가 추출되어 테스트 결과 첨부 파일로 게시됩니다 (그림 91) . [테스트] 탭에는 첨부 파일을 미리 볼 수 있는 옵션이 있으므로 로그를 보기 위해 trx 파일을 더 이상 다운로드할 필요가 없습니다.
빌드에 대한 테스트 추세 위젯
위젯 갤러리에 새로운 ‘Test result trend’(테스트 결과 추세) 위젯을 추가했습니다 (그림 92) . 이 위젯을 사용하면 빌드 정의와 관련한 최대 30개의 최신 빌드의 테스트 결과 추세 차트를 대시보드에 추가할 수 있습니다. 위젯 구성 옵션은 통과한 테스트 수, 실패한 테스트 수, 총 테스트 수, 통과율, 테스트 지속 시간 같은 피벗을 포함하도록 차트를 사용자 지정하는 데 유용합니다.
릴리스 환경 요약이 포함된 테스트 상태
[릴리스 환경]을 사용하여 애플리케이션을 배포하고 이에 대한 테스트를 실행하는 것이 좋습니다. 이 릴리스에서는 릴리스 요약 페이지의 환경 섹션에 릴리스 환경의 테스트 통과 비율을 통합했습니다 (그림 93) . 스크린샷에 표시된 것처럼 환경이 실패한 경우 테스트 열을 보고 테스트 실패로 인해 실패한 것인지 신속하게 추론할 수 있습니다. 통과 비율을 클릭하여 테스트 탭으로 이동한 후 해당 환경에 대해 실패한 테스트를 조사할 수 있습니다.
분기 및 릴리스 환경에 대한 자동화된 테스트 기록
개별 테스트가 여러 분기, 환경 및 구성에서 실행되는 것이 일반적인 시나리오입니다. 이러한 테스트가 실패하면 기본 분기와 같은 개발 분기에 해당 오류가 포함되어 있는지 또는 프로덕션 환경에 배포되는 릴리스 분기에도 영향을 미치는지 확인해야 합니다. 이제 결과 요약 페이지의 [기록] 탭을 보면 테스트 중인 여러 분기에서 테스트 기록을 시각화할 수 있습니다 (그림 94) . 마찬가지로 환경 피벗별로 그룹화하여 테스트가 실행되는 여러 릴리스 환경에서 테스트 기록을 시각화할 수 있습니다.
연속 테스트를 통한 추적 가능성
이제 사용자는 자신의 대시보드에서 요구 사항의 품질을 바로 추적할 수 있습니다 (그림 95) . 계획된 테스트 사용자의 요구 사항 품질에 대한 솔루션은 이미 있으며, 현재 연속 테스트를 따르는 사용자에게 이를 제공하고 있습니다. 사용자는 자동화된 테스트를 요구 사항에 직접 연결한 다음, 대시보드 위젯을 사용하여 추적에 관심 있는 요구 사항의 품질을 추적하고 빌드 또는 릴리스에서 품질 데이터를 가져올 수 있습니다.
원격 테스트 - 컴퓨터 수에 따라 테스트 배포
기능 테스트 실행 작업을 사용하여 어셈블리 내의 테스트를 원격 컴퓨터에 배포할 수 있습니다 (그림 96) . TFS 2015에서는 어셈블리 수준에서만 테스트를 배포할 수 있었습니다. 아래와 같이 작업에 있는 확인란을 사용하여 이러한 배포를 사용하도록 설정합니다.
SCVMM 및 VMWare에 대한 자동화된 테스트
사용자는 Azure를 통해 클라우드에서 또는 SCVMM이나 VMWare를 사용하여 온-프레미스에서 테스트 컴퓨터를 동적으로 설정하고 이러한 컴퓨터를 사용하여 분산 방식으로 테스트를 실행할 수 있습니다. 사용자는 컴퓨터 프로비전 작업(Azure, SCVMM 또는 VMWare) 중 하나를 사용한 다음 기능 테스트 실행 작업을 통해 테스트를 실행할 수 있습니다.
Maven 및 Gradle 작업에서 SonarQube 분석
이제 ‘SonarQube 분석 실행’을 선택하고 엔드포인트, SonarQube 프로젝트 이름, 프로젝트 키 및 버전을 제공하여 Maven 및 Gradle 빌드 작업에서 SonarQube 분석을 트리거할 수 있습니다 (그림 97) .
실행이제 SonarQube 프로젝트에 대한 링크도 얻을 수 있습니다 (그림 98) . 전체 분석을 요청하여 품질 게이트 정보를 확인하고 충족되지 않는 빌드는 중단할 수 있습니다.
자세한 내용은 The Gradle build task now supports SonarQube analysis(이제 Gradle 빌드 작업에서 SonarQube 분석 지원)를 참조하세요.
Marketplace 기능 향상
이제 프로젝트 컬렉션 관리자가 Team Foundation Server에서 Visual Studio Marketplace로 이동하여 팀 프로젝트 컬렉션에 무료 확장을 설치할 수 있습니다. 확장은 자동으로 Visual Studio Marketplace에서 다운로드되고 Team Foundation Server에 업로드되며 선택한 팀 프로젝트 컬렉션에 설치됩니다 (그림 99) .
유료 확장 구입 및 설치
이제 프로젝트 컬렉션 관리자가 Team Foundation Server에서 Visual Studio Marketplace로 이동하여 유료 확장을 구입하고 선택한 팀 프로젝트 컬렉션에 설치할 수 있습니다 (그림 100) . 관리자는Azure 구독으로 확장에 비용을 지불하고 이러한 확장을 할당할 사용자의 수를 선택할 수 있습니다. 이러한 확장은 자동으로 Visual Studio 마켓플레이스에서 다운로드되고 Team Foundation Server에 업로드되며 선택한 팀 프로젝트 컬렉션에 설치됩니다.
자세한 내용은 Get extensions for Team Foundation Server(Team Foundation Server용 확장 얻기) 설명서를 참조하세요.
관리 기능 향상
Windows 인증
이전 릴리스에서는 도메인에 가입된 TFS 배포를 구성할 때 Windows 인증에 NTLM과 Negotiate 보안 지원 공급자 중 무엇을 사용할지 결정해야 했습니다. 2017에서는 이 설정이 구성 환경에서 제거되었습니다. 2017에서 NTLM 인증을 계속 사용하려는 경우 어떤 조치도 취할 필요가 없습니다. Kerberos 인증을 사용했으며 2017에서도 계속 사용하려는 경우 어떤 조치도 취할 필요가 없습니다. 이제 TFS 2017에서 항상 Negotiate 및 NTLM 보안 지원 공급자를 이 순서대로 둘 다 구성합니다. 이 구성을 사용하면 가능한 경우 Kerberos 인증이 사용되므로 향상된 보안을 제공합니다. Kerberos를 사용할 수 없는 경우 NTLM 인증이 사용됩니다. 이 변경으로 인해 NTLM 인증을 사용하는 기존 TFS 배포에 영향을 주지 않는지 확인하기 위해 광범위한 테스트가 수행되었습니다.
최신 탐색 환경
이 릴리스에서는 새롭고 향상된 위쪽 탐색 모음을 사용할 수 있습니다. 새로운 탐색에 대한 두 가지 핵심 목표가 있습니다.
- 한 번의 클릭으로 허브에 신속하게 액세스할 수 있도록 하여 제품 영역의 탐색 효율성 향상.
- 제품에 현대적인 시각 효과 및 사용자 환경 적용.
이는 사용자에게 중요한 변화이며 기능이 여전히 반복되고 있기 때문에 Microsoft는 기본적으로 새로운 탐색 UX를 제공하기로 결정했습니다. 이 기능을 사용하려면 Team Foundation Server 관리 영역 제어판으로 이동하여 "새 탐색 사용"을 선택하면 됩니다. 이 기능은 서버의 모든 사용자가 사용할 수 있습니다.
팀 프로젝트 이름 바꾸기 권한
팀 프로젝트 이름을 바꿀 수 있는 사용자를 관리할 수 있는 권한이 변경되었습니다. 이전에는 팀 프로젝트에 대해 프로젝트 수준의 정보 편집 권한이 있는 사용자가 이름을 바꿀 수 있었습니다. 이제는 팀 프로젝트 이름 바꾸기의 새 권한을 통해 팀 프로젝트 이름을 바꿀 수 있는 권한을 사용자에게 부여하거나 허용하지 않을 수 있습니다.
관리 설정 페이지의 작업 허브
[관리 설정] 페이지에 일반 설정 (그림 101) , 반복 및 영역을 단일 탭에 결합하는 새로운 "작업" 허브가 도입되었습니다. 이 변경 때문에 사용자는 프로젝트 수준 설정과 팀 설정의 차이를 명확히 알 수 있습니다. 팀 설정에서는 사용자가 자신의 팀에 관련된 영역과 반복만 볼 수 있습니다. 프로젝트 수준의 설정 페이지에서는 관리자가 전체 프로젝트와 관련된 영역과 반복을 관리할 수 있습니다. 그 외에도 프로젝트 영역 경로에 "팀"이라는 새 열을 추가했고, 이 열을 통해 관리자가 특정 영역 경로를 선택한 팀을 빠르고 쉽게 구분할 수 있습니다.
프로세스 구성 REST API
이 공용 API를 사용하여 사용자는 지정된 프로젝트의 프로세스 구성을 가져올 수 있습니다. 프로세스 구성에는 다음 설정이 포함됩니다.
- TypeFields: agile 도구에 사용되는 사용자 지정 가능한 필드를 추상화한 것입니다. 예를 들어 “스토리 점수” 필드의 형식은 “작업량”입니다.
- 백로그 정의: 각 백로그에 놓을 작업 항목 유형을 정의합니다. 이 API는 확장을 빌드하는 고객들이 자주 요청한 API입니다. 이 같은 데이터를 통해 확장은 프로세스별 필드를 활용하는 법을 인식하여 agile 도구로 일반 시나리오(예: 작업 항목의 활동 또는 작업량 변경, 지정된 백로그 수준에 포함할 작업 항목 인식, 팀을 영역 경로로 식별할지 사용자 지정 필드로 식별할지 결정)를 실행할 수 있게 해줍니다. 자세한 내용은 작업 개요를 참조하세요.
접두사 기반 AD 검색이 포함된 새 관리자 환경
Team Foundation Server 2017에는 그룹 및 그룹 멤버 자격을 관리할 수 있는 새로운 환경이 도입되었습니다. 사용자/그룹 이름에 대한 접두사 기반 검색 조건을 사용하여 Active directory 또는 로컬 컴퓨터 사용자/그룹을 검색할 수 있습니다. 예를 들어 samaccountname뿐 아니라 'John D'(예: ' businessdomain\johbdnd')를 검색하여 사용자/그룹의 대화 상대 카드를 볼 수 있습니다.
사용자 보안 설정
새로운 “내 보안” 환경에서 개인용 액세스 토큰 및 SSH를 관리할 수 있습니다 (그림 102) . “내 프로필”을 사용하여 SSH를 관리하던 사용자는 이제 사용자 보안 설정에서 SSH 공개 키를 관리해야 합니다 (그림 103) .
통합 구성 마법사
이전 릴리스에서는 수행하려는 작업에 따라 TFS 배포에 대한 여러 구성 마법사 중 하나를 선택했습니다. 기본 및 전체 마법사는 새 배포를 구성하는 데 사용하고, 업그레이드 마법사는 프로덕션 및 사전 프로덕션 업그레이드에 사용하고, 애플리케이션 계층 전용 마법사는 기존 배포를 확장하고 애플리케이션 계층을 새 하드웨어로 바꾸는 등 다양한 시나리오에 사용할 수 있었습니다. TFS 2017에서는 이 모든 시나리오가 단일 서버 구성 마법사에 통합되었습니다. 이 마법사에서는 간단한 선택을 통해 각 시나리오를 안내합니다. 또한 사전 프로덕션 업그레이드 및 기존 배포 복제와 같은 고급 구성에서는 이제 서버 ID 변경, 데이터베이스 연결 문자열 다시 매핑 및 외부 종속성에 대한 참조 제거(tfsconfig.exe PrepareClone을 사용하여 수행)를 포함하여 tfsconfig.exe를 통해 수행된 작업을 자동화합니다.
새로운 액세스 수준
Team Foundation 서버의 액세스 수준 관리 포털에 새 Visual Studio Enterprise 그룹이 추가되었으므로 이제 Visual Studio Enterprise 구독을 보유한 사용자를 빠르게 식별할 수 있습니다. 식별된 이러한 사용자에게는 Visual Studio 마켓플레이스에서 설치된 모든 자사 TFS 확장에 대한 모든 권한이 추가 비용 없이 부여됩니다.
개인용 액세스 토큰
이제 SSH 외에 개인용 액세스 토큰을 사용하여 모든 Team Foundation Server에 연결할 수 있습니다 (그림 104) . 이는 Linux 또는 Mac에서 개발하고 모든 자동화 도구 및 GIT에서 사용하려는 경우에 유용합니다. 사용자 보안 설정 페이지에서 개인 액세스 토큰을 관리할 수 있습니다.
알려진 문제
이는 이 릴리스의 알려진 문제에 대한 전체 목록입니다.
Team Foundation Server 2017에는 파워 도구가 없습니다.
문제:
TFS 2017용으로 발표된 파워 도구가 없습니다.
해결 방법:
이전 파워 도구의 대부분이 TFS 2017에 통합되었음을 알리게 되어 기쁩니다. 아쉽게도 프로세스 템플릿 편집기는 통합되지 않았지만 Visual Studio Marketplace에서 가져올 수 있습니다.
사용자 지정 컨트롤 확장 업데이트
문제:
작업 항목 폼에서 필드의 스키마가 변경되었습니다. 사용자 지정 컨트롤 확장에 대한 설명서도 변경되었습니다.
해결 방법:
새 설명서: 작업 항목 폼에 사용자 지정 컨트롤 추가를 참조하세요.
작업 항목 형식 정의를 가져올 때 오류 발생
문제:
작업 항목 페이지 확장이 설치되어 있고 작업 항목 형식 정의를 내보낸 다음, 해당 정의를 가져오는 고객에게는 다음 오류가 발생합니다. "'LayoutMode' 특성이 선언되지 않았습니다".
해결 방법:
작업 항목 유형 정의를 내보낼 때마다 PageContribution 요소에 LayoutMode 특성이 추가로 생깁니다. 정의를 가져오기 전에 PageContribution 모드를 검색하여 LayoutMode 특성을 제거합니다. 예를 들어 LayoutMode="FirstColumnWide"를 제거합니다.
고객이 Git LFS 버전 1.3.1 이상으로 업데이트해야 함
문제:
Git LFS 1.3.1 이전 버전은 향후 릴리스에서 지원되지 않습니다.
해결 방법:
Git LFS를 사용하는 고객은 Git LFS 버전 1.3.1 이상으로 업데이트하는 것이 좋습니다. 이전 버전의 LFS 클라이언트는 이 버전 TFS의 인증 변경 내용과 호환되지 않습니다. 고객이 마이그레이션할 수 있도록 RTW에 대한 단기 해결 방법을 구현했습니다. 이 해결 방법은 업데이트 1에서 제거될 예정이며, 이 시점이 되면 Git LFS 클라이언트 1.3.1 이하 버전이 더는 작동하지 않습니다.
NuGet 복원에서 nuget.org에 있는 패키지를 찾지 못함
문제:
NuGet 3.4.3 이상을 사용하는 경우 NuGet.Config에서 명시적인 소스가 아니면 NuGet 복원 작업에서 NuGet.org로부터 패키지를 복원하지 않습니다.
해결 방법:
NuGet.org가 NuGet.Config에 있는지 확인합니다.
<packageSources><add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3">
</packageSources>
NuGet 빌드 및 릴리스 작업 인증 안 함
문제:
Team Foundation Server/패키지 관리를 사용할 때 빌드 에이전트가 네트워크 서비스 사용자(빌드 에이전트가 서비스로 실행될 때의 기본값)로 실행되면 NuGet 빌드 및 릴리스 작업에서 피드를 인증하지 않습니다. 이 문제는 NuGet 3.5 이전 버전에서 빌드 작업에서 제공된 자격 증명이 아닌 빌드 에이전트를 실행하는 사용자 계정의 자격 증명을 사용하므로 발생합니다.
해결 방법:
NuGet 빌드/릴리스 작업에서 네트워크 서비스로 실행 중인 에이전트를 사용하는 TFS 피드를 사용하려면 NuGet 3.5 이상 버전을 사용해야 합니다.
NuGet 빌드 및 릴리스 작업에서 에이전트의 자격 증명 사용
문제:
NuGet 3.5 이전 버전은 빌드 작업에서 제공된 자격 증명이 아닌 빌드 에이전트를 실행 중인 사용자 계정의 자격 증명을 사용합니다. 이로 인해 예기치 않은 액세스가 발생하거나 피드에 대한 액세스 권한이 없어질 수 있습니다.
해결 방법:
TFS 빌드 에이전트에서 NuGet 3.5 이상 버전을 사용합니다.
외부 확장은 TFS 업그레이드 시 자동으로 업그레이드되지 않습니다.
문제:
Visual Studio Marketplace에서 확장을 다운로드하고, TFS 2015 설치에 게시한 다음, TFS 2017로 업그레이드한 경우 확장의 새 버전이 Marketplace에 게시되더라도 해당 확장이 자동으로 업데이트되지 않습니다.
해결 방법:
TFS 2017로 업그레이드한 후 TFS 2015에 설치한 확장을 제거합니다. 그런 다음 최신 확장을 다시 설치합니다. TFS 2017에는 업데이트된 외부 확장이 있는지 하루에 한 번 자동으로 확인하고 업그레이드하는 기능이 추가되었습니다.
릴리스 정의에서는 Jenkins 작업을 큐에 넣기 작업을 실행할 수 없습니다.
문제:
릴리스 정의에서 Jenkins 작업을 큐에 넣기 작업을 실행하면 500 서버 오류가 발생합니다.
해결 방법:
현재 Jenkins 작업을 큐에 넣기 작업은 TFS 빌드 정의의 일부로는 실행할 수 있지만 빌드 정의로는 실행할 수 없습니다. 빌드 정의로 실행할 수 있는 기능은 이후 릴리스에서 추가할 예정입니다.
TFS 2017 DLL에 사용자 지정 TFS 서버 플러그 인을 다시 빌드해야 함
문제:
TFS 2017로 업그레이드한 후 사용자 지정 TFS 서버 플러그 인이 작동하지 않습니다.
해결 방법:
TFS 2017 어셈블리에 사용자 지정 서버 플러그 인을 다시 빌드하세요.
사용자 지정 TFS 서버 플러그 인의 서버 개체 모델이 TFS 2015 RTM 이후에 변경되었습니다.
문제:
사용자 지정 TFS 서버 플러그 인이 컴파일되지 않습니다.
해결 방법:
이 블로그 게시물에 설명된 대로 소스 코드를 수정하세요.
관리자 작업을 사용하는 경우 예외가 throw됩니다.
문제:
경고 관리 페이지에서 팀 관리자가 특정 사용자에 대한 경고 찾기 검색을 사용하여 팀에 대한 구독을 찾을 때 예외가 발생할 수 있습니다.
해결 방법:
옵션 1:모든 경고 노드를 클릭하고 모든 내 팀 경고 필터를 보이도록 설정합니다. 그러면 해당 사용자가 액세스할 수 있는 모든 그룹에 대한 모든 경고가 표시됩니다.
옵션 2: 그룹이 팀인 경우 팀 이름으로 검색하는 대신, 이 팀의 경고 관리 페이지로 이동하여 구독을 관리합니다.
팀 빌드/릴리스 관리에서 기능 테스트를 실행하기 위한 작업 사용 시 문제
문제:
작업 카탈로그에서 'Visual Studio 테스트 에이전트 배포' 및 '기능 테스트 실행' 작업을 사용하여 [팀 빌드/릴리스 관리]에서 기능 테스트를 실행하면, 현재는 Agents for Visual Studio 2015 업데이트 3이 사용되며 Visual Studio 2013 및 Visual Studio 2015를 사용하여 빌드된 테스트를 실행하는 데만 사용할 수 있습니다. 이러한 작업은 Visual Studio 2017 RC를 사용하여 빌드한 테스트를 실행하는 데는 사용할 수 없습니다. 자세한 내용은 이 블로그 게시물을 참조하세요.
해결 방법:
해결 방법이 없습니다. Test Agent 2017을 사용하고 Visual Studio 2017을 사용하여 빌드한 테스트를 실행하기 위한 지원은 TFS 2017 업데이트 1 기간 내에 추가됩니다.
확장이 자동으로 업데이트되지 않음
문제:
TFS의 이전 버전이 TFS 2017과 연결되도록 업그레이드하고 연결된 모드에서 TFS 2017을 실행 중인 경우 확장이 자동으로 업데이트되어야 하지만, 자동으로 업데이트되지 않습니다.
해결 방법:
지금은 해결 방법이 없습니다. 이 문제는 해결되었으며 자동 업데이트 동작은 TFS 2017 업데이트 2에서 지원됩니다. 특정한 이유로 업데이트 2를 기다릴 수 없는 경우에는 지원 채널을 통해 문의하시면 수정 사항을 미리 공유해 드리겠습니다.
프로덕션 환경에 배포할 수 없는 문제가 발생하는 경우(Go-Live) Microsoft 기술 지원에 문의하세요. (영문만 제공) 미국 업무 시간(월-금 오전 6시-오후6시 PST 기준)에만 지원되며 1근무일 이내에 답변합니다.
Team Foundation Server 2017에 대해 고객이 보고한 문제를 참조하세요.
제안 및 피드백
Microsoft는 여러분의 의견을 기다리고 있습니다! Developer Community를 통해 기능을 제안하고, 문제를 신고 및 추적하고, Stack Overflow에서 조언을 얻을 수 있습니다.