Team Foundation Server 2018 릴리스 정보 Team Foundation Server 2018 Release Notes

참고

영어 이외의 언어 버전에서 이 페이지에 액세스하는 경우 최신 콘텐츠를 보려면 영문 릴리스 정보 페이지를 방문하십시오.If you are accessing this page from a non-English language version, and want to see the most up-to-date content, please visit this Release Notes page in English.

이 페이지의 아래쪽에서 페이지 언어를 전환할 수 있습니다.You can switch the page language at the bottom of this page. 텍스트 커서가 이미 구부러진 빨간 곡선이 있는 줄 위에 있으면 왼쪽 여백에 나타나는Click the 아이콘을 클릭하거나, 언어를 검색하거나, 사용 가능한 언어 목록에서 선택합니다. icon, search for your language, or select from the list of available languages.

Download the latest version of Team Foundation Server

Team Foundation Server 2018에 대한 자세한 내용은 Team Foundation Server 요구 사항 및 호환성 페이지를 참조하세요.To learn more about Team Foundation Server 2018, see the Team Foundation Server Requirements and Compatibility page.


TFS 2018 비디오의 새로운 기능What's New in TFS 2018 video


사용자 의견Feedback

Microsoft는 여러분의 의견을 기다리고 있습니다!We’d love to hear from you! 개발자 커뮤니티를 통해 문제를 보고 및 추적하고 Stack Overflow에서 조언을 얻을 수 있습니다.You can report a problem and track it through Developer Community and get advice on Stack Overflow. Microsoft에서 우선적으로 구현했으면 하는 개선 사항이나 제안 사항이 있으면 UserVoice에서 의견을 제안해 주시거나 기존 의견에 투표해 주세요.As always, if you have ideas on things you’d like to see us prioritize, head over to UserVoice to add your idea or vote for an existing one.


릴리스 날짜: 2017년 11월 15일Release Date: November 15, 2017

요약: Team Foundation Server 2018 업데이트Summary: Team Foundation Server 2018 Updates

Team Foundation Server 2018에 새로운 기능을 많이 추가했습니다.We've added a lot of new value to Team Foundation Server 2018. 몇 가지 중요한 기능은 다음과 같습니다.Some of the highlights include:

이 릴리스에서 제거된 기능Features Removed with this Release


세부 정보: 이번 릴리스의 새로운 기능Details: What's New in this Release

작업 항목 추적 Work Item Tracking

웹의 프로젝트 만들기 마법사 Project Creation Wizard on the web

웹 액세스에서 팀 프로젝트를 만들기 위한 환경을 개선했습니다.We have improved the experience for creating a Team Project from web access. 이제 Visual Studio 클라이언트에서 팀 프로젝트를 만들 때 사용할 수 있는 대부분의 기능이 포함되어 있습니다.It now includes most of the features available when you create a Team Project in the Visual Studio client. 웹 인터페이스를 사용할 때의 이점은 일치하는 Visual Studio 버전이 필요하지 않다는 것입니다.The benefit of using the web interface is that you don't need a matching Visual Studio version. Visual Studio 또는 웹 버전을 사용할 때의 차이점은 웹 버전은 SSRS에서 보고서를 프로비전하지 않는다는 것입니다.The difference of using Visual Studio or the web version is that the web version doesn’t provision your reports in SSRS. 웹 버전의 팀 프로젝트 만들기를 사용하는 경우 응용 프로그램 계층에서 tfsconfig 명령을 실행하여 SSRS 보고서를 프로비전하거나 업데이트할 수 있습니다.If you used the web version of the Team Project creation, you can run the tfsconfig command on the Application Tier to provision or update the SSRS reports. 프로젝트 보고서 추가에서 자세한 내용을 참조하세요.See details in add project reports.

웹의 프로세스 템플릿 관리자Process Template Manager on the web

TFS 2018에서는 웹 액세스를 사용하여 프로세스 템플릿을 업로드할 수 있습니다.With TFS 2018, you can use web access to upload your process templates. 프로세스 템플릿과 상호 작용하기 위해 올바른 버전의 Visual Studio를 설치할 필요가 없으므로 웹 인터페이스는 훨씬 더 쉬운 환경입니다.The web interface is a much easier experience because you don't have to install the correct version of Visual Studio to interact with your process templates. 웹 인터페이스를 사용하는 것이 좋지만 Visual Studio 2017 업데이트 4 및 이전 버전에는 프로세스 템플릿 관리자 대화 상자가 여전히 표시됩니다.Visual Studio 2017 Update 4 and earlier will still show the Process Template Manager dialog, although we recommend using the web interface. Visual Studio 2017 업데이트 5 이상은 자동으로 사용자를 해당 웹으로 리디렉션합니다.Visual Studio 2017 Update 5 and later will redirect you to the web automatically.

작업 항목 폼 헤더 사용자 지정 Customize the work item form header

이제 기존 컨트롤을 바꾸거나 프로세스에 관련되지 않은 컨트롤을 숨겨 작업 항목 폼 헤더 영역을 사용자 지정할 수 있습니다.You can now customize the work item form header area by replacing the existing controls, or hiding controls, that are not relevant to your process. 이렇게 하면 팀이 Kanban에 집중한 경우 영역 경로를 사용자 지정 팀 필드와 바꾸고 반복을 숨기고, 이유를 사용자 지정 필드와 바꿀 수 있습니다.This will enable replacing Area path with a custom Team field, hiding Iteration if your teams are more Kanban focused, and replacing Reason with a custom field. 상태 필드를 숨기거나 바꿀 수 없습니다.The State field cannot be hidden or replaced.

자세한 정보는 WebLayout 및 컨트롤 요소에 대한 설명서를 참조하세요.See the documentation for WebLayout and Control elements for more information.

모바일 작업 항목 폼 Mobile work item form

작업 항목 *(그림 1)*에 대해 최적화된 모양과 느낌을 포함하는 완벽한 종단 간 환경을 제공합니다.We have a full end-to-end experience that includes an optimized look and feel for work items (Figure 1). 이 기능을 사용하면 사용자에게 할당되거나 사용자가 팔로우 중이거나 최근 휴대 전화에서 방문했거나 편집했던 항목과 손쉽게 상호 작용할 수 있습니다.It provides an easy way to interact with items that are assigned to you, that you’re following, or that you have visited, or edited recently, from your phone.

Mobile work item query
(그림 1) 모바일 작업 항목 쿼리(Figure 1) Mobile work item query

이 환경은 화면 구성도 보기 좋으며 모든 필드 형식에 대해 최적화된 컨트롤을 지원합니다*(그림 2)*.Along with the good looks, this experience supports optimized controls for all field types (Figure 2).

Mobile work item form
(그림 2) 모바일 작업 항목 양식(Figure 2) Mobile work item form

새 모바일 탐색*(그림 3)*을 사용하여 사용자는 TFS의 모바일 지원 부분에 연결하고, 다른 허브와 상호 작용해야 할 경우 전체 데스크톱 사이트로 돌아갈 수 있습니다.With the new mobile navigation (Figure 3), users can reach any other mobile-ready parts of TFS and get back to the full desktop site in case they need to interact with other hubs.

Mobile navigation
(그림 3) 모바일 탐색(Figure 3) Mobile navigation

백로그, Kanban 보드, 스프린트 및 쿼리 필터링Filtering on backlogs, Kanban boards, sprints, and queries

이제 모든 작업 항목 추적 표 환경(쿼리, 백로그, Kanban 보드, 스프린트 백로그 및 테스트 사례 관리)에서는 일반적이고 일관된 필터링 구성 요소가 사용됩니다*(그림 4)*.All of our work item tracking grid experiences (queries, backlogs, Kanban boards, sprints backlogs, and test case management) now make use of our common, consistent filtering component (Figure 4). 표시된 열에 걸쳐 키워드 필터를 적용하고 태그를 선택하는 것 외에도, 작업 항목 형식, 상태, 할당 대상을 기준으로 필터링하여 원하는 작업 항목을 빠르게 얻을 수 있습니다.Beyond applying a keyword filter across displayed columns and selecting tags, you can also filter on work item types, states, and assigned to, in order to quickly get to the work items you are looking for.

Filtering on query
(그림 4) 쿼리에서 필터링(Figure 4) Filtering on queries

Kanban 카드의 빈 필드를 표시하도록 확장Expand to show empty fields on a Kanban card

이제 카드에 필드를 더 추가한 다음, 보드 설정에서 빈 필드를 숨겨(그림 5) 불필요한 혼란을 제거할 수 있습니다.Today, you have the option to add additional fields to a card and then hide empty fields (Figure 5) in board settings to remove unnecessary clutter from the board. 이 기능의 단점은 빈 필드가 숨겨진 후 필드를 업데이트하기 위해서는 반드시 작업 항목 폼을 열어야 한다는 것입니다.The drawback to this feature was that once an empty field was hidden, the only way to update the field was to open the work item form. 이제 Kanban 카드에서 새롭게 사용 가능해진 확장 옵션을 사용하여, 보드 전체에서 빈 필드를 숨기면서 클릭 한 번으로 액세스하여 카드의 특정 필드를 업데이트할 수 있습니다.With the newly available expand option on Kanban cards, you can now benefit from hiding empty fields across the board, but still have single click access to update a particular field on a card. 카드 위로 마우스를 가져가기만 하면 카드 아래쪽에 숨겨진 필드를 업데이트할 수 있는 아래쪽 펼침 단추가 표시됩니다.Simply hover over the card and look for the down chevron at the bottom of the card to update the hidden field.

Hidden field
(그림 5) Kanban 카드에서 숨겨진 필드(Figure 5) Hidden field on Kanban card

카드 맨 아래에 있는 아래쪽 펼침 단추를 클릭하여 필드를 업데이트합니다*(그림 6)*.Click the down chevron at the bottom of the card to update the field (Figure 6).

Update hidden field
(그림 6) Kanban 카드에서 숨겨진 필드 업데이트(Figure 6) Update hidden field on Kanban card

확장 기능으로 작업 항목 저장 차단Extensions block work item save

이제 작업 항목 폼 사용자 지정 컨트롤, 그룹 및 페이지에서 작업 항목 저장을 차단하여 작업 항목 폼을 저장하기 전에 데이터의 유효성을 검사하고 사용자가 필요한 정보를 모두 입력하도록 할 수 있습니다.Work item form custom controls, groups, and pages can now block work item save to validate data and ensure the user fills out any required information before saving the work item form.

인라인 추가 배달 계획Inline add on Delivery Plans

새 기능 아이디어는 언제든지 도착할 수 있으므로 배달 계획에 새 기능을 직접 추가하기 더 쉽게 만들었습니다*(그림 7)*.New feature ideas can arrive at any moment, so we’ve made it easier to add new features directly to your Delivery Plans (Figure 7). 가리키기에서 사용할 수 있는 새 항목 단추를 클릭하고 이름을 입력하고 enter 키를 누릅니다.Simply click the New item button available on hover, enter a name, and hit enter. 새로운 기능이 예상한 영역 경로 및 반복 경로와 함께 생성됩니다.A new feature will be created with the area path and iteration path you’d expect.

Inline add on delivery plans
(그림 7) 인라인 추가 배달 계획(Figure 7) Inline add on delivery plans

버전 제어 Version Control

포크 Forks

TFS 2018에서는 Git 포크를 추가로 지원합니다*(그림 8)*.TFS 2018 adds support for Git forks (Figure 8). 포크는 리포지토리의 서버 쪽 복사본입니다.A fork is a server-side copy of a repository. 포크를 사용하여 직접적인 커밋 액세스 권한이 없어도 광범위한 사용자들이 리포지토리에 기여하도록 할 수 있습니다.Using forks, you can allow a broad range of people to contribute to your repository without giving them direct commit access. 대신, 사용자들은 리포지토리의 자체 포크로 작업을 커밋합니다.Instead, they commit their work to their own fork of the repository. 이를 통해 해당 변경 내용을 중앙 리포지토리에 수락하기 전에 끌어오기 요청에서 검토할 수 있습니다.This gives you the opportunity to review their changes in a pull request before accepting those changes into the central repository.

Git forks
(그림 8) Git 포크(Figure 8) Git forks

GVFS GVFS

GVFS(Git 가상 파일 시스템)는 이제 지원됩니다.Git Virtual File System (GVFS) is now supported. GVFS는 Git 리포지토리를 파일 시스템에서 Git의 작동 방식을 가상화하고 최적화하여 수백만 개의 파일로 확장할 수 있도록 합니다.GVFS allows Git repositories to scale to millions of files by virtualizing and optimizing how Git operates on the filesystem.

웹을 사용하여 리포지토리에 폴더 만들기Create a folder in a repository using web

이제 Git 및 TFVC 리포지토리에서 웹을 통해 폴더를 만들 수 있습니다*(그림 9)*.You can now create folders via the web in your Git and TFVC repositories (Figure 9). 이는 이제 사용 중단의 프로세스를 거칠 폴더 관리 확장을 바꿉니다.This replaces the Folder Management extension, which will now undergo the process of deprecation.

폴더를 만들려면 명령 모음 또는 바로 가기 메뉴에서 새로 만들기 > 폴더를 클릭합니다.To create a folder, click New > Folder in either the command bar or context menu:

New folder option
(그림 9) 새 폴더 옵션(Figure 9) New folder option

TFVC의 경우 폴더 이름을 지정한 다음 체크인합니다.For TFVC, you’ll specify a folder name and then check it in. Git의 경우 빈 폴더가 허용되지 않으므로 파일 이름을 지정하고 선택적으로 파일을 편집한 다음 커밋해야 합니다.For Git, because empty folders aren’t permitted, you’ll also have to specify a file name, optionally edit the file, then commit it.

또한 Git의 경우 새 파일 대화 상자 *(그림 10)*가 하위 폴더를 만드는 슬래시를 허용하도록 향상되었습니다.Additionally, for Git, The New file dialog (Figure 10) has been enhanced to accept slashes to create subfolders.

New file dialog
(그림 10) 새 파일 대화 상자(Figure 10) New file dialog

파일 미니 맵File minimap

이제 코드의 간략한 개요를 제공하는 보거나 편집하는 파일의 미니 맵을 볼 수 있습니다*(그림 11)*.You can now view a minimap of a file as you view or edit to give you a quick overview of the code (Figure 11). 미니 맵을 활성화하려면 명령 팔레트(F1 또는 마우스 오른쪽 단추로 클릭)를 열고 미니 맵 설정/해제를 선택합니다.To turn on the minimap, open the Command Palette (F1 or right-click) and select Toggle Minimap.

File minimap
(그림 11) 파일 미니 맵(Figure 11) File minimap

대괄호 일치Bracket matching

파일을 편집하거나 볼 때 대괄호를 쉽게 일치시킬 수 있는 지침이 왼쪽에 있습니다*(그림 12)*.When editing or viewing a file, there are now guidelines on the left side to make it easy to match your brackets (Figure 12).

Bracket matching
(그림 12) 대괄호 일치(Figure 12) Bracket matching

공백 설정/해제Toggle white space

