Team Foundation Server 2018 업데이트 2 릴리스 정보
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 2012 이상에서 Team Foundation Server 2018 업데이트 2로 바로 업그레이드할 수 있습니다. TFS 배포가 TFS 2010 이하인 경우 TFS 2018 업데이트 2로 업그레이드하기 전에 중간 단계를 수행해야 합니다. 자세한 정보는 아래 차트 및 TFS 설치 페이지를 참조하세요.
Important
TFS 2018 업데이트 2로 업그레이드하기 전에 TFS 2018 RTM으로 업그레이드할 필요가 없습니다.
릴리스 날짜: 2018년 5월 7일
이제 TFS 2018 업데이트 2로 업그레이드하고, XAML 컨트롤러를 연결하고, XAML 빌드를 계속 실행할 수 있습니다. TFS 2018 RTW 및 업데이트 1에서 XAML 빌드에 대한 지원을 제거한 경우, 일부 사용자는 레거시 XAML 빌드로 인해 업그레이드할 수 없어 차단을 해제하려고 합니다. TFS 2018 업데이트 2는 기존 빌드에 대한 XAML 빌드를 지원하지만, XAML 빌드는 더 이상 사용되지 않아 더 이상 투자할 필요가 없기 때문에 최신 빌드 정의 형식으로 변환하는 것이 좋습니다.
TFS 2018 업데이트 2의 새로운 기능에 대한 요약
Team Foundation Server 2018 업데이트 2에 새로운 기능을 많이 추가했습니다. 몇 가지 중요한 기능은 다음과 같습니다.
- 끌어오기 요청 병합 커밋 보기
- 끌어오기 요청 레이블을 사용하여 검토자 지원
- 끌어오기 요청에 대한 언급
- 스레드 컨텍스트가 포함된 끌어오기 요청 주석 알림
- 끌어오기 요청 상태 확장성
- 작업 항목 추적 알림의 사용자 지정 필드 및 태그 필터
- 현대화 열 옵션
- Not In 쿼리 연산자 지원 추가
- Query for @MyRecentActivity and @RecentMentions
- 계획 필터링
- 릴리스 게이트
- GitHub Enterprise의 지속적인 통합을 통한 빌드
- 향상된 다단계 빌드 기능
- 리포지토리에 변경 내용이 없는 경우 예약된 빌드 건너뛰기
- 업스트림 소스를 통해 원활하게 공용 패키지 사용
- TFS 피드의 보존 정책
- 패키지 관리에서 필터링
- Wiki 검색
- Wiki에서 작업 항목 참조
- Wiki 페이지 편집 시 콘텐츠 미리 보기
- 다양한 Wiki 콘텐츠를 HTML로 붙여넣기
- 프로필 카드
- 원형 아바타
TFS 2018 업데이트 2의 새로운 기능에 대한 세부 정보
기능에 대한 세부 정보를 확인할 수 있는 각 영역은 다음과 같습니다.
코드
코드에 대한 영구 링크 얻기
파일을 볼 때 일반적으로 선택한 분기의 팁에 버전이 표시됩니다. 팁의 파일 버전은 새 커밋으로 변경될 수 있습니다. 이 보기에서 링크를 복사하면 커밋 SHA가 아닌 분기 이름만 URL에 포함되므로 부실 링크가 될 수 있습니다. 이제는 파일 보기를 쉽게 전환하여 분기 대신 커밋을 참조하도록 URL을 업데이트할 수 있습니다. “y” 키를 누르면 보기가 현재 분기의 팁 커밋으로 전환됩니다. 그런 다음, 영구 링크를 복사할 수 있습니다.
API를 통해 최근에 삭제된 리포지토리 복구
소스 제어에서 오래된 리포지토리를 정리할 때 경우에 따라 실수를 할 수 있습니다. Git 리포지토리가 지난 30일 이내에 삭제된 경우 REST API를 통해 복구할 수 있습니다. 자세한 내용은 목록 및 복구 작업에 대한 설명서를 참조하세요.
SSH: 추가 암호화/키 지원 및 오래된 암호화 사용 중단
보안과 호환성을 향상하기 위해 SSH에 지원되는 암호화 목록을 업데이트했습니다. OpenSSH의 지침에 따라 2개의 새 암호화와 3개의 사용되지 않는 암호화를 추가했습니다. 사용되지 않는 암호화는 이 릴리스에서 계속 작동하지만, 나중에 사용량이 떨어지면 제거됩니다.
추가됨:
- AES128 CTR
- AES256 CTR
사용되지 않음:
- AES128
- AES192
- AES256
리포지토리 설정을 사용하여 성능 덮어쓰기 및 보호 방지
이 업데이트에는 Git가 원활하게 실행될 수 있도록 하는 새로운 두 가지 리포지토리 설정이 있습니다.
대/소문자 적용은 서버를 기본 대/소문자 구분 모드(“File.txt” 및 “file.txt”에서 동일한 파일을 참조함)에서 Windows 및 macOS에 친숙한 모드(“File.txt” 및 “file.txt”가 동일한 파일임)로 전환합니다. 이 설정은 파일, 폴더, 분기 및 태그에 영향을 줍니다. 또한 참가자가 소문자만 구분을 실수로 도입하지 않도록 방지합니다. 대부분의 참가자가 Windows 또는 macOS를 실행하는 경우 대/소문자 적용을 사용하는 것이 좋습니다.
파일 크기 제한을 사용하면 새 파일 또는 업데이트된 파일이 설정한 크기 제한을 초과하지 않도록 방지할 수 있습니다. Git 리포지토리의 기록에 존재하는 큰 파일의 수가 많을수록 복제 및 페치 작업의 성능이 저하됩니다. 이 설정은 실수로 이러한 파일을 도입하지 않도록 방지합니다.
변경된 파일이 1,000개 이상 있는 커밋에 대해 향상된 필터링 기능
1,000개가 넘는 파일을 수정한 커밋 또는 끌어오기 요청에서 파일을 검색하는 것이 비효율적이기 때문에 관심이 있는 파일을 찾는 데 추가 로드 링크를 여러 번 클릭해야 했습니다. 이제는 트리 보기에서 콘텐츠를 필터링하는 경우 로드된 상위 1,000개 파일을 살펴보는 대신 커밋의 모든 파일에서 해당 파일을 검색합니다. 1,000개가 넘는 파일이 수정되는 경우에도 커밋 세부 정보 페이지의 성능이 향상됩니다.
강제 푸시로 인해 손실된 커밋 찾기
로컬 참조의 상위 항목이 아니더라도 Git 강제 푸시 수행하고 원격 참조를 업데이트할 수 있습니다. 이로 인해 다른 사용자가 커밋을 잃을 수 있으며 근본 원인을 식별하기가 매우 어려울 수 있습니다. 누락된 커밋과 관련된 문제를 해결하는 데 도움이 되도록 새 푸시 보기에 강제 푸시를 눈에 띄게 만들었습니다.
강제 푸시 태그를 클릭하면 제거된 커밋으로 이동합니다.
이제는 기록되는 원인
원인 보기는 코드 줄을 마지막으로 변경한 사용자를 식별하는 데 유용합니다. 그러나 코드 줄을 이전에 변경한 사용자를 알아야 하는 경우가 있습니다. 향상된 최신 기능인 이 커밋 전에 원인 보기가 도움이 될 수 있습니다. 이름에서 알 수 있듯이, 이 기능을 사용하면 특정 줄을 변경한 버전 이전의 파일 버전으로 다시 이동하여 해당 버전에 대한 원인 정보를 볼 수 있습니다. 선택한 코드 줄이 변경된 파일에 맞춰 각 버전을 살펴보면서 계속 드릴할 수 있습니다.
diff 보기에서 자동 줄 바꿈 설정/해제 및 공백 토글
파일 diff 뷰어에서 두 가지 새 기능, 즉 자동 줄 바꿈 설정/해제 및 공백 토글을 사용할 수 있습니다. 첫 번째 기능은 diff 보기에서 단어 줄 바꿈 설정을 적용할 수 있게 합니다. 이는 줄 바꿈이 빈번하지 않은 파일이 포함된 PR을 검토할 때 특히 유용하며, 마크다운 파일이 좋은 예입니다. 공백 토글 옵션은 줄 또는 파일에서 공백만 변경하는 경우에 유용합니다. 이 설정을 토글하면 diff에서 공백 문자(공백의 점, 탭의 화살표 등)가 강조 표시됩니다.
이러한 설정을 관리하려면 끌어오기 요청 편집기 또는 diff 보기에서 편집기 기본 설정 기어 아이콘을 클릭합니다. 파일 보기의 오른쪽 클릭 메뉴에서 사용자 기본 설정 옵션을 선택합니다.
공백 표시 및 차이 표시, 자동 줄 바꿈 사용, 코드 접기 사용 및 미니맵 표시와 같은 다양한 편집기 기능을 선택합니다.
코드 접기(일부 편집기에서는 “개요”라고 함)는 웹 보기에서도 사용할 수 있습니다. 코드 접기를 사용하도록 설정하면, 빼기 기호를 클릭하여 코드 섹션을 접고 더하기 기호를 클릭하여 접힌 섹션을 펼칩니다. 또한 F1 명령 팔레트는 전체 파일에서 다양한 들여쓰기 수준을 접을 수 있는 옵션을 제공하므로 큰 파일을 더 쉽게 읽고 검토할 수 있게 합니다.
빌드 및 릴리스에 대해 Git 리포지토리에 푸시하는 트랙 코드
이제 푸시 페이지에 병합 커밋의 빌드 및 릴리스 상태가 표시됩니다. 푸시 옆에 있는 상태를 클릭하면 성공을 확인하거나 실패를 조사할 수 있도록 푸시가 포함된 특정 빌드 또는 릴리스가 표시됩니다.
이메일 알림에 렌더링된 마크다운
마크다운은 다양한 서식, 링크 및 이미지를 PR(끌어오기 요청) 설명 및 주석에 추가하는 데 유용합니다. 이제 PR에 대한 이메일 알림에 원시 콘텐츠 대신 렌더링된 값이 표시되어 가독성이 향상되었습니다.
인라인 이미지는 아직 인라인으로 렌더링되지 않지만(단지 링크로만 표시됨), 나중에 추가할 수 있도록 백로그로 유지하고 있습니다.
Windows 탐색기에서 바로 수행하는 TFVC 명령
Windows 파일 탐색기에 통합된 경량 버전 제어 환경을 제공하는 TFVC Windows 셸 확장은 이제 TFS 2018을 지원합니다. 이 도구는 Windows 탐색기 바로 가기 메뉴에서 직접 다양한 TFVC 명령에 편리하게 액세스할 수 있습니다.
TFS 성능 도구의 일부였던 이 도구는 Visual Studio Marketplace에서 독립 실행형 도구로 릴리스되었습니다.
끌어오기 요청에 참여할 수 있는 컨트롤
이전에는 Git 리포지토리를 볼 수 있는 사용자는 모두 끌어오기 요청을 처리할 수 있었습니다. 끌어오기 요청 만들기 및 주석 처리에 대한 액세스를 제어하는 끌어오기 요청에 참여라는 새 권한이 추가되었습니다. 이 새 권한은 이전에 읽기 권한을 보유한 모든 사용자 및 그룹에도 기본적으로 부여됩니다. 이 새 권한의 도입에 따라 추가적인 유연성과 제어 기능이 관리자에게 제공됩니다. Readers(읽기 권한자) 그룹이 진정으로 읽기 전용이 되어야 하는 경우 끌어오기 요청에 참여 권한을 거부할 수 있습니다.
자세한 내용은 리포지토리 권한 설정에 대한 빠른 시작 설명서를 참조하세요.
스레드 컨텍스트가 포함된 끌어오기 요청 주석 알림
대부분의 경우 PR(끌어오기 요청)에 대한 응답은 매우 간단하며 변경 내용이 있거나 적용되었음을 인정합니다. 웹 보기에 이러한 주석이 표시되면 문제가 되지 않지만, 이메일 알림에서 주석을 읽는 경우 원래 주석의 컨텍스트가 손실됩니다. 이는 간단하게 해결할 수 있는 문제가 아닙니다.
이제는 PR 주석에 응답할 때마다 주석 이메일의 이메일 메시지 본문에 이전 회신이 포함됩니다. 이렇게 하면 스레드 참가자가 받은 편지함에서 주석의 전체 컨텍스트를 직접 볼 수 있으므로 웹 보기를 열 필요가 없습니다.
작업 항목 설정 완료
끌어오기 요청을 완료할 때 작업 항목을 완료하는 기능에는 이제 기본 동작을 제어하는 새 리포지토리 설정이 있습니다. 끌어오기 요청으로 작업 항목을 완료하기 위한 사용자 기본 설정을 기억합니다에 대한 새 설정은 기본적으로 사용하도록 설정되어 있으며, 나중에 리포지토리에서 끌어오기 요청을 완료할 때 사용자의 마지막 상태를 유지합니다. 새 설정을 사용하지 않도록 설정한 경우 병합 후 연결된 작업 항목 완료 옵션이 리포지토리의 모든 끌어오기 요청에 대해 기본적으로 사용하지 않도록 설정됩니다. 사용자는 PR을 완료할 때 연결된 작업 항목을 전환하도록 선택할 수 있지만 매번 옵트인해야 합니다.
끌어오기 요청 상태 확장성
분기 정책은 코드의 품질을 높이는 좋은 방법이 될 수 있습니다. 그러나 이러한 정책은 TFS에서 기본적으로 제공하는 통합으로만 제한되었습니다. 새로운 끌어오기 요청 상태 API 및 해당 분기 정책을 사용하여 네이티브 TFS 기능과 마찬가지로 타사 서비스에서 끌어오기 요청 워크플로에 참여할 수 있습니다.
서비스가 끌어오기 요청에 대한 상태 API에 게시되면 새 상태 섹션의 PR 세부 정보 보기에 바로 나타납니다. 상태 섹션은 해당 설명을 표시하고 서비스에서 제공하는 URL에 대한 링크를 만듭니다. 상태 항목은 웹 확장에서 추가할 새 작업에 대해 확장할 수 있는 작업 메뉴(...)도 지원합니다.
상태만으로는 PR의 완료를 차단할 수 없습니다. 정책이 필요합니다. PR 상태가 게시되면 정책을 구성할 수 있습니다. 분기 정책 환경에서 외부 서비스의 승인을 요구할 때 새 정책을 사용할 수 있습니다. +서비스 추가를 선택하여 프로세스를 시작합니다.
대화 상자의 목록에서 상태를 게시하는 서비스를 선택하고 원하는 정책 옵션을 선택합니다.
정책이 활성화되면 정책 섹션의 필수 또는 옵션에 상태가 적절히 표시되고 PR 완료가 적절히 적용됩니다.
상태 API에 대해 자세히 알아보고 직접 사용해 보려면 설명서 및 샘플을 확인해 보세요.
끌어오기 요청 서비스 후크 병합 이벤트
끌어오기 요청 서비스 후크를 사용하는 확장에는 이제 병합 이벤트에 대한 세부 정보 및 필터링 옵션이 있습니다. 병합이 시도될 때마다 병합의 성공 또는 실패와 관계없이 이벤트가 발생합니다. 병합 시도가 실패하면 실패한 원인에 대한 세부 정보가 포함됩니다.
끌어오기 요청으로 완료된 작업 항목에 대해 향상된 오류 메시지
끌어오기 요청으로 작업 항목을 완료하려고 할 때 연결된 작업 항목이 완료됨 상태로 전환되지 않을 수 있습니다. 예를 들어 특정 필드가 필요할 수 있으며 상태를 전환하기 전에 사용자 입력이 필요합니다. 작업 항목 전환을 차단하는 항목이 있는 경우 이를 알려줌으로써 필요한 변경 작업을 수행할 수 있도록 환경이 향상되었습니다.
끌어오기 요청에 대한 언급
이제 PR 주석 및 작업 항목 토론에서 끌어오기 요청을 언급할 수 있습니다. PR을 언급하는 환경은 작업 항목의 환경과 비슷하지만 해시 표시(#) 대신 느낌표(!)를 사용합니다.
PR을 언급하려고 할 때마다 !를 입력하면 최근 PR 목록에서 PR을 선택할 수 있는 대화형 환경이 표시됩니다. 제안 목록을 필터링하기 위한 키워드를 입력하거나 언급하려는 PR의 ID를 입력합니다. PR이 언급되면 ID 및 전체 제목이 있는 인라인으로 렌더링되며 PR 세부 정보 페이지에 연결됩니다.
끌어오기 요청 레이블을 사용하여 검토자 지원
끌어오기 요청에 대한 추가 정보를 검토자에게 전달하는 것이 중요한 경우도 있습니다. 끌어오기 요청은 아직 진행 중인 작업이거나 예정된 릴리스에 대한 핫픽스일 수 있으므로 제목에 추가 텍스트(예: “[WIP]” 접두사 또는 “병합 안 함”)를 추가할 수 있습니다. 이제 레이블은 중요한 세부 정보를 전달하고 끌어오기 요청을 구성하는 데 사용할 수 있는 추가 정보를 사용하여 끌어오기 요청에 태그를 지정하는 방법을 제공합니다.
이름이 바뀐 파일에 기반한 끌어오기 요청 주석
끌어오기 요청이 활성 상태인 동안 파일 이름이 변경되거나 파일이 이동되는 경우가 있습니다. 이전에는 이름이 바뀐 파일에 주석이 있는 경우 코드의 최신 보기에 주석이 표시되지 않았습니다. 이제 이름 변경을 따르도록 주석 추적 기능이 향상되어 이름이 바뀌었거나 이동된 파일의 최신 버전에 대한 주석이 표시됩니다.
끌어오기 요청 병합 커밋 보기
끌어오기 요청 diff 보기는 소스 분기에 도입된 변경 내용을 강조 표시하는 데 유용합니다. 그러나 대상 분기를 변경하면 diff 보기가 예상한 것과 다르게 표시될 수 있습니다. 이제 새 명령(병합 커밋 보기)을 사용하여 끌어오기 요청에 대한 “미리 보기” 병합 커밋의 diff를 볼 수 있습니다. 이 병합 커밋은 병합 충돌을 확인하고 끌어오기 요청 빌드와 함께 사용하기 위해 만들어지며, 끌어오기 요청이 최종적으로 완료될 때 병합 커밋이 표시되는 모양을 반영합니다. diff에 반영되지 않은 변경 내용이 대상 분기에 있는 경우 병합 커밋 diff가 소스 분기와 대상 분기 모두에서 최근 변경 내용을 확인하는 데 유용할 수 있습니다.
병합 커밋 보기 명령과 함께 유용한 또 다른 명령은 병합 다시 시작입니다(동일한 명령 메뉴에서 사용 가능). 끌어오기 요청이 처음 만들어진 후에 대상 분기가 변경된 경우 이 명령을 실행하면 병합 커밋 diff 보기를 업데이트하여 새 미리 보기 병합 커밋이 만들어집니다.
최근에 사용한 검토자
동일한 사용자가 코드를 자주 검토하는 경우 이전보다 쉽게 검토자를 추가할 수 있습니다. 끌어오기 요청에 검토자를 추가할 때 검토자 입력란에 포커스를 놓으면 최근에 추가된 검토자 목록이 자동으로 표시되므로 이름으로 검색할 필요가 없습니다. 다른 모든 검토자와 마찬가지로 해당 검토자를 선택합니다.
끌어오기 요청 자동 완성에 대한 나머지 정책 기준 보기
자동 완성은 분기 정책을 사용하는 팀에 유용한 기능이지만, 선택적 정책을 사용하는 경우 끌어오기 요청이 완료되지 않도록 차단하는 것이 정확히 명확하지 않을 수 있습니다. 이제 끌어오기 요청에 대한 자동 완성을 설정하면 완료를 보류하는 정책 기준의 정확한 목록이 설명선 상자에 명확하게 나열됩니다. 각 요구 사항이 충족되면 나머지 요구 사항이 없고 끌어오기 요청이 병합될 때까지 항목이 목록에서 제거됩니다.
끌어오기 요청에 대한 수학적 논의
끌어오기 요청 주석에 수식 또는 이나 수학 함수 식이 포함될 필요가 있나요? 이제 인라인 및 블록 주석 처리를 모두 사용하여 주석에 KaTeX 함수가 포함 수 있습니다. 자세한 내용은 지원되는 함수 목록을 참조하세요.
포크에 대한 끌어오기 요청 제안
토픽 분기가 리포지토리에서 업데이트될 때마다 토픽 분기에 대한 새 PR(끌어오기 요청)을 만들도록 요구하는 “제안”이 표시됩니다. 이는 새 PR을 만드는 데 매우 유용하며, 포크된 리포지토리에서 작업하는 사용자에 대해서도 사용할 수 있게 되었습니다. 포크에서 분기를 업데이트하면 다음에 포크 또는 업스트림 리포지토리에 대한 코드 허브를 방문할 때 끌어오기 요청을 만들도록 요구하는 제안이 표시됩니다. “끌어오기 요청 만들기” 링크를 선택하면 소스 및 대상 분기와 리포지토리가 미리 선택되어 있는 PR 만들기 환경으로 이동합니다.
끌어오기 요청 정책에 대한 경로 필터
대부분의 경우 빌드의 유효성을 검사하고 테스트를 실행하기 위해 단일 리포지토리에 CI(연속 통합) 파이프라인으로 작성된 코드가 포함됩니다. 이제 통합된 빌드 정책에서 경로 필터링 옵션을 지원하여 각 PR에 대해 필요하고 자동으로 트리거될 수 있는 여러 PR 빌드를 쉽게 구성할 수 있습니다. 필요에 따라 각 빌드에 대한 경로를 지정하고 트리거 및 요구 사항 옵션을 원하는 대로 설정하기만 하면 됩니다.
또한 상태 정책에는 빌드 외에도 경로 필터링 옵션을 사용할 수 있습니다. 이렇게 하면 모든 사용자 지정 또는 타사 정책에서 특정 경로에 대한 정책 적용을 구성할 수 있습니다.
근무
작업 항목 양식의 바로 가기 키
바로 가기 키를 사용하여 작업 항목을 자신에게 할당하고(Alt+i), 토론으로 이동하고(Ctrl+Alt+d), 작업 항목에 빠른 링크를 복사합니다(Shift+Alt+c). 새 바로 가기의 전체 목록을 보려면 작업 항목 폼을 열고 “?”를 입력하거나 아래 표를 참조하세요.
현대화 열 옵션
백로그, 쿼리 및 테스트 허브에서 작업 항목 그리드의 열을 구성하는 데 사용된 열 옵션 대화 상자에서 새 패널 디자인을 사용하도록 업데이트되었습니다. 필드를 검색하여 찾거나, 열을 끌어서 놓아 다시 정렬하거나, 더 이상 필요하지 않은 기존 열을 제거합니다.
마지막 실행 정보 기준 쿼리
프로젝트의 공유 쿼리 트리가 커짐에 따라 쿼리가 더 이상 사용되지 않고 삭제할 수 있는지 확인하기가 어려울 수 있습니다. 공유 쿼리를 관리하는 데 도움이 되도록 쿼리 REST API에 새로운 두 가지 메타데이터 부분(마지막으로 실행한 사용자 및 마지막으로 실행한 날짜)을 추가하여 부실한 쿼리를 삭제하는 정리 스크립트를 작성할 수 있습니다.
작업 항목 그리드에서 제거된 HTML 태그
고객 의견에 따라 웹, Excel 및 Visual Studio IDE의 작업 항목 쿼리 결과 보기에서 여러 줄 텍스트 필드의 동작을 업데이트하여 HTML 서식이 제거되었습니다. 이제 쿼리에 여러 줄 텍스트 필드가 열로 추가되면 일반 텍스트로 표시됩니다. 설명에 HTML이 포함된 기능의 예는 다음과 같습니다.
이전에는 쿼리 결과가 <div><b><u>Customer Value</u>...와 비슷하게 렌더링되었습니다.
Not In 쿼리 연산자 지원 추가
“In” 쿼리 연산자를 지원하는 필드에서 이제 “Not In”을 지원합니다. 중첩된 “Or” 절을 많이 만들지 않고도 ID 목록에 대한 “Not In”, 상태 목록에 대한 “Not In” 등과 같은 작업 항목에 대한 쿼리를 작성할 수 있습니다.
@MyRecentActivity 및 @RecentMentions에 대한 쿼리
중요할 수 있는 작업 항목을 찾는 데 도움이 되도록 ID 필드에 대한 두 가지 쿼리 매크로를 새로 도입했습니다. @RecentMentions를 사용하여 지난 30일 동안 언급한 항목을 보거나 @MyRecentActivity를 사용하여 최근에 보거나 편집한 작업 항목을 살펴봅니다.
작업 항목 추적 알림의 사용자 지정 필드 및 태그 필터
이제 사용자 지정 필드 및 태그에 조건을 사용하여 알림을 정의할 수 있습니다. 이러한 알림이 변경될 때뿐만 아니라 특정 값이 충족될 때도 마찬가지입니다. 또한 작업 항목에 설정할 수 있는 더욱 강력한 알림 세트를 허용합니다.
내 작업 항목 페이지에 대한 언급됨 지원
내 작업 항목 페이지 아래에 언급됨 피벗을 새로 추가했습니다. 이 피벗 내에서 지난 30일 동안 언급된 작업 항목을 검토할 수 있습니다. 이 새 보기를 사용하면 사용자 입력이 필요한 항목에 대한 작업을 빠르게 수행하고, 사용자와 관련된 대화에서 최신 상태를 유지할 수 있습니다.
이 동일한 피벗은 모바일 환경을 통해서도 사용할 수 있으므로 모바일과 데스크톱 간에 일관성을 유지할 수 있습니다.
계획 필터링
배달 계획 확장은 이제 일반적인 필터링 구성 요소를 사용하며 작업 항목 및 보드에 대한 그리드 필터링 환경과 일치합니다. 이 필터링 제어를 사용하면 팀 멤버 모두에게 향상된 유용성과 일관된 인터페이스가 제공됩니다.
업데이트된 계획 탐색
대부분의 사용자가 특정 계획이나 일단의 계획에 대해 관심이 있으며, 즐겨찾기를 사용하여 콘텐츠에 빠르게 액세스합니다. 먼저, 디렉터리 페이지 대신 가장 최근에 방문한 계획으로 이동하도록 계획 허브를 업데이트했습니다. 다음으로, 즐겨찾기 선택기를 사용하여 다른 계획으로 빠르게 전환하거나, 이동 경로를 사용하여 디렉터리 페이지로 다시 이동할 수 있습니다.
작업 보드에서 요구 사항/사용자 펼치기/접기
이제 한 번의 클릭으로 스프린트 작업 보드의 모든 항목을 펼치거나 접을 수 있습니다.
특정 사용자에게 무시 규칙 권한 부여
다른 소스에서 작업 항목을 마이그레이션할 때 조직에서 작업 항목의 원래 속성을 모두 유지하려는 경우가 많습니다. 예를 들어 원래 만든 날짜를 유지하고 원래 시스템의 값으로 만들어진 버그를 만들 수도 있습니다.
작업 항목 업데이트에 대한 API에는 해당 시나리오를 사용할 수 있게 하는 무시 규칙 플래그가 있습니다. 이전에는 해당 API 요청을 만든 ID가 프로젝트 컬렉션 관리자 그룹의 멤버여야 했습니다. 무시 규칙 플래그가 있는 API를 실행하기 위한 프로젝트 수준의 권한을 추가했습니다.
빌드 및 릴리스
XAML 빌드
TFS 2015에는 웹 기반, 플랫폼 간 빌드 시스템을 도입했습니다. XAML 빌드는 TFS 2018 RTW 또는 업데이트 1에서 지원되지 않지만 TFS 2018 업데이트 2에서 XAML 빌드를 활성화했습니다. 따라서 XAML 빌드를 마이그레이션하는 것이 좋습니다.
TFS 2018 업데이트 2로 업그레이드하는 경우:
팀 프로젝트 컬렉션에 XAML 빌드 데이터가 있는 경우 XAML 빌드 기능 사용 중지에 대한 경고가 표시됩니다.
XAML 빌드 정의를 편집하거나 새 XAML 빌드를 큐에 넣을 때 VS 또는 Team Explorer 2017을 사용해야 합니다.
새 XAML 빌드 에이전트를 만들어야 할 경우 TFS 2015 빌드 에이전트 설치 관리자를 사용하여 설치해야 합니다.
XAML 빌드 사용 중단 계획에 대한 설명은 진화하는 TFS/Team Services 빌드 자동화 기능 블로그 게시물을 참조하세요.
향상된 다단계 빌드 기능
단계를 사용하여 빌드 단계를 구성하고, 단계마다 서로 다른 요구를 사용하여 서로 다른 에이전트를 대상으로 지정할 수 있었습니다. 이제 단계를 빌드하는 몇 가지 기능이 추가되어 다음과 같은 작업을 수행할 수 있습니다.
각 단계마다 다른 에이전트 큐를 지정합니다. 즉, 다음과 같이 수행할 수 있습니다.
- macOS 에이전트에서 빌드의 한 단계를 실행하고, Windows 에이전트에서 다른 단계를 실행합니다. 이 방법이 얼마나 유용한지에 대한 멋진 예제를 보려면 모바일 앱 및 서비스용 CI/CD DevOps 파이프라인(Connect(); 2017 비디오)을 참조하세요.
- 빌드 에이전트 풀에서 빌드 단계를 실행하고, 테스트 에이전트 풀에서 단계를 테스트합니다.
테스트를 병렬로 실행하여 더 빠르게 실행합니다. 병렬 처리가 “다중 에이전트”로 구성되고 “VSTest” 작업이 포함된 단계는 이제 구성된 에이전트 수에 따라 테스트 실행을 자동으로 병렬 처리합니다.
각 단계에서 OAuth 토큰에 액세스할 수 있도록 스크립트를 허용하거나 거부합니다. 예를 들어 REST API를 통해 VSTS와 통신하도록 빌드 단계에서 실행되는 스크립트를 허용할 수 있으며, 동일한 빌드 정의에서 테스트 단계에서 실행되는 스크립트를 차단할 수 있습니다.
특정 조건에서만 단계를 실행합니다. 예를 들어 이전 단계가 성공했을 때만 또는 기본 분기에서 코드를 빌드할 때만 실행되도록 단계를 구성할 수 있습니다.
자세한 내용은 빌드 및 릴리스 관리 단계를 참조하세요.
리포지토리에 변경 내용이 없는 경우 예약된 빌드 건너뛰기
인기 있는 요청을 통해 코드에서 변경된 내용이 없을 때 예약된 빌드가 실행되지 않도록 지정할 수 있습니다. 일정에 있는 옵션을 사용하여 이 동작을 제어할 수 있습니다. 기본적으로 동일한 일정에서 마지막으로 예약된 빌드가 전달되고 변경 내용이 더 이상 리포지토리에 체크인되지 않으면 새 빌드를 예약하지 않습니다.
GitHub Enterprise의 지속적인 통합을 통한 빌드
GitHub Enterprise를 버전 제어에 사용하는 경우 CI(지속적인 통합) 빌드를 수행하는 데 더 나은 통합이 이루어졌습니다. 이전에는 외부 Git 커넥터를 통한 코드 변경에 대한 폴링이 제한되어 있어 서버 로드가 증가하고 빌드가 트리거되기 전에 지연이 발생할 수 있었습니다. 이제는 공식적인 GitHub Enterprise 지원을 통해 팀 CI 빌드가 즉시 트리거됩니다. 또한 LDAP 또는 기본 제공 계정과 같은 다양한 인증 방법을 사용하여 연결을 구성할 수 있습니다.
빌드 또는 릴리스 중에 보안 파일을 에이전트에 다운로드할 수 있습니다.
새 보안 파일 다운로드 작업은 VSTS 보안 파일 라이브러리에서 암호화된 파일을 에이전트 컴퓨터에 다운로드하도록 지원합니다. 파일이 다운로드되면 암호가 해독되어 에이전트의 디스크에 저장됩니다. 빌드 또는 릴리스가 완료되면 파일이 에이전트에서 삭제됩니다. 이를 통해 VSTS에 안전하게 암호화되고 저장되는 인증서 또는 프라이빗 키와 같은 중요한 파일을 빌드 또는 릴리스에서 사용할 수 있습니다. 자세한 내용은 보안 파일 설명서를 참조하세요.
소스 리포지토리에서 설치할 수 있는 Apple 프로비전 프로필
Apple 프로비전 프로필 설치 작업은 이미 VSTS 보안 파일 라이브러리에 저장된 프로비전 프로필을 에이전트 컴퓨터에 설치하도록 지원합니다. 프로비전 프로필은 Xcode에서 iOS, macOS, tvOS 및 watchOS와 같은 Apple 앱을 서명하고 패키지하는 데 사용됩니다. 이제 프로비전 프로필은 소스 코드 리포지토리에서 설치할 수 있습니다. 이러한 파일의 보안을 강화하기 위해 보안 파일 라이브러리를 사용하는 것이 좋지만, 향상된 이 기능은 이미 소스 제어에 저장된 프로비전 프로필을 처리합니다.
빌드 태그를 사용하여 빌드할 GitHub 소스 추적
GitHub 또는 GitHub Enterprise의 빌드는 이미 관련된 커밋에 연결됩니다. 빌드한 빌드에 대한 커밋을 추적할 수 있는 것도 마찬가지로 중요합니다. 이제는 TFS에서 소스에 태그 지정을 사용하도록 설정할 수 있습니다. 빌드 정의에서 GitHub 리포지토리를 선택하는 동안 태그 서식과 함께 태그를 지정하려는 빌드 형식을 선택합니다.
그런 다음, GitHub 또는 GitHub Enterprise 리포지토리에 빌드 태그가 표시되는지 살펴봅니다.
빌드 및 릴리스 중에 설치할 수 있는 특정 JDK(Java Development Kit)
특정 JDK는 특정 Java 프로젝트를 빌드하는 데 필요할 수 있지만 에이전트 컴퓨터에서 사용할 수 없습니다. 예를 들어 IBM, Oracle 또는 오픈 소스 JDK의 이전 버전 또는 다른 버전이 프로젝트에 필요할 수 있습니다. Java 도구 설치 관리자 작업은 빌드 또는 릴리스 중에 프로젝트에 필요한 JDK를 다운로드하여 설치합니다. JAVA_HOME 환경 변수는 빌드 또는 릴리스 기간 동안 적절하게 설정됩니다. 특정 JDK는 파일 공유, 소스 코드 리포지토리 또는 Azure Blob Storage를 사용하여 Java 도구 설치 관리자에서 사용할 수 있습니다.
향상된 Xcode 빌드 구성
Xcode 작업은 Xcode 빌드, 테스트, 패키징 구성을 향상시키는 새로운 주 버전(4.*)으로 업데이트되었습니다. Xcode 프로젝트에 하나의 공유 구성표만 있으면 자동으로 사용됩니다. 추가 인라인 도움말이 추가되었습니다. xcrun 패키징과 같이 사용되지 않는 기능은 Xcode 작업의 속성에서 제거되었습니다. 최신의 Xcode 작업 4.* 버전을 사용하려면 기존 빌드 및 릴리스 정의를 수정해야 합니다. 새 정의의 경우, 더 이상 사용되지 않는 이전 Xcode 작업 버전의 기능이 필요하면 정의에서 해당 버전을 선택할 수 있습니다.
릴리스 게이트
연속 모니터링은 DevOps 파이프라인의 필수적인 부분입니다. 배포 후 릴리스의 앱이 정상인지 확인하는 것은 배포 프로세스의 성공만큼 중요합니다. 기업은 프로덕션 환경에서 앱 상태를 자동으로 감지하고 고객이 보고하는 인시던트를 추적하기 위한 다양한 도구를 채택했습니다. 지금까지 승인자는 릴리스를 승격하기 전에 모든 시스템에서 앱의 상태를 수동으로 모니터링해야 했습니다. 그러나 릴리스 관리는 이제 연속 모니터링을 릴리스 파이프라인에 통합하도록 지원합니다. 이 기능을 사용하여 앱에 대한 모든 상태 신호가 동시에 성공할 때까지 시스템에서 이러한 상태 신호 모두를 반복적으로 쿼리한 후에 릴리스를 계속합니다.
먼저 릴리스 정의에서 배포 전 또는 배포 후 게이트를 정의하는 것으로 시작합니다. 각 게이트는 앱의 모니터링 시스템에 해당하는 하나 이상의 상태 신호를 모니터링할 수 있습니다. 기본 제공 게이트는 “Azure Monitor(애플리케이션 인사이트) 경고” 및 “작업 항목”에 사용할 수 있습니다. Azure 함수를 통해 제공되는 유연성을 사용하여 다른 시스템과 통합할 수 있습니다.
실행 시 릴리스는 모든 게이트를 샘플링하고 각 게이트로부터 상태 신호를 수집하기 시작합니다. 동일한 간격으로 모든 게이트에서 수집된 신호가 성공할 때까지 각 간격마다 샘플링을 반복합니다.
새 배포에 사용할 수 있는 정보가 충분하지 않을 수 있으므로 모니터링 시스템의 초기 샘플이 정확하지 않을 수 있습니다. “평가 전 지연” 옵션을 사용하면 모든 샘플이 성공한 경우에도 이 기간에 릴리스가 진행되지 않습니다.
게이트 샘플링 중에는 에이전트 또는 파이프라인이 사용되지 않습니다. 자세한 내용은 릴리스 게이트 설명서를 참조하세요.
릴리스를 트리거하는 아티팩트에 따라 선택적으로 배포
여러 아티팩트 소스를 릴리스 정의에 추가하고 이 릴리스를 트리거하도록 구성할 수 있습니다. 소스 중 하나에 새 빌드를 사용할 수 있으면 새 릴리스가 만들어집니다. 릴리스를 트리거한 소스에 관계없이 동일한 배포 프로세스가 실행됩니다. 이제 트리거하는 소스를 기반으로 하여 배포 프로세스를 사용자 지정할 수 있습니다. 자동 트리거 릴리스의 경우 Release.TriggeringArtifact.Alias 릴리스 변수가 채워져 릴리스를 트리거한 아티팩트 소스를 식별합니다. 이 변수는 작업 조건, 단계 조건 및 작업 매개 변수에서 프로세스를 동적으로 조정하는 데 사용할 수 있습니다. 예를 들어 환경을 통해 변경된 아티팩트만 배포하면 되는 경우가 있습니다.
엔티티 관련 보안 관리
이전에는 역할 기반 보안에서 보안 액세스 역할이 설정되는 경우 이러한 역할은 배포 그룹, 변수 그룹, 에이전트 큐 및 서비스 엔드포인트에 대한 허브 수준에서 사용자 또는 그룹에 대해 설정되었습니다. 이제 특정 엔터티에 대한 상속을 설정/해제할 수 있으므로 원하는 방식으로 보안을 구성할 수 있습니다.
여러 환경 승인
릴리스를 사용한 승인 관리가 이제 더 간단해 졌습니다. 병렬로 배포되는 여러 환경에 대해 동일한 승인자가 있는 파이프라인의 경우, 승인자는 현재 각 승인에 대해 개별적으로 작업을 수행해야 합니다. 이제 이 기능을 사용하면 여러 개의 보류 중인 승인을 동시에 완료할 수 있습니다.
릴리스 템플릿 확장성
릴리스 템플릿을 사용하면 릴리스 프로세스를 정의할 때 시작할 수 있는 기준을 만들 수 있습니다. 이전에는 계정에 새 템플릿을 업로드할 수 있었지만, 이제는 작성자가 자신의 확장에 릴리스 템플릿을 포함할 수 있습니다. GitHub 리포지토리에서 예제를 찾을 수 있습니다.
조건부 릴리스 작업 및 단계
조건부 빌드 작업와 마찬가지로, 이제는 특정 조건이 충족되는 경우에만 작업 또는 단계를 실행할 수 있습니다. 이렇게 하면 롤백 시나리오 모델링에 도움이 됩니다.
기본 제공 조건이 사용자의 요구를 충족시키지 못하거나 작업 또는 단계가 실행될 때 더 세분화된 제어가 필요한 경우 사용자 지정 조건을 지정할 수 있습니다. 조건을 중첩된 함수 집합으로 표현합니다. 에이전트에서 가장 안쪽에 있는 함수를 평가하고 바깥쪽으로 작동합니다. 최종 결과는 작업이 실행될지 여부를 결정하는 부울 값입니다.
서비스 엔드포인트에 대한 요청 기록
서비스 엔드포인트를 사용하면 외부 및 원격 서비스에 연결하여 빌드 또는 배포 작업을 실행할 수 있습니다. 엔드포인트는 프로젝트 범위에서 구성되고 여러 빌드 및 릴리스 정의 간에 공유됩니다. 이제 서비스 엔드포인트 소유자는 엔드포인트를 사용하여 빌드 및 배포에 대한 통합된 보기를 가져올 수 있으므로 감사 및 거버넌스 기능을 향상시키는 데 도움이 됩니다.
편집 가능한 Git 및 GitHub 아티팩트 형식의 기본 속성
이제 아티팩트가 연결된 후에도 Git 및 GitHub 아티팩트 형식의 기본 속성을 편집할 수 있습니다. 이 기능은 안정적인 버전의 아티팩트에 대한 분기가 변경된 시나리오에서 특히 유용하며, 이후의 연속 배달 릴리스에서 이 분기를 사용하여 최신 버전의 아티팩트를 가져와야 합니다.
릴리스 보기의 수동 대량 배포 환경
이제 릴리스의 여러 환경에 배포 작업을 수동으로 동시에 트리거할 수 있습니다. 이렇게 하면 실패한 구성 또는 배포가 있는 릴리스에서 여러 환경을 선택하고 한 번의 작업으로 모든 환경에 다시 배포할 수 있습니다.
폴더에 구성된 Jenkins 다중 분기 파이프라인 지원 및 연결 작업
Jenkins의 프로젝트를 사용하는 것이 훨씬 향상되었습니다.
먼저, Jenkins 다중 분기 파이프라인 프로젝트를 릴리스 정의의 아티팩트 소스로 사용할 수 있습니다.
다음으로, 이전에는 Jenkins 서버의 루트 폴더에서만 Jenkins 프로젝트를 아티팩트로 연결할 수 있었지만, 지금은 폴더 수준에서 구성한 Jenkins 프로젝트를 사용할 수 있습니다. 아티팩트 소스로 사용할 프로젝트를 선택하는 소스 목록에 폴더 경로와 함께 Jenkins 프로젝트 목록이 표시됩니다.
Docker 허브 또는 Azure Container Registry를 아티팩트 소스로 사용
이 기능을 사용하면 릴리스에서 Docker 허브 레지스트리 또는 ACR(Azure Container Registry)에 저장된 이미지를 사용할 수 있습니다. 이는 ACR의 지역에서 복제 기능을 사용하거나 프로덕션 환경에 대한 이미지만 있는 컨테이너 레지스트리에서 환경(예: 프로덕션)에 배포하여 새로운 지역별 변경 내용을 출시하는 것과 같은 시나리오를 지원하기 위한 첫 번째 단계입니다.
이제 릴리스 정의의 + 추가 아티팩트 환경에서 Docker 허브 또는 ACR을 최고급 아티팩트로 구성할 수 있습니다. 지금은 릴리스를 수동으로 또는 다른 아티팩트를 통해 트리거해야 하지만, 곧 새 이미지를 레지스트리에 푸시하는 트리거가 추가될 예정입니다.
기본 아티팩트 버전
이제 버전 제어 아티팩트를 릴리스 정의에 연결할 때 몇 가지 기본 버전 옵션이 있습니다. 특정 커밋/변경 집합을 구성하거나 기본 분기에서 선택할 수 있도록 최신 버전을 구성하기만 하면 됩니다. 일반적으로 최신 버전을 선택하도록 구성하지만, 이는 향후의 모든 지속적인 배포에 대해 특별한 아티팩트 버전을 지정해야 하는 일부 환경에서 특히 유용합니다.
향상된 릴리스 트리거 분기
이제 빌드 정의에 지정된 기본 분기를 기반으로 하여 릴리스 트리거 필터를 구성할 수 있습니다. 이는 기본 빌드 분기에서 모든 스프린트를 변경하고 릴리스 트리거 필터를 모든 릴리스 정의에서 업데이트해야 하는 경우에 특히 유용합니다. 이제 빌드 정의에서 기본 분기를 변경하기만 하면 모든 릴리스 정의에서 이 분기를 자동으로 사용합니다. 예를 들어 팀에서 각 스프린트 릴리스 페이로드에 대한 릴리스 분기를 만드는 경우 빌드 정의에서 새 스프린트 릴리스 분기를 가리키도록 업데이트하고 릴리스에서 이를 자동으로 선택합니다.
패키지 관리 아티팩트에 대한 릴리스 트리거
이제 릴리스 정의에 패키지 관리 아티팩트에 대한 트리거를 설정하여 새 버전의 패키지가 게시될 때 새 릴리스가 자동으로 만들어지도록 할 수 있습니다. 자세한 내용은 릴리스 관리의 트리거에 대한 설명서를 참조하세요.
특정 환경에 대한 변수 그룹 범위 지정
이전에는 변수 그룹이 릴리스 정의에 추가되면 이 그룹에 포함된 변수를 릴리스의 모든 환경에서 사용할 수 있었습니다. 이제 변수 그룹을 특정 환경으로 범위를 조정할 수 있습니다. 이렇게 하면 단일 환경에서 사용할 수 있지만 동일한 릴리스의 다른 환경에서는 사용할 수 없습니다. 이는 환경 간에 서로 다른 SMTP 이메일 서비스와 같은 외부 서비스가 있는 경우에 유용합니다.
Azure Container Registry 및 Docker 허브에서 자동으로 릴리스
컨테이너화된 앱을 배포하는 경우 컨테이너 이미지가 먼저 컨테이너 레지스트리에 푸시됩니다. 푸시가 완료되면 컨테이너 이미지를 컨테이너 또는 Kubernetes 클러스터용 웹앱에 배포할 수 있습니다. 이제 Docker 허브 또는 Azure Container Registry에 저장된 이미지를 아티팩트 소스로 추가하여 업데이트 시 릴리스를 자동으로 만들 수 있습니다.
Jenkins 아티팩트에 대한 기본 버전 지정
여러 아티팩트가 있는 릴리스가 자동으로 트리거되면 릴리스 정의에 저장된 기본 버전이 모든 아티팩트에 대해 선택됩니다. 이전에는 Jenkins 아티팩트에 기본 버전 설정이 없기 때문에 Jenkins를 보조 아티팩트로 사용하는 릴리스에서 지속적인 배포 트리거를 설정할 수 없었습니다.
이제는 친숙한 옵션을 사용하여 Jenkins 아티팩트에 대한 기본 버전을 지정할 수 있습니다.
- 가장 늦은 날짜
- 릴리스를 만들 때 지정
- 특정 버전
확장에서 릴리스 게이트 참가
릴리스 게이트를 사용하면 릴리스 파이프라인에 정보 기반 승인을 추가할 수 있습니다. 상태 신호 세트는 배포 이전 또는 이후에 반복적으로 수집되어 릴리스를 다음 단계로 승격해야 하는지 여부를 결정합니다. 기본 제공 게이트 집합이 제공되며, 지금까지 다른 서비스와 통합하기 위한 수단으로 "Azure 함수 호출"이 권장되었습니다. 이제 다른 서비스와 통합하는 경로를 간소화하고 마켓플레이스 확장을 통해 게이트를 추가합니다. 이제 사용자 지정 게이트 작업을 제공하고 릴리스 정의 작성자에게 게이트를 구성하는 향상된 환경을 제공할 수 있습니다.
게이트 작업 작성에 대해 자세히 알아보세요.
배포 그룹을 사용하여 가상 머신에 배포 확장
강력한 기본 제공 다중 머신 배포를 제공하는 배포 그룹이 이제 출시되었습니다. 배포 그룹을 사용하면 전체적으로 애플리케이션의 고가용성을 보장하면서 여러 서버에서 배포를 오케스트레이션하고 롤링 업데이트를 수행할 수 있습니다. 온-프레미스나 Azure 또는 클라우드의 가상 머신에 서버를 배포할 수도 있으며, 배포된 아티팩트 버전을 서버 수준까지 통합 추적할 수 있습니다.
에이전트 기반 배포 기능은 이미 사용 가능한 동일한 빌드 및 배포 에이전트에 의존합니다. 배포 그룹 단계에서 대상 컴퓨터의 전체 작업 카탈로그를 사용할 수 있습니다. 확장성 관점에서 프로그래밍 방식 액세스에 대해 배포 그룹 및 대상의 REST API를 사용할 수도 있습니다.
Package(패키지)
업스트림 소스를 통해 원활하게 공용 패키지 사용
이제 nuget.org 및 npmjs.com에 대한 업스트림 소스를 사용할 수 있습니다. 이점으로, 업스트림 소스에서 저장된 패키지를 관리(나열 취소, 사용 안 함, 게시 취소, 삭제 등)하는 기능과 사용하는 모든 업스트림 패키지를 저장하도록 보장하는 기능이 있습니다.
TFS 피드의 보존 정책
지금까지 TFS 패키지 피드는 사용되지 않는 이전의 패키지 버전을 자동으로 정리하는 방법을 제공하지 않았습니다. 빈번한 패키지 게시자의 경우 일부 버전을 수동으로 삭제할 때까지 NuGet 패키지 관리자 및 다른 클라이언트의 피드 쿼리 속도가 느려질 수 있습니다.
이제 TFS 피드에 보존 정책을 사용하도록 설정했습니다. 보존 임계값이 충족되면 보존 정책에서 가장 오래된 버전의 패키지를 자동으로 삭제합니다. 보기로 승격된 패키지는 무기한 보존되므로 프로덕션 환경에서 사용되거나 조직 전체에서 널리 사용되는 버전을 보호할 수 있습니다.
보존 정책을 사용하도록 설정하려면 피드를 편집하고 보존 정책 섹션의 패키지당 최대 버전 수에 값을 입력합니다.
패키지 관리에서 필터링
표준 페이지 레이아웃, 명령 모음 컨트롤 및 새 표준 필터 모음을 사용하도록 패키지 페이지가 업데이트되었습니다.
배지를 사용하여 패키지 공유
오픈 소스 커뮤니티에서는 일반적으로 리포지토리의 추가 정보에서 최신 버전의 패키지에 연결되는 배지를 사용합니다. 이제 패키지에 대한 배지를 피드에 만들 수 있습니다. 피드 설정에서 패키지 배지 사용 옵션을 선택하고, 패키지를 선택한 다음, 배지 만들기를 클릭하면 됩니다. 배지 URL을 직접 복사하거나 패키지의 세부 정보 페이지에 배지를 다시 연결하는 미리 생성된 마크다운을 복사할 수 있습니다.
이제 전체 페이지 목록으로 변경된 이전 패키지 버전 목록
업데이트된 패키지 관리 환경에 대해 많은 피드백을 받았습니다. 이에 따라 패키지 세부 정보 페이지에서 이전 패키지 버전 목록을 이동 경로 선택기로 옮겼습니다. 이전 버전에 대한 자세한 정보를 제공하고 버전 번호를 복사하거나 이전 버전으로의 링크를 쉽게 만들 수 있는 새 버전 피벗을 추가했습니다.
패키지 목록에서 패키지 버전 품질 보기
이제 패키지 목록에서 각 패키지 버전의 보기를 보고 품질을 빠르게 확인할 수 있습니다. 자세한 내용은 릴리스 보기 설명서를 참조하세요. 자세한 내용은 ) 설명서를 참조하세요.
Gulp, Yarn 등 인증된 피드 지원
오늘날 npm 작업은 패키지 관리 또는 외부 레지스트리(예: npm Enterprise 및 Artifactory)에 있는 인증된 npm 피드와 원활하게 작동하지만, 지금까지 해당 작업에서 인증된 피드를 지원하지 않는 한 작업 실행기(예: Gulp) 또는 대체 npm 클라이언트(예: Yarn)를 사용하는 것이 어려웠습니다. 후속 작업에서 인증된 피드를 성공적으로 사용할 수 있도록 .npmrc에 자격 증명을 추가하는 새 npm Authenticate 빌드 작업을 추가했습니다.
프로젝트 관리자가 포함된 패키지 피드 기본 권한
이전에는 피드를 만드는 경우 만드는 사용자를 유일한 피드 소유자로 설정하여 해당 사용자가 팀을 전환하거나 조직을 떠날 때 대규모 조직에 관리상의 문제가 발생할 수 있습니다. 이 단일 실패 지점을 제거하기 위해 이제 피드를 만들 때 사용자의 현재 프로젝트 컨텍스트를 사용하여 프로젝트 관리자 그룹을 가져와서 피드 소유자로 만듭니다. 다른 모든 권한과 마찬가지로, 이 그룹을 삭제하고 피드 설정 대화 상자를 사용하여 피드 권한을 추가로 사용자 지정할 수 있습니다.
패키지 재활용 및 복원
사용하지 않는 패키지를 삭제하면 패키지 목록을 깨끗하게 유지하는 데 도움이 되지만 실수로 삭제할 수 있는 경우도 있습니다. 이제 휴지통에서 삭제된 패키지를 복원할 수 있습니다. 삭제된 패키지는 30일 동안 휴지통에서 보관되어 필요한 경우 복원하는 데 충분한 시간을 제공합니다.
모든 위치에서 패키지에 연결
과거에 패키지 허브에 있는 패키지에 URL을 공유할 수도 있었지만, 링크를 사용하는 사용자에게 적용될 수도 있고 적용되지 않을 수도 있는 프로젝트를 URL에 포함해야 하기 때문에 사용하기가 어려웠습니다. 이제 이 업데이트를 사용하면 받는 사람이 액세스할 수 있는 프로젝트를 자동으로 선택하는 URL을 사용하여 패키지를 공유할 수 있습니다.
URL 형식은 'https://< TFSserverURL>/_packaging?feed=<feed>&package=<package>&version=<version>&protocolType=<NuGet|Npm|Maven>&_a=package'
‘<TFSserverURL>’를 제외한 모든 매개 변수는 선택 사항이지만, 패키지를 제공하는 경우 프로토콜 유형을 제공해야 합니다.테스트
Visual Studio 전체가 필요하지 않은 Visual Studio 테스트 작업
빌드/릴리스의 Visual Studio 테스트 작업에는 에이전트에서 테스트를 실행하기 위해 Visual Studio가 필요합니다. 프로덕션 환경에서 테스트를 실행하거나 단순히 여러 에이전트에 테스트를 배포하기 위해 Visual Studio를 설치하는 대신 새로운 Visual Studio 테스트 플랫폼 설치 관리자 작업을 사용합니다. 이 작업은 nuget.org에서 테스트 플랫폼을 가져와서 도구 캐시에 추가합니다. 설치 관리자 작업은 vstest 요구 사항을 충족하고, 정의에 있는 후속 Visual Studio 테스트 작업은 Visual Studio 전체를 에이전트에 설치할 필요 없이 실행할 수 있습니다.
작업 카탈로그에서 설치 관리자 작업을 정의에 추가합니다.
후속 Visual Studio 테스트 작업에서 설치 관리자를 통해 얻은 비트를 사용하도록 구성합니다.
참고 항목
제한 사항: NuGet의 테스트 플랫폼 패키지는 현재 코딩된 UI 테스트 실행을 지원하지 않습니다. 코딩된 UI 테스트에 대한 지원 사용은 백로그로 있습니다. NuGet의 테스트 플랫폼 패키지는 플랫폼 간 패키지이지만 VSTest 작업은 현재 .NET 핵심 테스트 실행을 지원하지 않습니다. .NET 핵심 테스트를 실행하려면 'dot net' 작업을 사용합니다.
기능 테스트 실행 및 테스트 에이전트 배포 작업은 이제 더 이상 사용되지 않습니다.
작년에 빌드, 릴리스 및 테스트에서 에이전트를 통합하기 위한 여정을 시작했습니다. 이는 WinRM 기반 테스트 에이전트 배포 및 기능 테스트 실행 작업과 관련된 다양한 문제점을 해결하기 위한 것입니다. 또한 모든 테스트 요구에 대해 다음을 포함한 VSTest(Visual Studio 테스트) 작업을 사용할 수 있습니다.
- 단위 테스트
- 기능(UI/비UI) 테스트
- MSTest 기반 테스트
- 타사 프레임워크 기반 테스트
- 어셈블리 기반 테스트 사양 또는 테스트 계획/테스트 도구 모음을 사용하여 테스트 실행
- 단일 에이전트 테스트 실행 및 여러 에이전트에 대한 테스트 배포
또한 관리자는 통합 에이전트 방법을 통해 CI/CD에 사용되는 모든 머신을 일관된 방식으로 관리할 수 있습니다.
이 기능을 사용할 수 있도록 다음과 같은 몇 가지 중요한 부분을 제공했습니다.
- 에이전트는 UI 테스트를 위해 구성할 수 있습니다.
- Visual Studio 테스트 플랫폼 설치 관리자를 사용하면 Visual Studio를 미리 설치하지 않고도 VSTest 작업을 실행할 수 있습니다
- 빌드 및 릴리스 정의는 모두 여러 단계로 만들 수 있으며, 각 단계마다 서로 다른 에이전트 큐를 사용하는 기능이 있습니다.
- 자동화된 테스트 사례는 VSTest 작업을 사용하여 테스트 허브에서 실행할 수 있습니다.
이제 위의 모든 요소들이 제대로 갖추어졌으므로 다음 두 가지 작업을 평가할 준비가 되었습니다. 사용되지 않는 작업을 사용하는 기존 정의는 계속 작동하지만, 시간이 지남에 따라 VSTest를 사용하여 지속적인 향상된 기능을 활용하도록 전환하는 것이 좋습니다.
큰 테스트 결과 필터링
시간이 지남에 따라 테스트 자산이 누적되고 대규모 애플리케이션이 무수한 테스트로 쉽게 확장될 수 있습니다. 팀에서는 테스트 실패, 관련 근본 원인 또는 문제의 소유권을 확인하면서 생산성을 높이기 위해 많은 양의 테스트 결과 집합을 탐색하는 더 나은 방법을 찾고 있습니다. 이 기능을 사용할 수 있도록 [빌드 및 릴리스]의 테스트 탭 아래에 3개의 새 필터, 즉 테스트 이름, 컨테이너(DLL) 및 소유자(컨테이너 소유자)를 추가했습니다.
또한 기존의 결과 필터는 이제 여러 결과에 대한 필터링 기능을 제공합니다. 사실상 다양한 필터 기준이 누적됩니다. 사용자가 방금 커밋한 변경에 대한 테스트 결과를 보려는 경우 컨테이너(DLL 이름), 소유자(DLL 소유자), 테스트 이름 또는 이 모든 항목에 대해 필터링하여 사용자와 관련된 결과를 얻을 수 있습니다.
잘 끊어지는 테스트 식별
때로는 테스트가 잘 끊어집니다. 즉 한 실행에서 실패하고, 다른 실행에서 아무런 변경 없이 통과됩니다. 잘 끊어지는 테스트는 실망스러울 수 있으며 테스트 유효성에 대한 신뢰가 훼손됩니다. 이에 따라 오류가 무시되고 버그가 발생합니다. 이 업데이트를 통해 잘 끊어지는 테스트 문제를 해결할 수 있는 첫 번째 솔루션을 배포했습니다. 이제 실패한 테스트를 다시 실행하도록 Visual Studio 테스트 작업을 구성할 수 있습니다. 그런 다음, 테스트 결과에서는 처음에는 테스트가 실패했으며 다시 실행에서 통과되었음을 나타냅니다. 순서가 지정된 데이터 기반 테스트에 대한 다시 실행 지원은 나중에 제공될 예정입니다.
Visual Studio 테스트 작업은 실패한 테스트를 다시 실행하는 최대 시도 횟수 및 광범위하게 분산된 오류가 발생하는 경우 테스트를 다시 실행하지 않도록 하는 실패에 대한 임계값 비율(예: 모든 테스트의 20% 미만이 실패한 경우에만 테스트 다시 실행)을 제어하도록 구성할 수 있습니다.
빌드 및 릴리스 아래의 테스트 탭에서 테스트 결과를 “다시 실행에서 통과됨”으로 필터링하여 실행 중에 불안정한 동작이 있었던 테스트를 파악할 수 있습니다. 현재는 다시 실행에서 통과된 각 테스트의 마지막 시도가 표시됩니다. 총 테스트 아래에서 “다시 실행에서 통과됨(n/m)”을 표시하도록 요약 보기도 수정되었습니다. 여기서 n은 다시 실행에서 통과된 테스트의 수이고, m은 통과된 총 테스트의 수입니다. 모든 시도에 대한 계층적 보기는 다음 몇 가지 스프린트에 제공됩니다.
Visual Studio Test 작업에서 생성된 여러 로그 유형에 대해 향상된 기능 및 지원 미리 보기
실패한 테스트에 대한 표준 출력 및 표준 오류에 해당하는 여러 종류의 로깅 문으로 생성된 로그를 게시하도록 VSTest 작업이 향상되었습니다. 또한 로그 파일에서 검색할 수 있는 기능과 함께 텍스트 및 로그 파일 형식을 볼 수 있도록 미리 보기 환경도 향상되었습니다.
Wiki
Wiki 검색
코드 및 작업 항목의 오른쪽에서 제목별 또는 내용별로 즐겨 찾는 Wiki 페이지를 검색할 수 있습니다. Microsoft DevOps 블로그에서 Wiki 검색에 대한 자세한 내용을 참조할 수 있습니다.
Wiki 페이지 인쇄
Wiki는 다양한 콘텐츠에 사용할 수 있습니다. 경우에 따라 Wiki의 콘텐츠를 인쇄하여 여유 시간에 읽거나, 펜과 종이로 주석을 추가하거나, 오프라인 PDF 복사본을 VSTS 프로젝트 외부의 사용자와 공유하는 것이 유용할 수도 있습니다. 이제는 페이지의 바로 가기 메뉴를 클릭하고 페이지 인쇄를 선택하면 됩니다.
참고 항목
이 기능은 현재 Firefox에서 지원되지 않습니다.
바로 가기 키를 사용하여 Wiki 페이지에 쉽게 참여
이제 바로 가기를 사용하여 키보드만으로 Wiki의 일반적인 편집 및 보기 작업을 더 빠르게 수행할 수 있습니다.
다음과 같이 페이지를 보면서 하위 페이지를 추가하거나 편집하거나 만들 수 있습니다.
페이지를 편집하면서 빠르게 저장하거나, 저장 후 닫거나, 단순히 닫을 수 있습니다.
이러한 키는 굵게 표시된 경우 Ctrl+B, 기울광의 경우 Ctrl+I, 연결용 Ctrl+K 등과 같은 표준 편집 바로 가기에 추가됩니다. 자세한 내용은 바로 가기 키의 전체 목록을 참조하세요.
코드 리포지토리 마크다운에 서식 있는 마크다운 렌더링
이제 코드 리포지토리에 서식 있는 README.MD 파일을 만들 수 있습니다. 코드 리포지토리에 있는 MD 파일의 마크다운 렌더링은 이제 HTML 태그, 블록 따옴표, 이모지, 이미지 크기 조정 및 수식을 지원합니다. 코드에서 Wiki 및 MD 파일의 마크다운 렌더링에는 패리티가 있습니다.
수식을 지원하는 Wiki
애플리케이션에서 수식과 방정식을 처리하는 경우 이제는 LaTeX 형식을 사용하여 Wiki에 넣을 수 있습니다.
Wiki에서 작업 항목 참조
이제 '#' 키를 눌러 가장 최근에 액세스한 작업 항목의 목록을 가져오고 관심 있는 작업 항목을 선택하여 Wiki 페이지에서 작업 항목을 참조할 수 있습니다. 릴리스 정보, 대규모 사용자 스토리, 사양 또는 작업 항목을 참조해야 하는 다른 페이지를 작성하는 경우에 특히 유용합니다.
작업 항목 및 Wiki 페이지 연결
이제 작업 항목을 Wiki에 연결하거나 그 반대로도 연결할 수 있습니다. 작업 항목을 Wiki에 연결하여 대규모 사용자 스토리 페이지, 릴리스 정보 및 Wiki 페이지와 관련된 작업 항목을 추적하고 대규모 사용자 스토리 페이지가 완성된 비율을 확인하는 데 도움이 되는 계획 콘텐츠를 만들 수 있습니다.
연결된 작업 항목이 Wiki 페이지에 표시됩니다.
새로운 “Wiki 페이지” 링크 형식을 통해 작업 항목의 Wiki 페이지에 대한 링크를 추가합니다.
Wiki 페이지를 저장하는 Ctrl+S
Wiki 페이지를 더 빠르고 더 쉽게 저장하는 방법을 원하는 경우가 많았습니다. 이제는 단순히 Ctrl+S 바로 가기 키를 사용하여 페이지를 기본 수정 메시지로 저장한 다음, 계속 편집할 수 있습니다. 사용자 지정 수정 메시지를 추가하려면 저장 단추 옆의 펼침 단추를 클릭하면 됩니다.
서식 있는 Wiki 콘텐츠를 HTML로 붙여넣기
이제 Confluence, OneNote, SharePoint 및 MediaWiki와 같은 브라우저 기반 애플리케이션의 Wiki 마크다운 편집기에서 서식 있는 텍스트를 붙여넣을 수 있습니다. 이는 복잡한 테이블과 같은 서식 있는 콘텐츠를 만들고 Wiki에 표시하려는 사용자에게 특히 유용합니다. 콘텐츠를 복사하여 HTML로 붙여넣기만 하면 됩니다.
Wiki에서 키보드를 사용하여 페이지 이동
이전에는 사용자가 Wiki에서 키보드를 사용하여 페이지를 다시 정렬하거나 페이지를 부모로 다시 지정할 수 없었으며, 이로 인해 키보드 조작을 선호하는 사용자에게 영향을 주었습니다. 이제는 Ctrl+Up 또는 Ctrl+Down 명령을 사용하여 페이지를 다시 정렬할 수 있습니다. 페이지의 바로 가기 메뉴에서 페이지 이동을 클릭하여 해당 페이지를 부모로 다시 지정하고, 새 부모 페이지를 선택하여 이동할 수도 있습니다.
텍스트 강조 표시 필터링
Wiki에서 탐색 창을 필터링하면 전체 페이지 계층 구조가 표시됩니다. 예를 들어 “foobar”라는 제목의 페이지를 필터링하면 필터링된 탐색 창에 부모 페이지도 모두 표시됩니다. 이로 인해 “foobar”라는 제목이 지정되지 않은 페이지가 필터링된 결과 집합에 표시되는 이유가 혼동될 수 있습니다. 이제는 Wiki에서 콘텐츠를 필터링하면 검색 중인 텍스트가 강조 표시되어 필터링된 제목과 그렇지 않은 제목을 명확하게 보여줍니다.
모든 코드 탐색 창에서도 비슷한 동작을 관찰할 수 있습니다. 예를 들어 끌어오기 요청, 커밋, 변경 집합 및 보류 집합의 파일 탐색 창이 있습니다.
Wiki 페이지 편집 시 콘텐츠 미리 보기
데이터에 따르면, 사용자가 콘텐츠를 편집하는 동안 거의 항상 Wiki 페이지를 여러 번 미리 봅니다. 사용자는 각 페이지 편집마다 미리 보기를 평균적으로 1-2회 클릭합니다. 이로 인해 느리고 최적화되지 않은 편집 환경이 되고, 특히 마크다운을 처음 사용하는 사용자에게는 시간이 많이 걸릴 수 있습니다. 이제는 편집하면서 페이지의 미리 보기를 볼 수 있습니다.
일반
프로필 카드
TFS에는 특정 개인과 관련된 정보(예: 개인이 만든 끌어오기 요청, 개인에게 할당된 작업 항목 등)가 표시되는 여러 영역이 있습니다. 그러나 완전한 컨텍스트를 얻는 데 필요한 개인 자체에 대한 정보는 제한되어 있습니다. TFS에서는 새 프로필 카드가 기존 프로필 카드를 대체합니다. 업데이트된 프로필 카드를 사용하면 TFS 계정 내의 사용자와 상호 작용하고 이들에 대해 자세한 정보를 확인할 수 있습니다. 기본 이메일 및 IM 클라이언트와 통합함으로써 AD(Active Directory) 사용자가 이메일을 보내고 프로필 카드에서 직접 채팅을 시작할 수 있습니다. 또한 AD 사용자는 프로필 카드 내에서 조직 계층 구조도 볼 수 있습니다. 연락처 카드 아이콘, 프로필 사진 또는 주석 내의 사용자 이름을 클릭하여 프로필 홈 페이지(팀 멤버 섹션, 버전 제어, 작업 항목 및 Wiki 섹션) 내에서 프로필 카드를 활성화할 수 있습니다.
원형 아바타
이제 원형 아바타가 있습니다! 서비스의 모든 프로필 사진이 정사각형 대신 원 모양으로 표시됩니다. 예를 들어 이 변경에 대한 실제 끌어오기 요청이 있습니다(정사각형 아바타가 아니라 원형 아바타 참조).
프로젝트 태그
이제 중요한 키워드(태그)로 프로젝트를 표시할 수 있습니다. 관리자가 프로젝트 홈 페이지에서 직접 태그를 쉽게 추가하거나 삭제하므로 사용자는 프로젝트의 목적과 범위에 대한 자세한 정보를 더 빨리 파악할 수 있습니다. 프로젝트 태그를 활용하는 방법에 대해 많은 계획이 준비되었으므로 더 많은 뉴스를 기대해 주세요.
즐겨찾는 그룹 다시 정렬
이제 각 그룹 머리글에 있는 위쪽 및 아래쪽 화살표를 사용하여 계정의 내 즐겨찾기 페이지에 있는 그룹을 다시 정렬할 수 있습니다.
피드백 및 제안
많은 의견 부탁드립니다! 개발자 커뮤니티를 통해 문제를 보고 및 추적하고 Stack Overflow에서 조언을 얻을 수 있습니다.