이제 파일을 보거나 편집할 때 공백을 설정 및 해제할 수 있습니다.You can now toggle white space on and off when viewing or editing a file. diff할 때 공백을 설정/해제할 수 있도록 하는 기능을 개발 중입니다.We are still developing a feature that will allow you to toggle white space when diff’ing. 공백*(그림 13)*을 보려면 명령 팔레트(F1 또는 마우스 오른쪽 단추로 클릭)를 열고 공백과 탭을 구분할 수 있도록 하는 공백 설정/해제를 선택합니다.To view white space (Figure 13), open the Command Palette (F1 or right-click) and select Toggle White Space, which allows you to differentiate between spaces and tabs.

Toggle white space
(그림 13) 공백 설정/해제(Figure 13) Toggle white space

TFVC 리포지토리에 대한 웹 편집 해제 설정Setting to turn off web editing for TFVC repos

TFVC를 사용하는 팀은 종종 Visual Studio의 체크 인 정책을 사용하여 코드 품질을 보장합니다.Teams that use TFVC often use check-in policies in Visual Studio to ensure code quality. 그러나 체크 인 정책은 클라이언트에서 적용되므로 웹에서 편집되는 코드에는 동일한 정책이 적용되지 않습니다.However, because check-in policies are enforced on the client, code that is edited on the web isn’t subjected to the same policies.

일부 사용자는 웹 편집을 사용하지 않도록 설정하여 체크 인 정책을 우회하는 변경으로부터 보호할 수 있는 방안을 요청하고 있습니다.Several people have asked for a way to disable web-editing to protect against changes that bypass check-in policies. 프로젝트/리포지토리를 기준으로 TFVC에 대해 웹 편집(추가, 삭제, 이름 바꾸기, 편집)을 해제하는 방법을 사용할 수 있습니다.We’ve enabled a way for you to turn off web-editing (adding, deleting, renaming, and editing) for TFVC on a project/repository basis.

웹 편집을 허용하지 않으려면 파일 페이지에서 __설정__으로 이동한 후 버전 제어*(그림 14)*로 이동합니다.To disallow web-editing from the Files page, go to Settings then Version Control (Figure 14). 트리에서 TFVC 리포지토리를 클릭하고, 옵션 피벗으로 이동한 후 Enable web-editing for this TFVC repository(이 TFVC 리포지토리에 웹 편집 사용)를 선택 취소합니다.Click on the TFVC repo in the tree, navigate to the Options pivot, and uncheck Enable web-editing for this TFVC repository. 기본적으로 웹 편집은 사용되도록 설정됩니다.By default, web-editing is enabled.

참고

__프로젝트 개요 페이지__에서 README를 편집할 때는 영향을 받지 않습니다.Editing the README from the Project Overview page is unaffected.

Turn off web editing
(그림 14) 웹 편집 해제(Figure 14) Turn off web editing

웹 편집이 사용되지 않도록 설정된 프로젝트에서 웹 편집을 사용하려고 하면 웹 편집이 허용되지 않는다는 알림이 표시됩니다*(그림 15)*.If you attempt a web-edit in a project with web-editing disabled, you will be notified that web-editing is not allowed (Figure 15).

Web editing not allowed dialog
(그림 15) 웹 편집 허용 안 함 대화 상자(Figure 15) Web editing not allowed dialog

이 기능은 관련 제안을 토대로 개발되었습니다.This has been developed based on a related suggestion.

부실 분기 식별Identify stale branches

더 이상 필요하지 않은 분기를 삭제하여 리포지토리를 정리하면 팀에서 관심 있는 분기를 찾고 적절한 세분성으로 즐겨찾기를 설정할 수 있습니다.Keeping your repository clean by deleting branches you no longer need enables teams to find branches they care about and set favorites at the right granularity. 그러나 리포지토리에 많은 분기가 있으면 비활성 상태여서 삭제할 수 있는 분기를 파악하기 어려울 수 있습니다.However, if you have lots of branches in your repo, it can be hard to figure out which are inactive and can be deleted. 이제 “부실” 분기(3개월보다 오래된 커밋을 가리키는 분기)를 보다 쉽게 식별할 수 있습니다.We’ve now made it easier to identify “stale” branches (branches that point to commits older than 3 months). 부실 분기를 확인하려면 분기 페이지의 부실 피벗으로 이동합니다*(그림 16)*.To see your stale branches, go to the Stale pivot on the Branches page (Figure 16).

Stale branches
(그림 16)부실 분기(Figure 16) Stale branches

삭제된 분기 검색 및 다시 만들기Search for a deleted branch and re-create it

서버에서 실수로 분기가 삭제된 경우 어떤 상황인지 파악하기 어려울 수 있습니다.When a branch is accidentally deleted from the server, it can be difficult to figure out what happened to it. 이제 삭제된 분기를 검색하고, 삭제한 사용자 및 시간을 확인하고, 원할 경우 다시 만들 수 있습니다.Now you can search for a deleted branch, see who deleted it and when, and re-create it if you wish.

삭제된 분기를 검색하려면 분기 검색 상자에 전체 분기 이름을 입력합니다.To search for a deleted branch, enter the full branch name into the branch search box. 해당 텍스트와 일치하는 기존의 모든 분기가 반환됩니다.It will return any existing branches that match that text. 삭제된 분기 목록에서 정확한 일치 항목을 검색하는 옵션도 제공됩니다.You will also see an option to search for an exact match in the list of deleted branches. 삭제된 분기를 검색하기 위한 링크를 클릭합니다*(그림 17)*.Click the link to search deleted branches (Figure 17).

Search for deleted branches
(그림 17) 삭제된 분기 검색(Figure 17) Search for deleted branches

일치 항목이 있는 경우 삭제한 사용자 및 시간을 확인합니다.If a match is found, you will see who deleted it and when. 분기를 복원할 수도 있습니다*(그림 18)*.You can also restore the branch (Figure 18).

Restore deleted branches
(그림 18) 삭제된 분기 복원(Figure 18) Restore deleted branches

분기를 복원하면 마지막에 가리킨 커밋에서 다시 만들어집니다.Restoring the branch will re-create it at the commit to which is last pointed. 그러나 정책 및 사용 권한은 복원되지 않습니다.However, it will not restore policies and permissions.

접두사로 시작하는 분기에서 커밋 검색Search for a commit in branches starting with a prefix

모든 분기에 접두사가 지정된 계층 구조 형식으로 분기가 구성된 경우 이 기능을 사용하면 해당 접두사 텍스트로 시작되는 모든 분기에서 커밋을 찾을 수 있습니다.If you have branch structure in a hierarchical format where all branches are prefixed with a text, then this feature will help you to find a commit in all the branches starting with that prefix text. 예를 들어 커밋이 접두사 “dev”가 붙은 모든 분기로 연결되어 있는지 확인하려는 경우 검색 상자에 간단히 “dev”를 입력하고 Search in branches starting with "dev"(“dev”로 시작하는 분기 검색)을 선택합니다(그림 19).For example, if you want to see whether a commit made its way to all branches that are prefixed with "dev" then simply type "dev" in the search box and select Search in branches starting with "dev" (Figure 19).

Search for a commit
(그림 19) 커밋 검색(Figure 19) Search for a commit

커밋 세부 정보 페이지의 다양한 끌어오기 요청 설명Richer pull request callout on commit details page

커밋 세부 정보 페이지의 끌어오기 요청 설명은 더 나은 진단에 도움이 되는 적절한 정보를 표시합니다*(그림 20)*.The pull request callout on the commit details page shows more relevant information to help you diagnose better (Figure 20). 또한 이제 분기에 커밋을 도입한 첫 번째 끌어오기 요청기본 분기와 연결된 끌어오기 요청이 설명이 표시됩니다.Now we also show the first pull request that introduced the commit to any branch and the pull request associated with the default branch in the callout.

Pull request callout
(그림 20) 끌어오기 요청 설명(Figure 20) Pull request callout

코드의 트리 뷰 필터링Filter tree view in Code

이제 원하는 파일로 이동하기 위해 커밋으로 인해 수정되었을 수 있는 모든 파일을 스크롤할 필요가 없습니다.Now you don’t need to scroll through all the files that a commit may have modified to just get to your files. 이제 커밋 세부 정보, 끌어오기 요청, 보류 집합 정보, 변경 집합 정보 페이지의 트리 뷰에서 파일 및 폴더 필터링을 지원합니다.The tree view on commit details, pull requests, shelveset details, and changeset details page now supports file and folder filtering. 이 필터는 폴더 이름으로 필터링할 때는 폴더의 자식 파일을 표시하고, 파일 이름으로 필터링할 때는 축소된 트리 뷰를 통해 파일 계층 구조를 표시하는 스마트 필터입니다.This is a smart filter that shows child files of a folder when you filter by folder name and shows a collapsed tree view of a file to display the file hierarchy when you filter by file name.

커밋 트리에서 파일 또는 폴더 필터 찾기*(그림 21)* 및 (그림 22):Find a file or folder filter on commit tree (Figure 21) and (Figure 22):

Find a file or folder
(그림 21) 파일 또는 폴더 찾기(Figure 21) Find a file or folder
Filtered view
(그림 22) 커밋 트리에 대한 필터링된 보기(Figure 22) Filtered view on commit tree

분기 업데이트 페이지가 이제 푸시로 표시됩니다.Branch updates page is now Pushes

분기 업데이트 페이지에는 상당히 큰 값이 있습니다.The Branch Updates page has tremendous value. 그러나 기록 허브 아래에 피벗으로 숨겨져 있습니다.However, it was hidden as a pivot under the History hub. 이제 분기 업데이트 페이지가 코드 아래에 커밋, 분기, 태그끌어오기 요청과 함께 푸시*(그림 23)*라는 허브로 표시됩니다.Now the branch updates page will be visible as a hub called Pushes (Figure 23) under Code, alongside Commits, Branches, Tags, and Pull Requests. 푸시 페이지의 새 URL은 \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/pushes입니다.The new URL for the pushes page is: \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/pushes. 이전 URL은 계속 작동합니다.The old URLs will continue to function.

Pushes page
(그림 23) 푸시 페이지(Figure 23) Pushes page

동시에 기록 허브의 이름이 커밋*(그림 24)*으로 바뀌었습니다. 이 허브에는 커밋만 표시되기 때문입니다.At the same time, the History hub is now renamed to Commits (Figure 24) since the hub only shows commits. 커밋 목록 보기에 커서를 놓으면 자세한 시간만 표시되었으므로 커밋 관련 문제를 해결하는 것이 어렵다는 의견이 있었습니다.We received feedback that people were finding it difficult to troubleshoot commit related issues because the commit list view only showed detailed time on-hover. 이제 인스턴스 전체의 커밋 목록 보기에는 dd/mm/yy hh:mm 형식으로 날짜 및 시간이 표시됩니다.Now the commit list view across your instance will show date and time in dd/mm/yy hh:mm format. 커밋 페이지의 새 URL은 \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/commits입니다.The new URL for commits page is: \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/commits. 이전 URL은 계속 작동합니다.The old URLs will continue to function.

Commits page
(그림 24) 커밋 페이지(Figure 24) Commits page

파일에서 커밋으로 이동할 때 파일 이름 유지Retain filename when moving from Files to Commits

코드 허브의 파일 피벗에서 디렉터리를 특정 파일로 필터링한 다음 나중에 기록 피벗으로 전환하면 커밋이 1,000개 이상의 파일을 변경할 경우 파일 이름이 지속되지 않는다는 의견이 있었습니다.We heard feedback from people that when they filter the directory to a particular file in the Files pivot of the Code hub and later flip to the History pivot, the filename isn’t persisted if the commit changed more than 1,000 files. 이로 인해 사용자들은 파일을 찾기 위해 더 많은 파일을 로드하고 콘텐츠를 필터링해야 했으며, 이는 생산성에 영향을 미쳤습니다.This resulted in people needing to load more files and filter content to find the file, which was impacting productivity. 개발자들은 일반적으로 동일한 디렉터리에서 작동하므로 변경 내용을 추적할 때 작업하든 디렉터리를 유지하려고 합니다.Developers normally work in the same directory and want to persist to the directories they work in as they trace changes. 이제 커밋에서 변경된 파일 수와 관계없이 코드 허브 피벗 간을 전환할 때 파일 이름이 유지됩니다.Now, we persist the filename as you move between Code hub pivots regardless of the number of files changed in a commit. 즉, 원하는 파일을 찾기 위해 추가 로드를 클릭할 필요가 없습니다.This means that you do not have to click on Load More to find the file you want.

Git 태그 보기 View Git tags

태그 페이지에서 리포지토리의 모든 태그를 볼 수 있습니다*(그림 25)*.You can view all the tags in your repository on the Tags page (Figure 25). 모든 태그를 릴리스로 관리하는 경우 사용자는 태그 페이지를 방문하여 모든 제품 릴리스의 조감도를 볼 수 있습니다.If you manage all your tags as releases, then a user can visit the tags page to get a bird’s-eye view of all the product releases.

View Git tags
(그림 25) Git 태그 보기(Figure 25) View Git tags

경량 태그와 주석이 추가된 태그를 쉽게 구별할 수 있습니다.You can easily differentiate between a lightweight and an annotated tag. 주석이 추가된 태그는 관련된 커밋과 함께 태거와 생성 날짜를 표시하지만 경량 태그는 커밋 정보만 표시합니다.Annotated tags show the tagger and the creation date alongside the associated commit, while lightweight tags only show the commit information.

Git 태그 삭제Delete Git tags

원격 리포지토리에서 태그를 삭제하려는 경우가 있을 수 있습니다.There can be times when you want to delete a tag from your remote repo. 태그 이름에 철자 오류가 있거나 잘못된 커밋에 태그를 지정했을 수 있습니다.It could be due to a typo in the tag name, or you might have tagged the wrong commit. 태그 페이지에서 태그의 상황에 맞는 메뉴를 클릭하고 __태그 삭제__를 선택하여 웹 UI에서 태그를 쉽게 삭제할 수 있습니다*(그림 26)*.You can easily delete tags from the web UI by clicking the context menu of a tag on the Tags page and selecting Delete tag (Figure 26).

경고

원격 리포지토리에서 태그를 삭제할 때는 주의해야 합니다.Deleting tags on remote repos should be exercised with caution.

Delete git tags
(그림 26) Git 태그 삭제(Figure 26) Delete Git tags

Git 태그 필터링Filtering Git tags

이전 리포지토리의 경우, 시간에 따라 태그 수가 많이 늘어날 수 있습니다. 또한 태그가 계층 구조로 생성된 리포지토리가 있어서 태그를 찾기 어려운 경우도 있었습니다.For old repositories, the number of tags can grow significantly with time; there can also be repositories that have tags created in hierarchies, which can make finding tags difficult.

태그 페이지에서 찾으려는 태그를 찾을 수 없으면 태그 페이지 맨 위에 있는 필터를 사용하여 태그를 이름을 간단히 검색할 수 있습니다*(그림 27)*.If you are unable to find the tag that you were looking for on the Tags page, then you can simply search for the tag name using the filter on top of the Tags page (Figure 27).

Filter Git tags
(그림 27) Git 태그 필터링(Figure 27) Filter Git tags

Git 태그 보안Git tags security

이제 리포지토리의 사용자에게 태그를 관리하기 위한 보다 세분화된 권한을 부여할 수 있습니다.Now you can grant granular permissions to users of the repo to manage tags. 사용자에게 이 인터페이스에서 태그를 삭제하거나 관리할 수 있는 권한을 부여할 수 있습니다*(그림 28)*.You can give users the permission to delete tags or manage tags from this interface (Figure 28).

Git tag security
(그림 28) Git 태그 보안(Figure 28) Git tag security

Git 태그에 대한 자세한 내용은 Microsoft DevOps 블로그를 참조하세요.Read more about Git tags at the Microsoft DevOps blog.

끌어오기 요청을 완료할 때 작업 항목 자동 완료 Automatically complete work items when completing pull requests

PR에 작업 항목을 연결하는 경우 모든 항목을 간단하게 최신 상태로 유지할 수 있습니다.If you’re linking work items to your PRs, keeping everything up to date just got simpler. 이제 PR을 완료할 때 PR이 성공적으로 병합된 후에 연결된 작업 항목을 자동으로 완료하는 옵션이 제공됩니다*(그림 29)*.Now, when you complete a PR, you’ll have the option to automatically complete the linked work items after the PR has been merged successfully (Figure 29). 정책을 사용하고 PR을 자동으로 완료되도록 설정하는 경우에도 같은 옵션이 표시됩니다.If you’re using policies and set PRs to auto-complete, you’ll see the same option. PR이 완료되면 작업 항목으로 다시 가서 상태를 업데이트할 필요가 없습니다.No more remembering to revisit work items to update the state once the PR has completed. 이러한 작업이 모두 자동으로 진행됩니다.This will be done for you automatically.

Complete linked work items
(그림 29) 연결된 작업 항목 완료(Figure 29) Complete linked work items

푸시/새 반복 시 투표 다시 설정Reset votes on push/new iteration

PR에서 더욱 엄격한 승인 워크플로를 선택한 팀은 이제 새 변경이 푸시될 때 투표를 다시 설정하도록 옵트인할 수 있습니다*(그림 30)*.Teams opting for a more strict approval workflow in PRs can now opt-in to reset votes when new changes are pushed (Figure 30). 새 설정은 최소 인원의 검토자가 필요함 정책에 따라 표시되는 옵션입니다.The new setting is an option under the policy to Require a minimum number of reviewers.

Reset votes setting
(그림 30) 투표 설정 다시 설정(Figure 30) Reset votes setting

이 옵션이 설정되면 PR의 소스 분기가 업데이트될 때마다 모든 검토자의 모든 투표가 다시 설정됩니다.When set, this option will cause all votes from all reviewers to be reset any time the source branch of the PR is updated. PR 타임라인은 이 옵션의 결과로 투표가 다시 설정될 때마다 항목을 기록합니다*(그림 31)*.The PR timeline will record an entry any time the votes are reset as a result of this option (Figure 31).

Reset votes in timeline
(그림 31) 타임라인에서 투표 다시 설정(Figure 31) Reset votes in timeline

파일 이름으로 끌어오기 요청 트리 필터링Filter pull request tree by file name

끌어오기 요청에서 특정 파일을 찾는 것이 이전보다 더 쉬워졌습니다.Finding a specific file in a pull request is easier than ever. 사용자는 파일 뷰의 새 필터 상자로 트리 뷰의 파일 목록을 필터링할 수 있습니다*(그림 32)*.The new filter box in the Files view lets users filter down the list of files in the tree view (Figure 32).

Find file or folder in pull request
(그림 32) 끌어오기 요청에서 파일 또는 폴더 찾기(Figure 32) Find file or folder in pull request

필터는 끌어오기 요청에서 일치하는 파일 경로 부분이 있는지 검색하므로 폴더 이름, 부분 경로, 파일 이름 또는 확장명으로 검색할 수 있습니다*(그림 33)*.The filter matches any part of the path of the files in the pull request, so you can search by folder names, partial paths, file names, or extensions (Figure 33).

Find results
(그림 33) 찾기 결과(Figure 33) Find results

추가 끌어오기 요청 주석 필터링 옵션More pull request comments filtering options

이제 끌어오기 요청 개요 및 파일 보기의 주석 모두 동일한 옵션을 제공합니다*(그림 34)*.Comments in both the pull request overview and the files view now have the same options (Figure 34). 본인이 참여한 토론만 표시되도록 필터링할 수도 있습니다.You can also filter to see only the discussions you participated in.

PR comment filtering
(그림 34) PR 주석 필터링(Figure 34) PR comment filtering

끌어오기 요청 세부 정보에서 코드 주석의 원래 차이점 보기View original diff for code comments in pull request details

경우에 따라 참조하는 코드가 변경된 후에(요청된 변경이 수행되었을 경우 여러 번) PR 주석을 이해하기 어렵습니다*(그림 35)*.Sometimes, it’s hard to make sense out of a PR comment after the code it’s referencing has changed (many times, when a requested change has been made) (Figure 35).

View original diff
(그림 35) 원래 차이점 보기(Figure 35) View original diff

이 경우 주석이 처음 생성되었을 때의 코드 모습을 보기 위해 클릭할 수 있는 배지가 업데이트 번호와 함께 표시됩니다*(그림 36)*.When this happens, you’ll now see a badge with an update number that you can click to see what the code looked like at the time the comment was originally created (Figure 36).

Update badge
(그림 36) 배지 업데이트(Figure 36) Update badge

축소 가능한 끌어오기 요청 주석Collapsible pull request comments

코드 검토는 끌어오기 요청 환경의 중요한 부분이므로 검토자들이 코드에 좀 더 쉽게 집중할 수 있도록 새로운 기능을 추가했습니다.Reviewing code is a critical part of the pull request experience, so we’ve added new features to make it easier for reviewers to focus on the code. 코드 검토자는 새 코드를 처음 검토할 때 주석을 숨겨서 전체적인 코드를 쉽게 파악할 수 있습니다*(그림 37)*.Code reviewers can easily hide comments to get them out of the way when reviewing new code for the first time (Figure 37).

Hide comments
(그림 37) 주석 숨기기(Figure 37) Hide comments

주석을 숨기면*(그림 38)* 트리 뷰에서 숨겨지고 파일 보기에서는 주석 스레드가 축소됩니다.Hiding comments (Figure 38) hides them from the tree view and collapses the comment threads in the file view:

Collapsed comments
(그림 38) 축소된 주석(Figure 38) Collapsed comments

주석이 축소되면 여백에 있는 아이콘을 클릭하여 쉽게 확장할 수 있으며 한 번 더 클릭하면 다시 축소됩니다.When comments are collapsed, they can be expanded easily by clicking the icon in the margin, and then collapsed again with another click. 도구 설명*(그림 39)*을 보면 전체 스레드를 보지 않고도 주석을 쉽게 확인할 수 있습니다.Tooltips (Figure 39) make it easy to peek at a comment without seeing the entire thread.

Collapsed comment tooltip
(그림 39) 축소된 주석 도구 설명(Figure 39) Collapsed comment tooltip

끌어오기 요청 설명 및 주석의 작업 목록Task lists in pull request descriptions and comments

PR을 준비하거나 주석을 달 때, 경우에 따라 추적하려는 항목 목록이 짧아서 텍스트를 편집하거나 여러 주석을 추가하게 됩니다.When preparing a PR or commenting you sometimes have a short list of things that you want to track but then end up editing the text or adding multiple comments. 간단한 작업 목록은 설명 또는 단일 통합 주석에서 PR 작성자 또는 검토자 자격으로 할 일 목록의 진행 상태를 추적하는 유용한 방법입니다.Lightweight task lists are a great way to track progress on a list of to-dos as either a PR creator or reviewer in the description or a single, consolidated comment. Markdown 도구 모음을 클릭하여 시작하거나 선택한 텍스트에 서식을 적용합니다*(그림 40)*.Click on the Markdown toolbar to get started or apply the format to selected text (Figure 40).

Task list toolbar
(그림 40) 작업 목록 도구 모음(Figure 40) Task list toolbar

작업 목록을 추가한 후에는*(그림 41)* 항목을 완료 상태로 표시하는 확인란을 간단히 선택할 수 있습니다.Once you’ve added a task list (Figure 41), you can simply check the boxes to mark items as completed. 이러한 사항은 Markdown에서 [ ][x]로 주석 내에 표시되고 저장됩니다.These are expressed and stored within the comment as [ ] and [x] in Markdown. 자세한 내용은 Markdown 지침을 참조하세요.See Markdown guidance for more information.

Task list
(그림 41) 작업 목록(Figure 41) Task list

끌어오기 요청에 주석에 “좋아요”를 표시하는 기능Ability to “Like” comments in pull requests

좋아요 단추를 한 번 클릭하여 PR 주석에 대한 지원을 표시합니다*(그림 42)*.Show your support for a PR comment with a single click on the like button (Figure 42). 단추 위로 마우스를 가져가 주석에 좋아요를 표시한 모든 사용자의 목록을 볼 수 있습니다.You can see the list of all people that liked the comment by hovering over the button.

Like pull request comments
(그림 42) 끌어오기 요청 주석에 좋아요 표시(Figure 42) Like pull request comments

제안과 함께 승인을 사용할 때 향상된 워크플로 제공Improved workflow when approving with suggestions

끌어오기 요청에 자동 완성 옵션*(그림 43)*을 사용하면 생산성을 향상할 수 있지만 코드 검토자와의 활성 토론이 갑자기 중단되는 것은 바람직하지 않습니다.Using the auto-complete option (Figure 43) with pull requests is a great way to improve your productivity, but it shouldn’t cut short any active discussions with code reviewers. 이러한 토론을 보다 편리하게 활용하기 위해 이제 제안과 함께 승인 투표에서는 끌어오기 요청이 자동으로 완료되도록 설정된 경우 메시지를 표시합니다.To better facilitate those discussions, the Approve with suggestions vote will now prompt when a pull request is set to complete automatically. 사용자는 해당 피드백을 읽을 수 있게 자동 완성을 취소하거나, 자동 완성 설정을 유지하고 모든 정책이 충족될 때 끌어오기 요청이 자동으로 완료되도록 허용하는 옵션을 선택할 수 있습니다.The user will have the option to cancel the auto-complete so that their feedback can be read, or keep the auto-complete set and allow the pull request to be completed automatically when all policies are fulfilled.

Cancel auto-complete dialog
(그림 43) 자동 완성 취소 대화 상자(Figure 43) Cancel auto-complete dialog

Git 알림에 대한 경로 필터링 지원Path filtering support for Git notifications

리포지토리의 모든 폴더에 대해 알림을 받는 대신, 이제 팀 구성원이 사용자에게 관심 있는 폴더에서만 끌어오기 요청 또는 푸시 코드를 만들 때 알림을 받도록 선택할 수 있습니다.Instead of getting notifications for all folders in a repo, you can now choose to get notified when team members create pull requests or push code in only the folders that you care about. 사용자 지정 Git 푸시 또는 Git 끌어오기 요청 전자 메일 알림 구독을 만들 경우 이러한 알림을 폴더 경로별로 필터링하는 새로운 옵션이 표시됩니다*(그림 44)*.When creating custom Git push or Git pull requests email notification subscriptions, you will see a new option to filter these notifications by folder path (Figure 44).

Path filtering for notifications
(그림 44) 알림에 대한 경로 필터링(Figure 44) Path filtering for notifications

끌어오기 요청 워크플로에 대한 업데이트된 전자 메일 템플릿Updated email templates for pull request workflows

끌어오기 요청 전자 메일 알림은 명확하고 간결하며 실행 가능하도록 새로 고쳐졌습니다*(그림 45)*.Pull request email alerts have been refreshed to make them clear, concise, and actionable (Figure 45). 제목 줄은 PR 제목으로 시작되고, 리포지토리 이름 및 ID와 같은 2차적 정보는 끝으로 보냅니다.The subject line will begin with the PR title and secondary information, like the repo name, and ID will be deferred to the end. PR을 만든 사람을 기준으로 규칙 및 필터를 더욱 쉽게 적용할 수 있도록 제목에 작성자의 이름이 추가되었습니다.The name of the author has been added to the subject to make it simpler to apply rules and filters based on the person that created the PR.

경고 전자 메일의 본문에는 경고를 보낸 이유를 요약하고 중요한 메타데이터(제목, 분기 이름 및 설명) 및 기본 행동 요구 지침 단추를 제공하는 새로 고친 템플릿이 포함되어 있습니다.The body of the alert emails has a refreshed template that first summarizes why the alert was sent, followed by the critical metadata (title, branch names, and description), and a main call-to-action button. 검토자, 파일 및 커밋 같은 추가 세부 정보는 전자 메일 아래쪽에 포함되어 있습니다.Additional details like the reviewers, files, and commits are included further down the email.

Improved email template
(그림 45) 향상된 이메일 템플릿(Figure 45) Improved email template

대부분의 경고는 웹에서 끌어오기 요청을 확인해야 합니다*(그림 46)*.For most alerts, the call-to-action (Figure 46) will be to view the pull request in the web. 그러나 특정 주석에 대한 알림이 제공되는 경우에는 컨텍스트에 대한 코드 및 사전 대화를 쉽게 찾을 수 있도록 __해당 주석에 직접 연결__해야 합니다.However, when you’re notified about a specific comment, the call-to-action will link directly to that comment so you can easily find the code and prior conversation for context.

Email call-to-action
(그림 46) 자 메일 행동 요구 지침(Figure 46) Email call-to-action

푸시 알림에 대한 업데이트된 전자 메일 템플릿Updated email templates for push notifications

명백하고 간결하고 조치 가능하도록 최적화된 새 전자 메일 템플릿을 일치시키도록 푸시 알림이 업데이트되었습니다*(그림 47)*.Push notifications have been updated to match the new email templates that are optimized to be clear, concise, and actionable (Figure 47). 제목 줄을 사용하면 푸시 알림을 구분하고, 분기, 리포지토리 및 작성자를 식별하고, 푸시에 포함된 커밋의 수를 요약할 수 있습니다.The subject line helps you clearly distinguish push emails, identify the branch, repo, and author, and summarize the number of commits included in the push. 또한 이러한 변경 내용을 통해 이러한 전자 메일 알림을 관리할 수 있도록 돕는 규칙 및 필터를 쉽게 만들 수 있습니다.These changes also make it easier to create rules and filters to help manage these email notifications.

전자 메일 본문은 전자 메일이 전송된 이유, 작업을 시작한 사람 및 정확히 무슨 상황이 발생했는지를 강조 표시하는 다른 전자 메일로 구성됩니다.The email body is consistent with other emails, emphasizing why the email was sent, who initiated the action, and exactly what happened. 변경 내용의 범위에 대해 받는 사람에게 알릴 수 있도록 푸시 경고에 관련된 리포지토리, 분기, 파일 및 커밋에 대한 세부 정보가 모두 포함됩니다.Specific to push alerts, the details about the repo, branch, files, and commits are all included to help inform the recipients about the scope of the changes. 푸시 경고의 작업에 대한 기본 호출은 푸시 보기이며 경고를 생성하는 특정 푸시에 대한 푸시 보기를 엽니다.The main call-to-action for push alerts is View Push, which will open the pushes view for the specific push that generated the alert.

Push template
(그림 47) 푸시 템플릿(Figure 47) Push template

Wiki Wiki

각 프로젝트는 이제 자체 Wiki를 지원합니다*(그림 48)*.Each project now supports its own Wiki (Figure 48). 이제 팀 구성원이 프로젝트를 이해하고 사용하고 참여하는 데 도움이 되는 페이지를 편리하게 작성할 수 있습니다.Now you can conveniently write pages that help your team members understand, use, and contribute to your project.

Wiki page
(그림 48) PR Wiki 페이지(Figure 48) PR Wiki page

새 Wiki의 주요 기능 중 일부는 다음과 같습니다.Some of the key features of the new Wiki include:

  • Markdown 구문을 사용한 간편한 편집 환경Simplified editing experience using markdown syntax.
  • 새 페이지에서 제목을 지정하고 콘텐츠를 추가할 수 있습니다.The new page allows you to specify a title and add content. 그림 49(Figure 49)
Title Wiki
(그림 49) PR 제목 Wiki(Figure 49) PR Title Wiki
  • Markdown에서 HTML 태그 지원*(그림 50)*.Support for HTML tags in markdown (Figure 50).
Wiki HTML tags
(그림 50) PR Wiki HTML 태그(Figure 50) PR Wiki HTML tags
  • Markdown 폴더에서 이미지 크기를 편리하게 조정*(그림 51)*.Conveniently resize images in the markdown folder (Figure 51).
Image resize
(그림 51) PR 이미지 크기 조정(Figure 51) PR Image resize
  • 페이지 순서와 페이지 부모를 다시 지정하고, 페이지를 관리할 수 있는 강력한 페이지 관리 창.Powerful page management pane that allows you to reorder, re-parent, and manage pages.
  • 큰 Wiki의 경우 제목으로 페이지를 필터링하는 기능*(그림 52)*.Ability to filter pages by title for large Wikis (Figure 52).
Wiki menu
(그림 52) PR Wiki 메뉴(Figure 52) PR Wiki menu

Wiki 시작에 대해 자세히 알아봅니다.Learn more about getting started with Wiki.

  • Wiki를 더 많이 사용하게 되면서 의도치 않은 변경 내용을 저장하는 경우가 발생합니다.As you use Wiki more, there is a chance you’ll save unintended changes. 이제 수정 세부 정보를 클릭하고 되돌리기 단추를 클릭하여 수정 버전을 Wiki 페이지로 되돌릴 수 있습니다*(그림 53)*.Now you can revert a revision to a Wiki page by going to the revision details and clicking on the Revert button (Figure 53).
Wiki revert button
(그림 53) PR Wiki 되돌리기 단추(Figure 53) PR Wiki revert button

Wiki 생성 도중 Wiki 페이지의 목차에 존재하지 않는 링크가 포함된 패턴이 관찰되었습니다*(그림 54)*.We observed a pattern during Wiki creation where a table of contents on a Wiki page included non-existent links (Figure 54). 사용자는 실제 페이지를 만들기 위해 이러한 링크를 클릭합니다.Users would click on these links in an attempt to create an actual page. 이전에는 링크가 끊어졌거나 페이지가 존재하지 않는다는 경고를 표시하여 이 시나리오를 처리했습니다.We previously handled this scenario by giving a warning suggesting that the link was broken, or that the page did not exist. 이제는 사용자들이 대신 페이지를 만들 수 있도록 하여 이러한 문제를 Wiki에 대한 주요 시나리오로 처리하고 있습니다.Now, we are handling this as a mainstream scenario for Wiki, by allowing you to create pages instead.

Create wiki page
(그림 54) PR Wiki 페이지 만들기(Figure 54) PR Create Wiki page

Wiki 페이지 딥 링크 설정Wiki page deep linking

Wiki는 콘텐츠의 테이블 만들기에 매우 유용한 페이지 내 및 페이지에 걸친 딥 링크 설정 섹션을 지원합니다.Wiki now supports deep linking sections within a page and across pages, which is really useful for creating a table of contents. 다음 구문을 사용하여 같은 페이지 또는 다른 페이지에서 제목을 참조할 수 있습니다.You can reference a heading in the same page or another page by using the following syntax:

  • 같은 페이지: [text to display](#section-name)Same page: [text to display](#section-name)
  • 다른 페이지: [text to display](/page-name#section-name)Another page: [text to display](/page-name#section-name)

이제 Marketplace의 Wiki 확장이 더 이상 사용되지 않습니다.The Wiki extension on the Marketplace is now deprecated. 기존 Wiki 확장 사용자는 이 마이그레이션 도구를 사용하여 wiki 페이지를 새 wiki로 마이그레이션할 수 있습니다.If you are an existing Wiki extension user, then you can migrate your Wiki pages to the new Wiki using this migration tool. 기존 Wiki 페이지를 새 Wiki로 마이그레이션하는 방법에 대해 자세히 알아봅니다.Learn more about how to migrate your existing Wiki pages to the new Wiki.

패키지 관리 Package Management

패키지 관리 환경 업데이트Package Management experience updates

이제 패키지 URL은 GUID를 사용하는 대신 패키지 이름 및 버전을 사용합니다.Package URLs now work with the package name and version, rather than using GUIDs. 따라서 패키지 URL을 더욱 쉽게 직접 만들 수 있습니다*(그림 55)*.This makes it easier to hand-craft package URLs (Figure 55). 형식은 \<tfsserverurl\>/\<project|team\>/_packaging?feed=\<feed\>&package=\<package\>&version=\<version\>&protocolType=\<NuGet|Npm|Maven\>&_a=package입니다.The format is: \<tfsserverurl\>/\<project|team\>/_packaging?feed=\<feed\>&package=\<package\>&version=\<version\>&protocolType=\<NuGet|Npm|Maven\>&_a=package.

Package URL
(그림 55) PR 패키지 URL(Figure 55) PR Package URL

UserVoice 제안에 따라 이제 모든 피드 사용자의 삭제된 패키지 버전을 숨길 수 있습니다*(그림 56)*(취소선이 그어진 패키지가 더 이상 표시되지 않음).You can now hide deleted package versions (Figure 56) from all feed users (no more strikethrough packages!), in response to this UserVoice suggestion.

Hide deleted packages
(그림 56) 삭제된 패키지 숨기기(Figure 56) Hide deleted packages

이제 패키지 세부 정보 페이지에서 수행할 수 있는 모든 작업을 패키지 목록의 상황에 맞는 메뉴에서 수행할 수 있습니다.Any action that you could perform on the package details page can now be performed from the context menu in the list of packages.

패키지 목록에는 사용자 중심 날짜가 포함된 새 마지막으로 푸시됨 열*(그림 57)*이 포함되어 있으므로 최근에 업데이트한 패키지를 쉽게 찾을 수 있습니다.The package list contains a new Last pushed column (Figure 57) with humanized dates so you can easily find recently-updated packages.

Last pushed column
(그림 57) 마지막 푸시 열(Figure 57) Last pushed column

Maven 패키지 Maven packages

TFS 2018에 Maven 아티팩트를 호스트하는 지원이 시작되었습니다*(그림 58)*.We’ve launched support for hosting Maven artifacts in TFS 2018 (Figure 58). Maven 아티팩트를 사용하여 Java 개발자는 코드 및 구성 요소를 쉽게 공유할 수 있습니다.Maven artifacts enable Java developers to easily share code and components. 패키지 관리를 사용하여 Maven 아티팩트를 공유하는 방법에 대해서는 시작 가이드를 참조하세요.Check out our getting started guide for how to share Maven artifacts using Package Management.

Maven packages
(그림 58) Maven 패키지(Figure 58) Maven packages

통합된 새 NuGet 작업New unified NuGet task

나머지 빌드 작업 라이브러리에 잘 맞도록 NuGet 복원, NuGet 패키지 작성 도구NuGet 게시자 작업을 통합 NuGet 빌드 작업에 결합했습니다. 새 작업은 기본적으로 NuGet 4.0.0을 사용합니다.We’ve combined the NuGet Restore, NuGet Packager, and NuGet Publisher task into a unified NuGet build task to align better with the rest of the build task library; the new task uses NuGet 4.0.0 by default. 따라서 이전 작업은 더 이상 사용되지 않습니다. 시간이 있을 때 새 NuGet 작업으로 전환하는 것이 좋습니다.Accordingly, we’ve deprecated the old tasks, and we recommend moving to the new NuGet task as you have time. 이러한 변경 작업은 아래에 설명된 기능 개선의 일환으로 진행되며 이러한 향상된 기능은 결합된 작업을 사용해야만 액세스할 수 있습니다.This change coincides with a wave of improvements outlined below that you’ll only be able to access by using the combined task.

이러한 작업의 일부로 PATH에서 사용할 수 있으며 새 NuGet 작업에서 사용되는 NuGet 버전을 제어하는 새로운 NuGet 도구 설치 관리자 작업을 릴리스했습니다.As part of this work, we’ve also released a new NuGet Tool Installer task that controls the version of NuGet available on the PATH and used by the new NuGet task. 따라서 최신 버전의 NuGet을 사용하려면 빌드 시작 부분에 NuGet 도구 설치 관리자 작업을 추가하기만 하면 됩니다*(그림 59)*.So, to use a newer version of NuGet, just add a NuGet Tool Installer task at the beginning of your build (Figure 59).

작업">task">

(그림 59) NuGet 작업(Figure 59) NuGet task

Microsoft DevOps 블로그의 빌드에서 최신 NuGet을 사용하는 방법에 대해 자세히 알아보세요.Read more about using the latest NuGet in your build on Microsoft DevOps Blog.

NuGet “Allow duplicates to be skipped”(중복 항목 건너뛰기 허용) 옵션NuGet “Allow duplicates to be skipped” option

많은 NuGet 고객이 업데이트(및 업데이트된 버전 번호)만 있는 패키지 집합을 생성하고 있다는 정보를 들었습니다.We heard from many NuGet customers that they generate a set of packages, only some of which may have updates (and therefore updated version numbers). NuGet 빌드 작업은 해당 버전이 이미 사용 중인 경우 VSTS/TFS 피드에 패키지를 푸시하려고 할 때 작업이 계속 진행될 수 있도록 하는 Allow duplicates to be skipped(중복 항목 건너뛰기 허용) 옵션을 새로 제공합니다.The NuGet build task has a new Allow duplicates to be skipped option that will enable the task to continue if it tries to push packages to a VSTS/TFS feed where the version is already in use.

npm 빌드 작업 업데이트npm build task updates

Windows, Linux 또는 Mac에서 npm 프로젝트를 빌드할 때 새 NPM 빌드 작업은 원활하게 진행됩니다.Whether you’re building your npm project on Windows, Linux, or Mac, the new NPM build task will work seamlessly. 또한 npm 설치 및 __npm 게시__가 보다 쉽게 진행될 수 있게 작업을 다시 구성했습니다.We have also reorganized the task to make both npm install and npm publish easier. 설치 및 __게시__의 경우 프로젝트의 .npmrc 파일에 나열된 레지스트리에 대한 자격 증명이 서비스 끝점에 안전하게 저장될 수 있도록 자격 증명 획득을 단순화했습니다.For install and publish, we have simplified credential acquisition so that credentials for registries listed in your project’s .npmrc file can be safely stored in a service endpoint. 또는 VSTS/TFS 피드를 사용하는 경우 피드를 선택할 수 있는 선택 기능이 제공되며, 빌드 에이전트에서 사용되는 필수 자격 증명으로 .npmrc를 생성하게 됩니다.Alternatively, if you’re using a VSTS/TFS feed, we have a picker that will let you select a feed, and then we will generate a .npmrc with requisite credentials that are used by the build agent.

이제 Maven에서 인증된 피드가 지원됨Maven now supports authenticated feeds

NuGet 및 __npm__과 달리 Maven 빌드 작업은 이전에는 인증된 피드와 쉽게 연동되지 않았습니다.Unlike NuGet and npm, the Maven build task did not previously work with authenticated feeds. 이제 Maven 작업이 업데이트되어, VSTS/TFS 피드를 쉽게 사용할 수 있습니다*(그림 60)*.We’ve updated the Maven task so you can work easily with VSTS/TFS feeds (Figure 60).

dotnet task
(그림 60) dotnet 작업(Figure 60) dotnet task

dotnet 작업이 인증된 피드, 웹 프로젝트를 지원함dotnet task supports authenticated feeds, web projects

dotnet 작업의 다음 주 버전(2.x)은 많은 피드백 요청을 해결하고 그동안 추적한 버그 집합을 수정합니다.The next major version of the dotnet task (2.x) addresses many of your feedback requests and fixes a set of bugs we’ve tracked for a while.

  1. 첫째, __dotnet__은 패키지 관리와 같은 인증된 패키지 소스를 지원하므로 이제 더 이상 개인 패키지 소스에서 패키지를 복원하기 위해 NuGet 작업을 사용할 필요가 없습니다.First, dotnet now supports authenticated package sources like Package Management, so you don’t need to use the NuGet task anymore to restore packages from private package sources.
  2. 프로젝트 경로 필드의 동작이 작업의 2.0 버전에서는 변경되었습니다.The behavior of Path to project(s) field has changed in the 2.0 version of the task. 작업의 이전 버전에서는 지정된 패턴과 일치하는 프로젝트 파일을 찾을 수 없으면 작업은 경고를 로그한 후 성공 결과를 나타냈습니다.In previous versions of the task, if the project file(s) matching the specified pattern were not found, the task used to log a warning and then succeed. 이러한 시나리오에서는 경우에 따라 빌드는 성공했으나 종속성은 복원되지 않은 이유를 이해하기 어려울 수 있습니다.In such scenarios it can sometimes be challenging to understand why the build succeeded but dependencies were not restored. 이제 지정한 패턴과 일치하는 프로젝트 파일을 찾을 수 없는 경우 작업은 실패합니다.Now the task will fail if the project file(s) matching the specified pattern are not found. 이러한 과정이 다른 작업의 동작에 맞게 진행되며 이해하고 사용하기 쉽습니다.This is in line with the behavior of other tasks and is easy to understand and use.
  3. 이전 버전의 작업 게시 명령에서는 명시적인 출력 경로를 입력한 경우에도 프로젝트 파일 이름을 따라 명명된 폴더에 모든 파일이 추가되는 방식으로 출력 경로가 수정되었습니다.In previous versions of the task’s publish command, the task modified the output path by putting all the files in a folder that was named after the project file name, even when you passed an explicit output path. 이로 인해 명령을 연결해서 실행하기 어렵습니다.This makes it hard to chain commands together. 이제 출력 파일 경로를 제어할 수 있습니다.Now you have control over the output path file.

PATH에서 사용할 수 있으며 새 dotnet 작업에서 사용되는 dotnet 버전을 제어하는 새로운 dotnet 도구 설치 관리자 작업을 릴리스했습니다.We’ve also released a new dotnet Tool Installer task that controls the version of dotnet available on the PATH and used by the new dotnet task. 따라서 최신 버전의 __dotnet__을 사용하려면 빌드 시작 부분에 dotnet 도구 설치 관리자 작업을 추가하기만 하면 됩니다.So, to use a newer version of dotnet, just add a dotnet Tool Installer task at the beginning of your build.

사용자 계정/컬렉션 외부에서 작업Working outside your account/collection

이제 사용자의 TFS 서버 또는 VSTS 계정 외부의 피드*(그림 61)를 사용하기가 더 쉬워졌습니다. 예를 들어 다른 VSTS 계정이나 TFS 서버의 패키지 관리 피드나 NuGet.org/npmjs.com, Artifactory 또는 MyGet과 같은 비패키지 관리 피드를 사용할 수 있습니다(그림 60)*.It’s now easier to work with feeds (Figure 61) outside your TFS server or VSTS account, whether they’re Package Management feeds in another VSTS account or TFS server or non-Package Management feeds like NuGet.org/npmjs.com, Artifactory, or MyGet (Figure 60). NuGet 및 npm에 대해 전용 서비스 끝점 유형을 사용하면 올바른 자격 증명을 쉽게 입력할 수 있으며 다운로드 패키지 및 패키지 푸시 작업에서 빌드 작업을 원활하게 수행할 수 있습니다.Dedicated Service Endpoint types for NuGet and npm make it easy to enter the correct credentials and enable the build tasks to work seamlessly across package download and package push operations.

Feeds to use
(그림 61) 사용할 피드(Figure 61) Feed to use

VSTS/TFS 피드용 피드 선택Feed picker for VSTS/TFS feeds

항상 구성 파일(예: NuGet.Config, .npmrc 등)을 확인하여 소스 리포지토리에서 패키지의 원본 위치에 대한 기록이 있는지 점검하는 것이 좋습니다.We always recommend checking in a configuration file (e.g. NuGet.Config, .npmrc, etc.) so that your source repository has a record of where your packages came from. 그러나 이러한 방식이 이상적이지 않은 경우가 여러 차례 확인되었으므로 피드를 선택하고 해당 빌드 단계에 사용할 구성 파일을 자동으로 생성할 수 있는 새로운 이 VSTS/TFS 피드의 패키지 사용 옵션을 추가했습니다*(그림 62)*.However, we’ve heard a set of scenarios where this isn’t ideal, so we’ve added a new Use packages from this VSTS/TFS feed option that allows you to select a feed and automatically generate a configuration file that will be used for that build step (Figure 62).

Feed picker
(그림 62) 피드 선택(Figure 62) Feed picker

빌드 및 릴리스 Build and Release

XAML 빌드에 대한 지원 제거 Removing support for XAML Builds

TFS 2015에는 웹 기반, 플랫폼 간 빌드 시스템을 도입했습니다.In TFS 2015, we introduced a web-based, cross-platform build system. TFS 2018에서는 이러한 시스템이 지원되는 유일한 모델입니다.In TFS 2018, that is the only model we support. XAML 빌드는 TFS 2018에서 지원되지 않습니다.XAML builds are not supported in TFS 2018. 따라서 XAML 빌드를 마이그레이션하는 것이 좋습니다.We encourage you to migrate your XAML builds. 아직 마이그레이션할 준비가 되지 않았고 XAML 빌드를 계속 사용해야 할 경우에는 TFS 2018로 업그레이드하지 않도록 합니다.If you're not yet ready to migrate and need to continue using XAML builds, then you should not upgrade to TFS 2018.

TFS 2018로 업그레이드하는 경우:When you upgrade to TFS 2018:

  • 팀 프로젝트 컬렉션에 XAML 빌드 데이터가 있는 경우 XAML 빌드 기능 제거에 대한 경고가 표시됩니다.If you have any XAML build data in your team project collection, you'll get a warning about the removal of XAML build features.

  • TFS 2018에서도 완료된 XAML 빌드를 볼 수 있지만 새 빌드를 큐에 대기할 수는 없습니다.In TFS 2018, you'll be able to view completed XAML builds, but you won't be able to queue new ones.

  • TFS 2018에 새 버전의 XAML 빌드 컨트롤러 또는 에이전트는 없으며 이전 버전의 XAML 빌드 컨트롤러 또는 에이전트를 TFS 2018에서 사용하도록 구성할 수도 없습니다.There's no new version of the XAML build controller or agent in TFS 2018, and you can't configure an older version of the XAML build controller or agent to work with TFS 2018.

XAML 빌드 사용 중단 계획에 대한 설명은 진화하는 TFS/Team Services 빌드 자동화 기능 블로그 게시물을 참조하세요.For an explanation of our XAML build deprecation plan, see the Evolving TFS/Team Services build automation capabilities blog post.

빌드 정의 내보내기 및 가져오기 Export and import build definitions

빌드 정의는 내부적으로 .json 파일로 구현되므로 파일 기록에서 변경 내용에 세부 정보를 볼 수 있습니다.Build definitions are implemented internally as .json files, so you can see details on changes in the file’s history. 빌드 정의를 복제하고 빌드 정의에서 템플릿을 만들 수 있지만 많은 사용자가 CI 빌드 논리 복사본를 만든 후 다른 팀 프로젝트에서 다시 사용하는 것을 선호했습니다.You can already clone and make templates from your build definitions, but many users have wanted to take a copy of their CI build logic and reuse it in another team project. 실제로 UserVoice에 상위 10개 요청이 있었습니다.In fact it’s been a top-ten request on UserVoice.

이제 이렇게 하는 것이 가능해졌습니다*(그림 63)* 및 (그림 64)!We’re pleased to announce that this is now possible (Figure 63) and (Figure 64)!

Export build definition
(그림 63) 빌드 정의 내보내기(Figure 63) Export build definition
Import build definition
(그림 64) 빌드 정의 가져오기(Figure 64) Import build definition

빌드 템플릿을 사용하여 확장Extensions with build templates

빌드 템플릿으로 사용자가 빌드 프로세스를 정의하는 기준을 만들 수 있습니다.Build templates let you create a baseline for users to get started with defining their build process. 오늘날 제품 상자에는 많은 제품이 담겨 있으며 계정에 새 제품을 업로드할 수 있지만 확장 작성자가 확장의 일부로 새 템플릿을 포함할 수는 없었습니다.We ship a number of them in the box today and while you could upload new ones to your account, it was never possible for extension authors to include new templates as part of an extension. 이제 확장에 빌드 템플릿을 포함할 수 있습니다.You can now include build templates in your extensions. 예:For example:

{  "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을 참조하세요.For the full example, see https://github.com/Microsoft/vsts-extension-samples/tree/master/fabrikam-build-extension.

이 기능을 사용하여 모든 팀 프로젝트에서 동일한 사용자 지정 템플릿을 제공하고 공유할 수 있습니다.You can use this capability to offer and share the same custom template across all your team projects.

확장의 작업 사용 중단Deprecate a task in an extension

이제 확장의 작업이 더 이상 사용되지 않게 할 수 있습니다.You can now deprecate a task in your extension. 이를 위해서는 작업의 최신 버전에 다음 변수를 추가해야 합니다.To make it work, you must add the following variable to the latest version of your task:

"deprecated": true

사용자가 사용되지 않는 작업을 검색할 경우*(그림 65)*, 이러한 작업을 끝으로 푸시한 후 기본적으로 축소되는 축소 가능한 섹션 아래에 그룹화합니다.When the user searches for deprecated tasks (Figure 65), we push these tasks to the end and group them under a collapsible section that’s collapsed by default. 사용되지 않는 작업이 정의에 이미 사용된 경우, 사용되지 않는 작업의 배지를 표시하여 사용자에게 대체 작업으로 전환할 것을 권장합니다.If a definition is already using a deprecated task, we show a deprecated task badge to encourage users to switch to the replacement.

Deprecated task badge
(그림 65) 사용되지 않는 작업의 배지(Figure 65) Deprecated task badge

작업 설명에서 대체 작업을 언급하여 사용자에게 관련 정보를 제공할 수 있습니다*(그림 66)*.You can help your users learn about the replacement task by mentioning it in the task description (Figure 66). 이 설명은 작업 카탈로그와 기존 빌드/릴리스 정의를 토대로 올바른 방향으로 작업을 사용하도록 지침을 제공합니다.The description will then point folks using the task in the right direction from both the task catalog and the existing build/release definitions.

Deprecated task description
(그림 66) 사용되지 않는 작업 설명(Figure 66) Deprecated task description

적용된 빌드 섹션으로 섹션 가시성 제어Let contributed build sections control section visibility

이전에는 빌드 작업 및 빌드 요약 섹션이 있는 확장을 사용할 경우 해당 빌드에서 빌드 작업을 사용하지 않더라도 빌드 요약 섹션이 표시됩니다.Previously, if you were using an extension that had build tasks and build summary sections, you’d see the build summary section even if you weren’t using the build task in that build. 이제 확장 코드에 다음 줄을 추가하고 해당 값을 true 또는 false로 설정하여 빌드 요약 페이지에 해당 섹션을 숨기거나 표시하도록 선택할 수 있습니다.Now, you can choose to hide or show that section in the build summary page by adding the following line in your extension code and setting the value to true or false:

VSS.getConfiguration().setSectionVisibility("$(publisherId).$(extensionId).$(sectionId)", false);

Microsoft vsts-extension-samples 리포지토리에 포함된 샘플을 참조하세요.View the sample included in the Microsoft vsts-extension-samples repository.

변수 그룹 지원Variable group support

변수 그룹을 릴리스 정의에서 사용할 수 있으며 이제 빌드 정의에서도 사용할 수 있습니다.Variable groups have been available to use in release definitions, and now they are ready to be used in build definitions, too. 변수 그룹 만들기에 대해 자세히 알아보세요.Learn more about creating a variable group. 변수 그룹은 프로젝트 수준 빌드/릴리스 변수빌드 정의의 변수 그룹에 대한 관련 제안에 따라 개발되고 우선 순위가 지정되었습니다.This has been developed and prioritized based on related suggestions for project-level build/release variables and variable groups in build definitions.

Apple 인증서와 같은 보안 파일 사용Work with secure files such as Apple certificates

범용 보안 파일 라이브러리를 추가했습니다*(그림 67)*.We’ve added a general-purpose secure files library (Figure 67).

Secure files library
(그림 67) 보안 파일 라이브러리(Figure 67) Secure files library

보안 파일 라이브러리를 사용하여 인증서 서명, Apple 권한 설정 프로파일, Android 키 저장소 파일 및 SSH 키와 같은 파일을 소스 리포지토리에 커밋할 필요 없이 서버에 저장할 수 있습니다.Use the secure files library to store files such as signing certificates, Apple Provisioning Profiles, Android Keystore files, and SSH keys on the server without needing to commit them to your source repository.

보안 파일의 내용은 암호화되며 빌드 또는 릴리스 프로세스 동안에만 작업에서 참조하는 방식으로 사용할 수 있습니다.The contents of secure files are encrypted and can only be used during build or release processes by referencing them from a task. 보안 파일은 보안 설정에 따라 팀 프로젝트의 여러 빌드 및 릴리스 정의에서 사용할 수 있습니다.Secure files are available across multiple build and release definitions in the team project based on security settings. 보안 파일은 라이브러리 보안 모델을 따릅니다.Secure files follow the Library security model.

이 새로운 기능을 활용하는 다음과 같은 몇 가지 Apple 작업도 추가했습니다.We’ve also added some Apple tasks that leverage this new feature:

빌드 정의 일시 중지Pause build definitions

이제 빌드 정의를 일시 중지하거나 사용하지 않을 수 있습니다.You can now pause or disable build definitions. 빌드 정의를 변경하고 완료될 때까지 모든 새 빌드의 큐를 방지하려는 경우 빌드 정의를 사용하지 않도록 합니다.If you plan to make changes to your build definition and you want to avoid queuing any new builds until you are done, simply disable the build definition. 마찬가지로, 에이전트 컴퓨터를 업그레이드하려는 경우 빌드 정의를 일시 중지하도록 선택할 수 있습니다. 이는 VSTS에서 새 빌드 요청을 여전히 수락하지만 정의를 다시 시작할 때까지 실행하지 않고 큐에 보관하도록 합니다.Similarly, if you plan to upgrade agent machines, you can choose to pause a build definition, which enables VSTS to still accept new build requests but hold them in queue without running until you resume the definition.

작업 입력 유효성 검사 지원Task input validations support

빌드 정의 작업에 매개 변수를 입력하면 경우에 따라 오류가 발생할 수 있습니다.Typing the parameters in build definition tasks can sometimes be error prone. 작업 입력 유효성 검사를 통해 작업 작성자는 적절한 값이 지정되도록 할 수 있습니다.With task input validation, task authors can ensure appropriate values are specified. 유효성 검사 식은 작업 조건에 사용되는 친숙한 식 구문을 따르고 URL, IPV4, 전자 메일, 번호 범위, sha1, 길이 또는 일치를 포함하여 작업 조건에서 지원하는 일반 함수 외에도 지원되는 함수를 사용할 수 있습니다.Validation expressions follow the familiar expression syntax used for task conditions and can use any of the supported functions besides the general functions supported by task conditions, including URL, IPV4, email, number range, sha1, length, or match.

vsts 작업 리포지토리 페이지의 목표 및 사용에 대해 자세히 읽어보세요.Read more about the goals and usage on the vsts-tasks repo page.

새 릴리스 정의 편집기 New Release Definition Editor

빌드 및 릴리스 환경의 지속적인 재정비의 일환으로, 더욱 직관적인 환경을 제공하고, 일부 문제점을 해결하고, 새 기능을 추가할 수 있도록 릴리스 정의 편집기를 혁신했습니다.Continuing on our journey of refreshing the Build and Release experiences, we have re-imagined the release definition editor to provide a more intuitive experience, fix some pain points, and add new capabilities. 새 편집기의 가장 강력한 기능 중 하나는 환경에 대한 배포가 진행되는 방식을 시각화하는 기능입니다.One of the most powerful features of the new editor is its ability to help you visualize how deployments to your environments would progress. 그뿐 아니라 이제 상황에 맞는 승인, 환경 속성 및 배포 설정이 제공되며 이러한 설정을 쉽게 구성할 수 있습니다.In addition to this, approvals, environment properties, and deployment settings are now in-context and easily configurable.

파이프라인의 시각화Visualization of the pipeline

편집기의 파이프라인*(그림 68)*은 릴리스에서 배포가 진행되는 방식에 대한 그래픽 뷰를 제공합니다.The pipeline (Figure 68) in the editor provides a graphical view of how deployments will progress in a release. 아티팩트는 해당 릴리스에서 사용되며 환경에 배포됩니다.The artifacts will be consumed by the release and deployed to the environments. 환경의 레이아웃 및 연결은 각 환경에 대해 정의된 트리거 설정을 반영합니다.The layout and linking of the environments reflects the trigger settings defined for each environment.

Pipeline
(그림 68) 릴리스 파이프라인(Figure 68) Release pipeline
상황에 맞는 구성 UIIn context configuration UI

아티팩트, 릴리스 트리거, 배포 전 및 배포 후 승인, 환경 속성 및 배포 설정은 이제 상황에 맞게 제공되며 쉽게 구성할 수 있습니다*(그림 69)*.Artifacts, release triggers, pre-deployment and post-deployment approvals, environment properties, and deployment settings are now in-context and easily configurable (Figure 69).

Release configuration
(그림 69) 릴리스 구성(Figure 69) Release configuration
배포 템플릿 시작Getting started with deployment templates

모든 기본 제공 배포 템플릿은 사용자가 작업을 심층 연구할 필요 없이 가장 중요한 매개 변수를 지정하여 쉽게 시작할 수 있도록 프로세스 매개 변수로 장착되어 있습니다*(그림 70)*.All in-built deployment templates are equipped with process parameters which makes it easier for users to get started by specifying the most important parameters without needing to go deep into your tasks (Figure 70).

Deployment templates
(그림 70) 배포 템플릿(Figure 70) Deployment templates
릴리스 및 환경 변수의 간편한 관리Simplified management of release and environment variables

목록 보기를 사용하여 신속하게 릴리스 또는 환경 변수를 추가하고 그리드 보기를 사용하여 병렬 범위에서 변수를 비교하고 편집합니다*(그림 71)*.Use the List view to quickly add release or environment variables and the Grid view to compare and edit variables across scopes side-by-side (Figure 71). 또한 필터 및 키워드 검색을 사용하여 두 보기에 사용하는 변수 집합을 관리할 수 있습니다.Additionally, you can use the filter and keyword search to manage the set of variables to work with in both the views.

Simplified management of variables
(그림 71) 변수의 간편한 관리(Figure 71) Simplified management of variables
향상된 작업 및 단계 편집기Improved task and phase editor

새 빌드 정의 편집기의 모든 향상된 기능을 릴리스 정의 편집기에서도 사용할 수 있습니다*(그림 72)*.All the enhancements in the new build definition editor are now available in the release definition editor, as well (Figure 72). 작업을 검색하고 추가 단추를 사용하거나 끌어서 놓기를 사용하여 추가할 수 있습니다.You can search for tasks and add them by either using the Add button or by using drag/drop. 끌어서 놓기를 사용하여 작업 순서를 변경하거나 복제할 수 있습니다.You can reorder or clone tasks using drag/drop.

Task editor
(그림 72) 태스크 편집기(Figure 72) Task editor
변수 그룹, 보존 및 옵션 탭Variable groups, Retention, and Options tabs

이제 옵션 탭에서 변수 그룹에 연결하거나 연결을 끊고*(그림 73)*, 개별 환경에 대한 보존 정책을 설정하고, 릴리스 번호 형식과 같은 릴리스 정의 수준 설정을 수정할 수 있습니다. 작업 탭 내에서 환경을 배포 템플릿으로 저장하고, 환경 수준 사용 권한을 설정하고, 단계 순서를 변경할 수도 있습니다.You can now link/unlink to variable groups (Figure 73), set retention policy for individual environments, and modify release definition-level settings such as release number format from the Options tab. You can also save an environment as a deployment template, set environment level permissions, and re-order phases within the Tasks tab.

Variable groups
(그림 73) 변수 그룹(Figure 73) Variable groups

환경 수준 작업을 사용하여 템플릿으로 저장하고 보안을 설정합니다*(그림 74)*.Use environment level operations to save as template and set security (Figure 74).

Environment menu
(그림 74) 환경 메뉴(Figure 74) Environment menu

자세한 내용은 릴리스 정의 편집기에 대한 설명서를 참조하세요.See the documentation for Release Definition Editor for more information.

배포 그룹을 사용하여 VM 배포 VM Deployment using Deployment Groups

이제 Release Management는 강력한 기본 다중 컴퓨터 배포를 지원합니다.Release Management now supports robust out-of-the-box multi-machine deployment. 이제 전체적으로 응용 프로그램의 고가용성을 보장하면서 여러 컴퓨터에서 배포를 오케스트레이션하고 롤링 업데이트를 수행할 수 있습니다.You can now orchestrate deployments across multiple machines and perform rolling updates while ensuring high availability of the application throughout.

에이전트 기반 배포 기능은 동일한 빌드 및 배포 에이전트에 의존합니다.Agent-based deployment capability relies on the same build and deployment agents. 그러나 빌드 및 배포 에이전트를 에이전트 풀의 프록시 서버 집합에 설치하고 원격 대상 서버로의 배포를 구동하는 현재의 접근 방식과 달리, 대상 서버 각각에 에이전트를 직접 설치하고 해당 서버로의 롤링 배포를 구동합니다.However, unlike the current approach where you install the build and deployment agents on a set of proxy servers in an agent pool and drive deployments to remote target servers, you install the agent on each of your target servers directly and drive rolling deployments to those servers. 대상 컴퓨터에서 전체 작업 카탈로그를 사용할 수 있습니다.You can use the full task catalog on your target machines.

배포 그룹*(그림 75)*은 각각에 에이전트가 설치된 대상(컴퓨터)의 논리적 그룹입니다.A deployment group (Figure 75) is a logical group of targets (machines) with agents installed on each of them. 배포 그룹은 단일 상자 개발, 다중 컴퓨터 QA 및 UAT/프로덕션용 컴퓨터 팜과 같은 실제 환경을 나타냅니다. 또한 실제 환경에 대한 보안 컨텍스트를 지정합니다.Deployment groups represent your physical environments, such as single-box Dev, multi-machine QA, and a farm of machines for UAT/Prod. They also specify the security context for your physical environments.

Deployment groups
(그림 75) 배포 그룹(Figure 75) Deployment groups

이 에이전트를 등록하는 모든 VM에 대해 사용할 수 있습니다.You can use this against any VM that you register our agent with. 또한 VM이 스핀업할 때 에이전트를 자동으로 설치하는 Azure VM 확장을 지원하여 Azure에 더욱 쉽게 등록할 수 있습니다.We’ve also made it very easy to register with Azure with support for an Azure VM extension that auto-installs the agent when the VM spins up. 등록 시 Azure VM의 태그가 자동으로 상속됩니다.We will automatically inherit the tags on the Azure VM when it’s registered.

배포 그룹이 지정되면 해당 배포 그룹에 대해 실행할 작업을 간단히 구성할 수 있습니다*(그림 76)*.Once you have a deployment group, you simply configure what you want us to execute on that deployment group (Figure 76). 태그를 사용하여 어떤 컴퓨터에서 어떤 작업을 실행할지 제어하고 롤아웃의 속도도 제어할 수 있습니다.You can control what gets run on which machines using tags and control how fast or slow the rollout happens.

Configure deployment groups
(그림 76) 배포 그룹 구성(Figure 76) Configure deployment groups

배포를 실행할 때 대상이 되는 전체 컴퓨터 그룹의 진행 상태가 로그에 표시됩니다*(그림 77)*.When the deployment is run, the logs show the progression across the entire group of machines you are targeting (Figure 77).

Deployment group progress
(그림 77) 배포 그룹 진행률(Figure 77) Deployment group progress

이 기능은 이제 Release Management에 통합되었으며This feature is now an integrated part of Release Management. 추가 라이선스는 필요하지 않습니다.No additional licenses are required.

향상된 배포 그룹 UIImproved Deployment Groups UI

빌드릴리스 환경의 지속적인 재정비의 일환으로,더욱 명확하고 직관적인 환경을 만들도록 배포 그룹 페이지를 혁신했습니다*(그림 78)*.Continuing our journey of refreshing the Build and Release experiences, we have now re-imagined our deployment groups pages to make it a more clean and intuitive experience (Figure 78). 시작 페이지의 배포 그룹에서 대상의 상태를 볼 수 있습니다.From the landing page, you can view the health of the targets in the deployment group. 개별 배포 그룹에 대한 보안을 관리하거나 배포 그룹에 걸쳐 기본 사용 권한을 설정할 수 있습니다.You can also manage security for an individual deployment group, or set default permissions across deployment groups.

Deployment groups UI
(그림 78) 배포 그룹 UI(Figure 78) Deployment groups UI

배포 그룹 내 대상의 경우 요약, 최근 배포 및 대상의 기능을 볼 수 있습니다*(그림 79)*.For a target within a deployment group, you can view a summary, recent deployments, and the target’s capabilities (Figure 79). 대상에 태그를 설정할 수 있으며 각 대상에서 실행되는 작업을 제어할 수 있습니다.You can set tags on the target, and control what is run on each target. 이후 릴리스에서 배포 그룹에 대한 필터 지원을 추가할 예정입니다.We will be adding filter support for deployment groups in upcoming releases.

Deployment groups UI tags
(그림 79) 배포 그룹 UI 태그(Figure 79) Deployment groups UI tags

작업 그룹 참조Task group references

작업 그룹을 사용하여 빌드 및 릴리스 정의에 추가할 수 있는 작업 집합을 정의할 수 있습니다*(그림 80).Task groups let you define a set of tasks that you can add to your build or release definitions (Figure 80). 여러 빌드 또는 릴리스에서 동일한 작업 그룹을 사용해야 할 경우에 유용합니다.This is handy if you need to use the same grouping of tasks in multiple builds or releases. 작업 그룹의 소비자를 좀 더 쉽게 추적할 수 있도록 빌드 정의, 릴리스 정의 및 작업 그룹을 참조하는 작업 그룹에 대한 뷰를 제공합니다(그림 79)*.To help you track the consumers of a task group, you now have a view into the build definitions, release definitions, and task groups that reference your task group (Figure 79).

Task group references
(그림 80) 작업 그룹 참조(Figure 80) Task group references

아직 참조되는 작업 그룹을 삭제하려고 하면 경고가 표시되고 이 페이지에 대한 링크가 표시됩니다.When you try to delete a task group that’s still referenced, we warn you and give you a link to this page.

작업 그룹 버전 관리Task group versioning

작업 그룹을 변경할 경우 해당 작업 그룹을 사용하는 모든 정의에 영향을 미칠 수 있으므로 위험하다고 생각될 수 있습니다.When making changes to task groups, it can feel risky because the change is effective to all definitions that use the task group. 작업 그룹 버전 관리를 사용하면 전환 준비가 될 때까지 가장 중요한 정의에 대한 안전한 버전을 제공하면서 작업 그룹 버전의 초안을 만들고 미리 볼 수 있습니다.With task group versioning, now you can draft and preview task group versions while still offering stable versions to your most important definitions until you are ready to switch. 초안 작성 및 반복 작업을 어느 정도 진행한 후에는 안전한 버전을 게시할 수 있으며, 게시하는 동안 변경이 진행될 경우 해당 작업 그룹을 미리 보기(새로운 주 버전)로 게시하도록 선택할 수 있습니다.After some drafting and iteration, you can publish a stable version and, while publishing, if the changes are breaking in nature, you can choose to publish the task group as preview (a new major version). 또는 업데이트된 안전한 버전으로서 직접 게시할 수 있습니다*(그림 81)*.Alternatively, you can publish it directly as an updated stable version (Figure 81).

작업 그룹의 새로운 주(또는 미리 보기) 버전을 사용할 수 있으면 정의 편집기에 새 버전이 있다는 알림이 표시됩니다.When a new major (or preview) version of the task group is available, the definition editor will advise you that there is a new version. 해당 주 버전이 미리 보기인 경우 “사용해 보기” 메시지가 표시됩니다.If that major version is preview, you even see a “try it out” message. 미리 보기에서 가져온 작업 그룹인 경우 해당 작업 그룹을 사용하는 정의가 자동으로 업데이트되며 주 채널로 제공됩니다*(그림 82)*.When the task group comes out of preview, definitions using it will be auto-updated, sliding along that major channel (Figure 82).

Save as draft
(그림 81) 초안으로 작업 그룹 저장(Figure 81) Save task group as draft
Publish task group as preview
(그림 82) 작업 그룹을 미리 보기로 게시(Figure 82) Publish task group as preview

작업 그룹 가져오기 및 내보내기Task group import and export

작업 그룹이 프로젝트 내에서 재사용되도록 설정되어 있으나 다른 프로젝트 및 계정 간에 작업 그룹을 다시 만드는 작업은 까다로운 일일 수 있습니다.Although task groups have enabled reuse within a project, we know that recreating a task group across projects and accounts can be painful. 작업 그룹 가져오기/내보내기*(그림 83)*를 사용하면 릴리스 정의의 경우처럼 JSON 파일로 내보낸 후 원하는 위치로 가져올 수 있습니다.With task group import/export (Figure 83), as we’ve done for release definitions, now you can export as a JSON file and import where you want it. 또한 중첩된 작업 그룹도 사용하도록 설정할 수 있습니다. 이 작업 그룹은 내보낼 때 맨 먼저 확장됩니다.We’ve also enabled nested task groups, which first expand when they are exported.

Export task group
(그림 83) 작업 그룹 내보내기(Figure 83) Export task group

서버 쪽(에이전트 없는) 작업에서 다중 구성 지원Multi Configuration support in Server Side (Agentless) tasks

서버 쪽(에이전트 없는) 작업에 대해 변수 승수를 지정하여*(그림 84)* 병렬로 실행되는 여러 구성에서 동일한 작업 집합을 한 단계로 실행할 수 있습니다.By specifying variable multipliers for server side (agentless) tasks (Figure 84), you can now run the same set of tasks in a phase on multiple configurations, which run in parallel.

Multi configuration of agentless tasks
(그림 84) 에이전트 없는 작업의 여러 구성(Figure 84) Multi configuration of agentless tasks

수동 개입 작업의 변수 지원Variables Support in Manual Intervention task

수동 개입 작업*(그림 85)은 이제 작업이 실행될 때 사용자에게 표시되는 명령 텍스트 내에서 변수를 사용할 수 있도록 지원합니다. 이 시점에서 사용자는 릴리스 프로세스의 실행을 계속하거나 거부할 수 있습니다.The Manual Intervention task (Figure 85) now supports the use of variables within the instruction text shown to users when the task runs, at the point where the user can resume execution of the release process or reject it. 릴리스에서 정의되고 사용 가능한 모든 변수가 포함되며 해당 값은 사용자에게 전송되는 전자 메일 뿐만 아니라 알림에서도 사용됩니다(그림 86)*.Any variables defined and available in the release can be included, and the values will be used in the notifications as well as in the email sent to users (Figure 86).

Manual intervention task
(그림 85) 수동 개입 작업(Figure 85) Manual intervention task
Manual intevention pending dialog
(그림 86) 수동 개입 보류 대화 상자(Figure 86) Manual intervention pending dialog

소스 분기에 따라 환경에 대한 릴리스 제어Control releases to an environment based on the source branch

새 릴리스가 만들어질 때, 일반적으로 소스 빌드가 성공적으로 진행된 이후에 자동으로 배포를 트리거하도록 릴리스 정의를 구성할 수 있습니다.A release definition can be configured to trigger a deployment automatically when a new release is created, typically after a build of the source succeeds. 그러나 성공적으로 수행된 빌드를 무조건 배포하기보다 소스의 특정 분기에서 가져온 빌드만 배포하고 싶을 수 있습니다.However, you may want to deploy only builds from specific branches of the source, rather than when any build succeeds.

예를 들어, 개발 및 테스트 환경에는 모든 빌드를 배포하고 프로덕션 환경에는 특정 빌드만 배포하려고 할 수 있습니다.For example, you may want all builds to be deployed to Dev and Test environments, but only specific builds deployed to Production. 이전에는 이 목적으로 개발 및 테스트 환경용 1개, 프로덕션 환경용 1개씩 2개의 릴리스 파이프라인을 유지해야 했습니다.Previously you were required to maintain two release pipelines for this purpose, one for the Dev and Test environments and another for the Production environment.

이제 Release Management를 사용하여 각 환경에 대해 아티팩트 필터를 사용할 수 있습니다.Release Management now supports the use of artifact filters for each environment. 즉, 배포 트리거 조건(예: 빌드 성공 및 새 릴리스 생성)이 충족될 때 각 환경에 배포되는 릴리스를 지정할 수 있습니다.This means you can specify the releases that will be deployed to each environment when the deployment trigger conditions (such as a build succeeding and creating a new release) are met. 환경 배포 조건 대화 상자의 트리거 섹션에서*(그림 87)* 해당 환경에 대한 새 배포를 트리거하는 아티팩트 조건(예: 빌드에 대한 소스 분기 및 태그)을 선택합니다.In the Trigger section of the environment Deployment conditions dialog (Figure 87), select the artifact conditions such as the source branch and tags for builds that will trigger a new deployment to that environment.

Deployment conditions dialog
(그림 87) 배포 조건 대화 상자(Figure 87) Deployment conditions dialog

또한 릴리스 요약 페이지에는*(그림 88)* “시작되지 않은” 모든 배포가 해당 상태를 나타내는 이유를 제공하고 배포를 시작할 방식 또는 시기를 제안하는 팝업 팁이 포함되어 있습니다.In addition, the Release Summary page (Figure 88) now contains a pop-up tip that indicates the reason for all “not started” deployments to be in that state, and suggests how or when the deployment will start.

Release summary tip
(그림 88) 릴리스 요약 팁(Figure 88) Release summary tip

아티팩트 소스로서 Git 리포지토리에 대해 릴리스 트리거 제공Release Triggers for Git repositories as an artifact source

이제 Release Management는 동일한 계정의 모든 팀 프로젝트에 포함된 릴리스 정의에 연결된 Git 리포지토리에 대해 연속 배포 트리거를 구성할 수 있도록 지원합니다*(그림 89)*.Release Management now supports configuring a continuous deployment trigger (Figure 89) for Git repositories linked to a release definition in any of the team projects in the same account. 이를 통해 리포지토리에 대해 새 커밋이 수행될 때 릴리스가 자동으로 트리거되도록 할 수 있습니다.This lets you trigger a release automatically when a new commit is made to the repository. 또한 커밋이 릴리스를 트리거하는 Git 리포지토리의 분기를 지정할 수 있습니다.You can also specify a branch in the Git repository for which commits will trigger a release.

Release triggers
(그림 89) 릴리스 트리거(Figure 89) Release triggers

릴리스 트리거: Git 리포지토리로 푸시되는 변경 내용에 대한 연속 배포Release Triggers: Continuous deployment for changes pushed to a Git repository

Release Management는 빌드가 완료될 때 연속 배포를 구성하는 기능을 항상 제공해왔습니다.Release Management has always provided the capability to configure continuous deployment when a build completes. 그러나 이제 Git 푸시에 대해서도 연속 배포를 구성할 수 있습니다.However, now you can also configure continuous deployment on Git Push. 즉, GitHub 및 Team Foundation Git 리포지토리를 아티팩트 소스로서 릴리스 정의에 연결한 다음, 빌드에서 생성되지 않아 연속 배포를 위해 빌드 작업이 필요하지 않은 Node.JS 및 PHP와 같은 응용 프로그램에 대해 자동으로 릴리스를 트리거할 수 있습니다.This means that you can link GitHub and Team Foundation Git repositories as artifact sources to a release definition, and then trigger releases automatically for applications such as Node.JS and PHP that are not generated from a build and so do not need a build action for continuous deployment.

환경 트리거의 분기 필터Branch filters in environment triggers

이제 새 릴리스 정의 편집기에서 특정 환경에 대한 아티팩트 조건을 지정할 수 있습니다.In the new release definition editor you can now specify artifact conditions for a particular environment. 이러한 아티팩트 조건을 사용하여 특정 환경에 배포되어야 할 아티팩트에 대한 보다 세부적인 제어를 갖습니다.Using these artifact conditions, you will have more granular control on which artifacts should be deployed to a specific environment. 예를 들어 프로덕션 환경의 경우 마스터 분기에서만 생성된 빌드가 배포되었는지 확인하려고 할 수 있습니다.For example, for a production environment you may want to make sure that builds generated only from the master branch are deployed. 이 필터는 이 조건을 충족해야 하는 것으로 예상하는 모든 아티팩트에 대해 설정되어야 합니다.This filter needs to be set for all artifacts that you think should meet this criterion.

릴리스 정의에 연결된 각 아티팩트에 대해 여러 필터를 추가할 수도 있습니다*(그림 90)*.You can also add multiple filters for each artifact that is linked to the release definition (Figure 90). 모든 아티팩트 조건이 성공적으로 충족되는 경우에만 이 환경에 배포가 트리거됩니다.Deployment will be triggered to this environment only if all the artifact conditions are successfully met.

Branch filters
(그림 90) 분기 필터(Figure 90) Branch filters

향상된 서버 쪽 작업 기능Enhancements to server-side tasks

서버 쪽 작업(서버 단계 내에서 실행되는 작업)이 2가지 측면에서 개선되었습니다.We have made two enhancements to server-side tasks (tasks that run within a server phase).

제네릭 HTTP REST API*(그림 91)*를 자동화된 파이프라인의 일부로 호출하는 데 사용할 수 있는 새 작업을 추가했습니다.We have added a new task that can be used to invoke any generic HTTP REST API (Figure 91) as part of the automated pipeline. 예를 들어 Azure 함수를 포함하는 특정 처리를 호출하고 완료될 때까지 기다리는 데 이 작업을 사용할 수 있습니다.For example, it can be used to invoke specific processing with an Azure function, and wait for it to be completed.

REST API task
(그림 91) REST API 작업(Figure 91) REST API task

또한 모든 서버 쪽 작업에 제어 옵션(그림 92) 섹션을 추가했습니다.We have also added a Control options (Figure 92) section to all server-side tasks. 이제 작업 동작에는 사용, 오류 발생 시 계속, 항상 실행시간 제한 옵션 설정이 포함됩니다.Task behavior now includes setting the Enabled, Continue on error, Always run, and Timeout options.

Task control options
(그림 92) 작업 제어 옵션(Figure 92) Task control options

코드 허브의 릴리스 상태 배지Release status badge in Code hub

현재, 고객 프로덕션 환경으로 커밋을 배포할지 여부를 알고 싶은 경우 먼저 해당 커밋을 사용할 빌드를 식별하고 이 빌드가 배포되는 모든 릴리스 환경을 확인해야 합니다.Today, if you want to know whether a commit is deployed to your customer production environment, you first identify which build consumes the commit and then check all the release environments where this build is deployed. 이제 코드가 배포되는 환경 목록을 보여 주는 코드 허브 상태 배지에 배포 상태를 통합할 수 있으므로 이러한 확인이 훨씬 쉬워졌습니다.Now this experience is much easier with the integration of the deployment status in the Code hub status badge to show the list of environments that your code is deployed to. 모든 배포에서 배포에 속하는 최신 커밋에 상태가 게시됩니다.For every deployment, status is posted to the latest commit that was part of the deployment. 커밋이 여러 릴리스 정의(여러 환경 포함)에 배포되면 배지에 각각에 대한 항목이 표시되며 각 환경에 대한 상태가 표시됩니다*(그림 93)*.If a commit is deployed to multiple release definitions (with multiple environments) then each has an entry in the badge, with status shown for each environment (Figure 93). 이를 통해 배포에 대한 코드 커밋을 쉽게 추적할 수 있습니다.This improves the traceability of code commit to deployments.

Release status badge
(그림 93) 릴리스 상태 배지(Figure 93) Release status badge

기본적으로 릴리스 정의를 만들 때 모든 환경에 대한 배포 상태가 게시됩니다.By default, when you create a release definition, deployment status is posted for all environments. 그러나 상태 배지에 배포 상태가 표시되어야 하는 환경을 선택적으로 표시할 수 있습니다(예: 프로덕션 환경만 표시)(그림 94).However, you can selectively choose the environments whose deployment status should be displayed in the status badge (e.g. only show production environments) (Figure 94).

Deployment options dialog
(그림 94) 배포 옵션 대화 상자(Figure 94) Deployment options dialog

아티팩트를 추가할 때 향상된 빌드 정의 메뉴 기능Enhancements to Build definition menu when adding artifacts

이제 릴리스 정의에 빌드 아티팩트를 추가할 때 폴더 조직 정보를 포함하는 정의를 볼 수 있으며 원하는 정의를 간편하게 선택할 수 있습니다*(그림 95)*.When adding build artifacts to a release definition, you can now view the definitions with their folder organization information and simplify choosing the desired definition (Figure 95). 따라서 다른 폴더에 있는 같은 이름의 빌드 정의를 쉽게 구분할 수 있습니다.This makes it easy to differentiate the same build definition name but in different folders.

Add artifact
(그림 95) 아티팩트 추가(Figure 95) Add artifact

정의 목록은 필터 용어를 포함하는 정의에 따라 필터링됩니다.The list of definitions is filtered based on those that contain the filter term.

릴리스 정의를 이전 버전으로 되돌리기Revert your release definition to older version

현재, 릴리스 정의가 업데이트될 경우 이전 버전으로 직접 되돌릴 수 없습니다.Today, if a release definition is updated, you can’t directly revert to a previous version. 유일한 방법은 릴리스 정의 기록을 조회하여 변경된 차이점을 찾아낸 다음 릴리스 정의를 수동으로 편집하는 것입니다.The only way is to look into the release definition history to find the diff of the changes, and then manually edit the release definition. 이제 정의 되돌리기 기능을 사용하여*(그림 96)* 릴리스 정의 기록 탭에서 릴리스 정의를 선택한 후 이전 버전의 릴리스 정의로 되돌릴 수 있습니다.Now, using the Revert Definition feature (Figure 96), you can choose, and revert back to any older version of a release definition from the release definition History tab.

Revert release definition
(그림 96) 릴리스 정의 되돌리기(Figure 96) Revert release definition

릴리스에 대해 개인 설정된 알림Personalized notifications for releases

릴리스 알림은 이제 VSTS 알림 설정 환경과 통합됩니다.Release notifications are now integrated with the VSTS notification settings experience. 이러한 관리 릴리스는 이제 보류 중인 작업(승인 또는 수동 개입) 및 중요한 배포 오류를 자동으로 알립니다.Those managing releases are now automatically notified of pending actions (approvals or manual interventions) and important deployment failures. 프로필 메뉴 아래의 알림 설정으로 이동하고 릴리스 구독을 꺼서 이러한 알림을 끌 수 있습니다.You can turn off these notifications by navigating to the Notification settings under the profile menu and switching off Release Subscriptions. 사용자 지정 구독을 만들어 추가 알림에 대해 구독할 수도 있습니다.You can also subscribe to additional notifications by creating custom subscriptions. 관리자는 계정 설정 아래의 알림 설정에서 팀 및 그룹에 대한 구독을 제어할 수 있습니다.Admins can control subscriptions for teams and groups from the Notification settings under Team and Account settings.

릴리스 정의 작성자는 승인 및 배포 완료에 대해 더 이상 수동으로 전자 메일을 보낼 필요가 없습니다.Release definition authors will no longer need to manually send emails for approvals and deployment completions.

이 기능은 릴리스에 대해 여러 이해 관계자가 있는 큰 계정과 알림을 받기 원하는 승인자, 릴리스 작성자 및 환경 소유자 이외의 사람에게 특히 유용합니다*(그림 97)*.This is especially useful for large accounts that have multiple stakeholders for releases, and for those other than the approver, release creator, and environment owner that might want to be notified (Figure 97).

Release notifications
(그림 97) 릴리스 알림(Figure 97) Release notifications

자세한 내용은 릴리스 알림 관리에 대한 게시물을 참조하세요.See the post for managing release notifications for more information.

테스트 Testing

Microsoft Test Manager의 랩 센터 및 자동화된 테스트 흐름에 대한 지원 제거 Removing support for Lab Center and automated testing flows in Microsoft Test Manager

빌드 및 릴리스 관리가 발전하면서 XAML 빌드는 TFS 2018에서 더 이상 지원되지 않으며 TFS에서 MTM(Microsoft Test Manager)을 사용하기 위해 지원을 업데이트할 예정입니다.With the evolution of Build and Release Management, XAML builds are no longer supported in TFS 2018 and consequently we are updating support for using Microsoft Test Manager (MTM) with TFS. MTM의 테스트 센터/랩 센터를 자동 테스트에 사용하는 것도 TFS 2018부터 TFS에서 더 이상 지원되지 않습니다.Using Test Center/Lab Center in MTM for automated testing is no longer supported by TFS, starting with TFS 2018. XAML 빌드 및 랩 센터에서 마이그레이션할 준비가 되지 않은 경우 TFS 2018로 업그레이드하지 않도록 합니다.If you are not ready to migrate away from XAML builds and Lab Center, you should not upgrade to TFS 2018.

아래와 같이 TFS 2018로 업그레이드할 때 미치는 영향을 확인하세요.Please see the impact of upgrading to TFS 2018 below:

랩 센터:Lab Center:
  • 더 이상 지원되지 않습니다.No longer supported:
    • 랩 환경을 만들고 관리하기 위해 TFS에 Test Controller를 등록할 수 없습니다.Test Controllers cannot be registered with TFS for creating and managing Lab environments.
    • TFS에 등록된 모든 기존 Test Controller는 오프라인 상태가 되며 기존 랩 환경은 ‘준비되지 않음’으로 표시됩니다.Any existing Test Controllers registered with TFS will go offline and existing Lab environments will appear as 'Not Ready'.
  • 권장 대안:Recommended alternative:
자동화된 테스트:Automated Testing:
수동 테스트:Manual Testing:
  • 모든 수동 테스트 시나리오는 계속 완벽하게 지원됩니다.All manual testing scenarios continue to be fully supported. TFS 2018에서 MTM을 사용하여 수동 테스트를 실행할 수 있지만 수동 테스트를 실행하는 데 랩 환경은 사용할 수 없습니다.While manual tests can be run using MTM with TFS 2018, Lab Environments cannot be used to run manual tests.
  • 모든 수동 테스트 시나리오에서는 TFS 웹 액세스의 테스트 허브를 사용할 것을 강력히 권장합니다.For all manual testing scenarios, we strongly recommend using the Test hub in TFS web access.

예비 테스트를 수행하는 팀에서 얻은 의견에 따라, 테스트 및 피드백 확장에서 얻은 버그, 작업 또는 테스트 사례를 정리하면서 추적 가능 링크를 개선하고 있습니다.Based on the feedback we received from teams doing exploratory testing, we are improving traceability links while filing bugs, tasks, or test cases from the Test & Feedback extension. 이제 요구 사항을 확인하면서 만드는 버그 및 작업은 팀 기본값이 아닌 요구 사항과 같은 영역 경로 및 반복으로 생성됩니다.Bugs and tasks created while exploring requirements will now be created with the same area path and iteration as that of the requirement instead of team defaults. 이제 요구 사항을 확인하면서 만드는 테스트 사례는 부모 <-> 자식 링크가 아닌 테스트 <-> 테스트한 사람 링크에 연결되므로 만드는 테스트 사례가 요구 사항 기반의 테스트 도구 모음에 자동으로 추가됩니다.Test cases created while exploring requirements will now be linked with a Tests <-> Tested By link instead of the Parent <-> Child link so that the test cases you create are automatically added to requirement based test suites. 마지막으로 요구 사항을 특별히 확인하지 않으면서 만드는 작업 항목은 현재 반복 대신 팀의 기본 반복에 정리되므로 스프린트 계획이 완료된 후에는 새 작업 항목이 현재 반복에 포함되지 않습니다.Finally, work items created while not specifically exploring any requirement will be filed in the team’s default iteration instead of the current iteration so that no new work items come into the current iteration after the sprint planning is complete.

테스트 허브의 테스트 계획 및 테스트 도구 모음에 제공되는 테스트 사례 작업 항목용 필터Filters for Test Case work items in Test Plans and Suites in Test Hub

테스트 필드(예: 결과, 구성테스터) 외에도 테스트 사례 작업 항목 필드(예: 제목, 상태할당 대상)에 대해서도 필터링할 수 있습니다*(그림 98)*.In addition to the filters on Test fields like Outcome, Configuration, and Tester, you can now filter on Test Case work item fields like Title, State, and Assigned To (Figure 98).

Test case filters
(그림 98) 테스트 사례 필터(Figure 98) Test case filters

릴리스 환경 및 테스트 실행에 대한 테스트 추세 차트Test trend charts for Release Environments and Test Runs

테스트 결과 추세 위젯에 릴리스 환경에 대한 지원을 추가하고 있으므로*(그림 99)* VSTS 대시보드에서 테스트 환경의 상태를 추적할 수 있습니다.We are adding support for Release Environments in the Test Result Trend widget (Figure 99) so that you can track status of test environments on VSTS dashboards. 빌드에서 테스트 결과에 대해 수행하는 것과 같은 방식으로, 이제 릴리스 환경에 대한 테스트 통과 비율, 총 테스트 수, 통과 또는 실패한 테스트, 테스트 기간을 보여 주는 추세 차트를 만들 수 있습니다.Like the way you to do for test results in Build, you can now create trend charts showing test pass rate, count of total, passed or failed tests, and test duration for Release Environments. 테스트 실행 제목 필터를 사용하여 환경 내의 특정 테스트 실행으로 차트를 필터링할 수도 있습니다.You can also filter the charts to a specific test run within an environment with the Test Run title filter.

Test trend chart
(그림 99) 테스트 추세 차트(Figure 99) Test trend chart

테스트 실행 및 테스트 결과 주석에 대한 Markdown 형식 지원Markdown formatting support for Test Run and Test Result comments

Markdown 구문을 사용하여 테스트 실행테스트 결과 주석의 형식을 지정할 수 있습니다.We are adding support for formatting Test Run and Test Result comments with markdown syntax. 이 기능을 사용하여 주석에서 형식이 지정된 텍스트를 만들거나 URL에 대한 빠른 링크를 만들 수 있습니다.You can use this feature to create formatted text or quick links to URLs in your comments. 테스트 결과 주석은 업데이트 분석을 사용하여 결과 요약 페이지에서 업데이트할 수 있고, 테스트 실행 주석은 테스트 허브의 업데이트 주석을 사용하여 실행 요약 페이지에서 업데이트할 수 있습니다.You can update Test Result comments in the Result Summary page with Update analysis and Test Run comments in the Run Summary page with Update comments in Test hub.

빌드 또는 릴리스 요약 페이지나 테스트 허브에서 테스트 결과를 분석하는 동안 기존 버그를 실패한 테스트에 연결할 수 있습니다.While analyzing the test result in the Build or Release summary page or in the Test hub, you can now associate an existing bug to a failed test. 이 기능은 버그가 이미 보고된 알려진 원인으로 인해 테스트가 실패한 경우 유용합니다.This is helpful when a test is failing for a known reason that has a bug already filed.

테스트 실행 및 테스트 결과에 첨부 파일 업로드Upload attachments to test runs and test results

이제 추가 정보로 테스트 실행 또는 테스트 결과에 스크린샷과 로그 파일과 같은 파일을 첨부할 수 있습니다.You can now attach files such as screenshots and log files to test runs or test results as additional information. 이 시점까지 이 기능은 VSTS/TFS 및 MTM 클라이언트에서 테스트 허브 간 컨텍스트를 전환하도록 강요하는 MTM(Microsoft Test Manager) 클라이언트를 통해서만 사용할 수 있었습니다.Up to this point, this capability was only available through the Microsoft Test Manager (MTM) client, forcing you to switch context between the Test hub in VSTS/TFS and the MTM client.

테스트 일괄 처리Test batching

빌드/릴리스 관리의 Visual Studio 테스트 작업에서 테스트가 효율적인 실행을 위해 그룹화(일괄 처리)되어야 하는 방식을 제어하는 데 옵션을 사용할 수 있습니다.In the Visual Studio test task in Build/Release management, options are available to control how tests should be grouped (batched) for efficient execution. 두 가지 방법으로 테스트를 그룹화할 수 있습니다.Tests can be grouped in two ways:

  1. 실행에 참여하는 테스트 에이전트의 수에 따라 테스트를 지정된 크기의 일괄 처리 수로 단순히 그룹화합니다.Based on the number of tests and agents participating in the run, which simply groups tests into a number of batches of a specified size.
  2. 과거 테스트의 실행 시간을 기반으로 테스트의 일괄 처리를 만드는 과거 실행 시간을 각 일괄 처리에 거의 동일한 실행 시간이 있다고 간주합니다*(그림 100)*.Based on past running time of tests, which considers past running time to create batches of tests such that each batch has approximately equal running time (Figure 100). 긴 테스트 실행은 별도 일괄 처리에 속할 수 있지만 빠른 테스트 실행은 함께 일괄 처리됩니다.Quick running tests get batched together while longer running tests may belong to a separate batch. 이 옵션은 총 테스트 시간을 최소한으로 줄이기 위해 여러 에이전트 단계 설정으로 구성될 수 있습니다.This option can be combined with the multi-agent phase setting to reduce the total test time to a minimum.
Test batching
(그림 100) 테스트 일괄 처리(Figure 100) Test batching

VSTest 작업을 사용하여 웹 테스트 실행Run webtests using the VSTest task

Visual Studio 테스트 작업을 사용하여 웹 성능 테스트라고도 알려진 웹 테스트를 이제 CI/CD 파이프라인에서 실행할 수 있습니다.Using the Visual Studio test task, webtests, also known as web performance tests, can now be run in the CI/CD pipeline. 테스트를 작업 어셈블리 입력에서 실행하도록 지정하여 웹 테스트를 실행할 수 있습니다.Webtests can be run by specifying the tests to run in the task assembly input. 웹 테스트에 연결된 "관련된 자동화"가 있는 테스트 사례 작업 항목은 작업에서 테스트 계획/테스트 도구 모음을 선택하여 실행할 수도 있습니다*(그림 101)*.Any test case work item that has an “associated automation” linked to a webtest, can also be run by selecting the test plan/test suite in the task (Figure 101).

Test selection
(그림 101) 테스트 선택(Figure 101) Test selection

웹 테스트 결과를 테스트 결과에 대한 첨부 파일로 사용할 수 있습니다*(그림 102)*.Webtest results will be available as an attachment to the test result (Figure 102). Visual Studio에서 오프라인 분석을 위해 다운로드할 수 있습니다.This can be downloaded for offline analysis in Visual Studio.

Test summary
(그림 102) 테스트 요약(Figure 102) Test summary

이 기능은 Visual Studio 테스트 플랫폼의 변경 내용에 따라 달라지며 빌드/릴리스 에이전트에 Visual Studio 2017 업데이트 4를 설치해야 합니다.This capability is dependent on changes in the Visual Studio test platform and requires that Visual Studio 2017 Update 4 be installed on the build/release agent. 이전 버전의 Visual Studio를 사용하여 웹 테스트를 실행할 수 없습니다.Webtests cannot be run using prior versions of Visual Studio.

마찬가지로, 기능 테스트 실행 작업을 사용하여 웹 테스트를 실행할 수 있습니다.Similarly, webtests can be run using the Run Functional Test task. 이 기능은 Visual Studio 2017 업데이트 5에서 사용할 수 있는 테스트 에이전트의 변경 내용에 따라 달라집니다.This capability is dependent on changes in the Test Agent, that will be available with the Visual Studio 2017 Update 5.

이 기능을 부하 테스트와 함께 사용할 수 있는 방법의 예제로 Visual Studio 및 VSTS 빠른 시작을 사용하여 클라우드에서 앱 부하 테스트를 참조하세요.See the Load test your app in the cloud using Visual Studio and VSTS quickstart as an example of how you can use this together with load testing.

테스트 계획 및 테스트 도구 모음에 대한 차트 위젯Chart widget for test plans and test suites

이전에 테스트 허브에서 테스트 계획 및 도구 모음에 대한 차트를 만들고 대시보드에 고정할 수 있었습니다.Previously, you could create charts for test plans and suites in Test hub and pin them to dashboard. 이제 대시보드의 위젯 카탈로그에서 테스트 계획 및 도구 모음에 대한 차트를 만들 수 있도록 하는 위젯을 추가했습니다.We have now added a widget that enables creating charts for test plans and suites from the widget catalog on the dashboard. 테스트 작성 상태 또는 테스트 실행 상태에 대한 차트를 만들 수 있습니다.You can create charts for test authoring status or test execution status. 또한 위젯에서 차트를 추가하여 차트에 표시할 데이터가 많은 경우 더 큰 차트를 만들 수 있습니다*(그림 103)*.Moreover, adding charts from the widget allows you to create larger charts when you have more data to be shown on a chart (Figure 103).

Chart widget
(그림 103) 차트 위젯(Figure 103) Chart widget

수동 테스트를 위해 Chrome 브라우저를 사용하여 데스크톱 앱에 대한 스크린샷 및 주석 지원Screenshot and annotation support for desktop apps with Chrome browser for manual tests

수동 테스트에서 상위 제안 중 하나에 대해 테스트 허브의 웹 Test Runner에서 데스크톱 응용 프로그램의 스크린샷을 캡처하는 지원을 추가합니다.We are adding support for one of the top suggestions from manual testing - capturing screenshots of desktop applications from the Web Test Runner in Test hub. 지금까지 Microsoft Test ManagerTest Runner를 사용하여 데스크톱 앱의 스크린샷을 캡처해야 했습니다.Until now, you had to use Test Runner in Microsoft Test Manager to capture screenshots of desktop apps. 이 기능을 사용하기 위해 테스트 및 피드백 확장을 설치해야 합니다.You need to install the Test & Feedback extension to use this functionality. Chrome 브라우저에 대한 지원을 공개하며 Firefox에서 그 후에 즉시 따를 예정입니다.We are rolling out support for the Chrome browser, and Firefox will follow shortly thereafter.

SharePoint에 대한 TFS 확장 중단 Discontinuing TFS Extension for SharePoint

TFS 2018 이상 버전은 SharePoint에 대한 TFS 확장을 더 이상 지원하지 않습니다.TFS 2018 and later versions will no longer support the TFS Extension for SharePoint. 또한 TFS 서버와 SharePoint 서버 간에 통합을 구성하는 데 사용되는 화면이 Team Foundation 관리 콘솔에서 제거되었습니다.Additionally, the screens used to configure integration between a TFS Server and a SharePoint server have been removed from the Team Foundation Administration Console.

참고

SharePoint와 통합하도록 구성된 이전 버전에서 TFS 2018로 업그레이드하는 경우 업그레이드 후 SharePoint 통합을 사용하지 않도록 설정해야 합니다. 그렇지 않으면 TFS SharePoint 사이트에서 로드에 실패합니다.If you are upgrading to TFS 2018 from a previous version configured to integrate with SharePoint, you will need to disable the SharePoint integration after upgrade, or your TFS SharePoint sites will fail to load.

SharePoint 서버에서 통합을 사용하지 않도록 할 수 있는 솔루션을 만들었습니다.We have created a solution that allows you to disable integration on the SharePoint server. 자세한 내용은 TFS/SharePoint 통합의 미래에 대한 게시물을 참조하세요.For more information, please see the post on the future of our TFS/SharePoint Integration.

단체방 중단 Discontinuing Team Rooms

최신 개발 팀은 공동 작업에 대한 업무가 가중되어 있습니다.Modern development teams heavily depend on collaboration. 사용자는 작업(알림)을 모니터링하고 이에 대해 대화(채팅)할 장소를 원하며 필요합니다.People want (and need) a place to monitor activity (notifications) and talk about it (chat). 몇 년 전에 이러한 추세를 인식하고 이러한 시나리오를 지원하기 위한 단체방을 빌드했습니다.A few years back, we recognized this trend and set out to build the Team Room to support these scenarios. 그 이후에 공동 작업을 위한 다양한 솔루션이 등장했습니다.Since that time, we have seen more solutions to collaborate emerge in the market. 가장 주목할 만한 것은 Slack의 등장입니다.Most notably, the rise of Slack. 또 좀 더 최근에는 Microsoft Teams가 발표되었습니다.And more recently, the announcement of Microsoft Teams.

TFS 및 Visual Studio Team Services와 원활하게 통합되는 다양한 솔루션이 제공되면서 TFS 2018과 Visual Studio Team Services에서 단체방 기능을 제거할 예정임을 1월에 발표하게 되었습니다.With so many good solutions available that integrate well with TFS and Visual Studio Team Services, we announced in January the plans to remove our Team Room feature from both TFS 2018 and Visual Studio Team Services.


맨 위로 이동
Top of Page