Team Foundation Server 2017 업데이트 2 릴리스 정보 Team Foundation Server 2017 Update 2 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.


이 문서에서는 Team Foundation Server 2017 업데이트 2의 최신 릴리스에 대한 정보를 찾을 수 있습니다.In this article, you will find information regarding the newest release for Team Foundation Server 2017 Update 2. 단추를 클릭하여 다운로드합니다.Click the button to download.

Download the latest version of Team Foundation Server

다른 형식 또는 언어는 다운로드 사이트를 참조하세요.For other formats or languages, please see the download site.

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


사용자 의견Feedback

Microsoft는 여러분의 의견을 기다리고 있습니다!We’d love to hear from you! 개발자 커뮤니티 포털을 통해 문제를 보고하고 추적할 수 있습니다.You can report a problem and track it through the Developer Community portal. Visual Studio Team Services 제품 업데이트 사이트를 통해 제안 사항을 보내주세요.Send us your suggestions through the Visual Studio Team Services Product Updates site.


릴리스 날짜: 2017년 7월 24일Release Date: July 24, 2017

TFS 2017 업데이트 2의 업데이트 요약Summary of Updates in TFS 2017 Update 2

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

기능별 개선 사항 영역에서 모든 새 기능에 대한 세부 정보를 확인할 수 있습니다.You can see the details of all the new features by viewing the improvements by feature area:


이번 릴리스의 새로운 기능What's New in this Release

작업 항목 추적의 개선 사항 Work Item Tracking Improvements

작업 항목 형식 아이콘 Work item type icons

Microsoft는 고객이 원하는 모든 제품을 사용할 수 있게 하겠다고 전 세계에 약속했습니다.We have made a global commitment to make our products fully accessible to our customers. 이러한 약속의 일환으로 Microsoft는 키보드 패턴에서 시각 디자인 및 레이아웃에 이르는 여러 접근성 문제를 찾고 해결하기 위해 노력하고 있습니다.As part of that commitment, we have been working to find and address many accessibility issues – anywhere from keyboard patterns to visual design and layout.

작업 항목 추적은 여러 환경에서 작업 항목 형식을 나타내는 색에만 의존했습니다.Work item tracking has relied solely on color in many experiences to convey work item type. 그러나 이 경우 색맹이거나 시력이 낮은 사용자는 색이 유사하여 항목을 구분할 수 없는 문제가 발생합니다.However, this is problematic for our color blind or low vision users who may not be able to distinguish between items due to similarities in color. 모든 고객이 작업 항목 형식을 더 잘 읽을 수 있도록 작업 항목 형식에 대한 시각적 언어로 아이콘을 도입했습니다.To increase the scanability of work item type for all our customers, we have introduced icons to the visual language of work item type. 다양한 아이콘 라이브러리에서 선택하여 작업 항목 형식을 사용자 지정할 수 있습니다.You can customize your work item types by choosing from a selection of our icon library.

백로그 및 쿼리 표에서 형식을 나타내는 색 막대가 색 구분 아이콘으로 바뀌었습니다 (그림 1).Color bars conveying type on the backlog and queries grids have been replaced with colored icons (Figure 1).

Wit icons in query
(그림 1) 쿼리의 색이 칠해진 아이콘(Figure 1) Colored icons in query

보드의 카드에 이제 형식 아이콘이 포함됩니다 (그림 2).Cards on the board now include a type icon (Figure 2).

Board with icon type
(그림 2) 아이콘 형식이 있는 보드(Figure 2) Board with icon type

배달 계획 Delivery Plans

배달 계획은 반복 기반 일정에서 작업 항목을 추적하여 팀 간 가시성과 맞춤을 향상할 수 있는 조직 도구입니다.Delivery Plans is an organizational tool that helps you drive cross-team visibility and alignment by tracking work status on an iteration-based calendar. 계획을 조정하여 계정의 여러 프로젝트에서 원하는 팀 또는 백로그 수준을 포함할 수 있습니다.You can tailor your plan to include any team or backlog level from across projects in the account. 또한 계획의 __필드 조건__을 사용하여 보기를 추가로 사용자 지정하고 __표식__으로 중요한 날짜를 강조 표시할 수 있습니다.Furthermore, Field Criteria on Plans enables you to further customize your view, while Markers highlight important dates.

자세히 알아보고 확장을 설치하려면 배달 계획의 Marketplace 페이지를 참조하세요.Check out the marketplace page for Delivery Plans to learn more and install the extension.

인터넷에서 연결이 끊어진 TFS 인스턴스를 사용하는 사용자의 경우, VSTS Marketplace로 이동하지 않고 웹 액세스의 확장 관리 옵션에서 바로 배달 계획을 사용할 수 있습니다.For users with a TFS instance that is disconnected from the Internet, Delivery Plans will be available directly from the Manage extensions option in web access, without navigating to the VSTS Marketplace. __확장 관리__에서 __로컬 확장명 찾아보기__를 선택한 후 __배달 계획__을 클릭하고 __설치__를 클릭합니다.From Manage extensions, click on Browse local extensions, then select Delivery Plans and click Install. 자세한 내용은 사전 설치된 확장에 관한 설명서를 참조하세요.See the documentation on pre installed extensions for more information.

작업 항목과 빌드 간 자동 연결Automatic linking from work items to builds

빌드 정의의 이 새 설정을 사용하면 대량의 빌드 집합을 수동으로 검색하지 않고도 작업을 포함한 빌드를 추적할 수 있습니다.With this new setting in the build definition, you can track the builds that have incorporated your work without having to search through a large set of builds manually. 작업 항목과 연결된 성공한 각 빌드는 작업 항목 폼의 개발 섹션에 자동으로 표시됩니다.Each successful build associated with the work item automatically appears in the development section of the work item form.

이 기능을 사용하려면 빌드 정의의 옵션 아래에서 설정을 전환합니다 (그림 3).To enable this feature, toggle the setting under Options in your build definition (Figure 3).

WIT build linking
(그림 3) WIT 빌드 연결(Figure 3) WIT build linking

이전 작업 항목 폼 사용 중단Deprecation of old work item form

새 작업 항목 폼에 대한 전반적인 피드백이 긍정적이어서 이제 호스팅 계정에서 100% 채택합니다.Overall feedback for the new work item form has been positive and we now have 100% adoption on our hosted accounts. VSTS 사용자를 만족하게 한 것과 같은 수준의 기능을 온-프레미스 고객도 활용할 수 있도록, 이전 작업 항목 폼과 이전 확장성 모델의 사용을 중단하기로 했습니다.We want on-premises customers to tap into the same value that has delighted our VSTS users and so we have made the decision to deprecate the old work item form and old extensibility model. Microsoft 애플리케이션 수명 주기 관리 페이지에서 계획에 대해 자세히 알아보세요.Read more about our plans on the Microsoft Application Lifecycle Management page.

작업 항목 검색을 사용하면 컬렉션의 모든 프로젝트에서 작업 항목을 빠르고 유연하게 검색할 수 있습니다 (그림 4).Work Item Search provides fast and flexible search across all your work items over all projects in a collection (Figure 4). 작업 항목 검색 전체 텍스트 검색 엔진을 사용하여 모든 작업 항목 필드의 용어를 쉽게 검색하고 관련 작업 항목을 효율적으로 찾을 수 있습니다.You can use the Work Item Search full text search engine to easily search for terms across all work item fields and efficiently locate relevant work items. 원하는 작업 항목 필드에서 인라인 검색 필터를 사용하여 작업 항목 목록의 범위를 빠르게 좁힐 수 있습니다.Use in-line search filters, on any work item field, to quickly narrow down to a list of work items.

TFS에 검색 서비스가 구성되어 있으면 다른 항목을 설치할 필요 없이 바로 검색을 시작할 수 있습니다.Once the Search service is configured in TFS, you can get searching without the need to install anything else. 작업 항목 검색을 사용하여 다음을 수행할 수 있습니다.By using Work Item Search you can:

  • 모든 프로젝트에서 검색: 자신과 파트너 팀의 백로그에서 검색합니다.Search over all your projects: Search in your own and your partner teams' backlog. 모든 작업 항목에 대한 프로젝트 간 검색을 사용하여 조직의 전체 작업 항목에서 검색할 수 있습니다.Use cross-project searches over all the work items to search across your organization's entire work items. 프로젝트 및 영역 경로 필터를 사용하여 검색 범위를 좁힐 수 있습니다.Narrow your search by using project and area path filters.
  • 모든 작업 항목 필드에서 검색: ere 필드를 비롯한 모든 작업 항목 필드에서 검색하여 관련 작업 항목을 빠르고 쉽게 찾을 수 있습니다.Search across all work item fields: Quickly and easily find relevant work items by searching across all work item fields (including ere fields). 모든 필드에서 전체 텍스트 검색을 사용하여 관련 작업 항목을 효율적으로 찾을 수 있습니다.Use a full text search across all fields to efficiently locate relevant work items. 코드 조각 뷰에는 일치 항목을 찾은 위치가 표시됩니다.The snippet view indicates where matches were found.
  • 특정 필드에서 검색: 원하는 작업 항목 필드에서 빠른 인라인 검색 필터를 사용하여 작업 항목 목록의 범위를 몇 초 안에 좁힐 수 있습니다.Search in specific fields: Use the quick in-line search filters, on any work item field, to narrow down to a list of work items in seconds. 제안 사항 드롭다운 목록을 사용하여 검색을 더 빨리 완료할 수 있습니다.The dropdown list of suggestions helps complete your search faster. 예를 들어 __AssignedTo:Chris WorkItemType:Bug State:Active__를 검색하면 Chris라는 사용자에게 할당된 모든 활성 버그를 찾습니다.For example, a search such as AssignedTo:Chris WorkItemType:Bug State:Active finds all active bugs assigned to a user named Chris.
  • 작업 항목 추적과의 통합 활용: 작업 항목 검색 인터페이스가 작업 허브의 익숙한 컨트롤과 통합되어 있으므로 보고 편집하고 주석을 달고 공유하는 등의 다양한 작업을 할 수 있습니다.Take advantage of integration with work item tracking: The Work Item Search interface integrates with familiar controls in the Work hub, letting you view, edit, comment, share, and much more.
Workitem search
(그림 4) 작업 항목 검색(Figure 4) Workitem search

버전 제어 기능 향상 Version Control Improvements

새로운 분기 정책 구성 환경 New branch policies configuration experience

분기 정책을 구성 환경을 다시 설계하여 몇 가지 유용한 새 기능을 추가했습니다 (그림 5).We’ve redesigned the branch policies configuration experience and added some great new capabilities (Figure 5). 강력한 기능 중 하나는 분기 폴더에 대한 정책을 구성할 수 있는 기능입니다.One of the most powerful features is the ability to configure policies for branch folders. 이 작업은 분기 뷰에서 분기 폴더를 선택하고 상황에 맞는 메뉴에서 __분기 정책__을 선택하여 수행할 수 있습니다.You can do this from the Branches view by selecting a branch folder and choosing Branch policies from the context menu.

Configure branch policies
(그림 5) 분기 정책 구성(Figure 5) Configure branch policies

그러면 분기 폴더의 모든 분기에 적용되는 정책을 구성할 수 있는 새 정책 구성 UX가 열립니다 (그림 6).This will open the new policies configuration UX, where you can configure policies that apply to all of the branches in the branch folder (Figure 6).

Policies page
(그림 6) 정책 페이지(Figure 6) Policies page

빌드 정책을 사용하는 경우 이제 하나의 분기에 대해 여러 빌드를 구성할 수 있습니다.If you’re using the build policy, you can now configure multiple builds for a single branch. 자동 또는 수동 트리거를 지정할 수 있는 새 옵션도 있습니다 (그림 7).There are also new options to specify an automatic or manual trigger (Figure 7). 수동 트리거는 실행 시간이 길 수 있는 자동 테스트 실행과 같은 작업에 유용하며 끌어오기 요청을 완료하기 전에 한 번만 실행하면 됩니다.Manual triggers are useful for things like automated test runs that might take a long time to run, and you only really need to run once before completing the pull request. 또한 빌드 정책에는 여러 빌드를 구성할 때 유용한 표시 이름도 있습니다.The build policy also has a display name that is useful if you’re configuring multiple builds.

Manual build
(그림 7) 수동 빌드(Figure 7) Manual build

수동으로 트리거되는 정책을 구성한 경우 끌어오기 요청의 정책 섹션에서 빌드 큐 대기 옵션을 선택하여 실행할 수 있습니다 (그림 8).Once you’ve configured a manually triggered policy, you can run it by selecting the Queue build option in the Policies section for the pull request (Figure 8).

Manual build queue
(그림 8) 수동 빌드 큐(Figure 8) Manual build queue

필수 검토자 정책 (그림 9) 의 경우 관리자가 정책이 적용될 때 끌어오기 요청 타임라인에 추가되는 메모를 지정할 수 있는 기능을 추가했습니다 (그림 10).For required reviewer policies (Figure 9), we added the ability for administrators to specify a note that will be appended to the pull request timeline when the policy applies (Figure 10).

Required reviewer dialog
(그림 9) 필수 검토자 대화 상자(Figure 9) Required reviewer dialog
Required reviewer note
(그림 10) 필수 검토자 메모(Figure 10) Required reviewer note

활성 주석 없음에 대한 새로운 정책New policy for no active comments

주석 정책을 사용하여 끌어오기 요청의 모든 주석이 처리되도록 할 수 있습니다.Ensure that all comments in your pull requests are being addressed with the new Comments policy. 이 정책을 사용하도록 설정하는 경우 활성 주석이 있으면 PR 완료가 차단되어 모든 주석이 해결되도록 합니다.With this policy enabled, active comments will block completion of the PR, forcing all comments to be resolved. PR 만든 이에게 주석을 남기되 끌어오기 요청을 긍정적으로 승인하려는 검토자는 만든 이가 병합할 때 어떤 주석도 빠뜨리지 않도록 할 수 있습니다.Reviewers that leave comments for the PR author but optimistically approve the pull request can be sure that an author that’s eager to merge won’t miss any comments.

파일 허브 기능 향상Files hub improvements

파일 허브의 보기 및 편집 환경을 개선하는 여러 업데이트를 만들었습니다.We’ve made several updates to the Files hub to improve the viewing and editing experiences.

보기 환경의 경우 현재 폴더에서 추가 정보를 보고 (그림 11), Markdown 파일을 미리 보고, 파일을 이전 버전과 비교하고 (그림 12), 원인을 볼 수 있는 피벗을 추가했습니다.For viewing, we’ve added pivots that let you view the README in the current folder (Figure 11), preview Markdown files, compare a file to a previous version (Figure 12), and view blame.

Files viewing
(그림 11) 파일 보기(Figure 11) Files viewing
Git graph
(그림 12) Git 그래프(Figure 12) Git graph
>

편집 환경의 경우 이제 변경 사항을 미리 보고, 주석을 쉽게 추가하고, 새 분기에 커밋하고, 작업 항목을 연결할 수 있습니다 (그림 13).For editing, you can now preview your changes, easily add a comment, commit to a new branch, and link work items (Figure 13).

Files editing
(그림 13) 파일 편집(Figure 13) Files editing

Git 리포지토리 시각화 Visualize your git repository

이제 리포지토리 또는 파일에 대한 커밋 기록을 표시할 때 그래프로 볼 수 있습니다.You can now see a graph while showing commit history for repositories or files. 따라서 Git 리포지토리에 대한 모든 분기 및 커밋의 멘탈 모델을 Git 그래프를 사용하여 쉽게 만들 수 있습니다 (그림 14).This allows you to easily create a mental model of all your branches and commits for your git repositories using git graph (Figure 14). 이 그래프에서는 모든 커밋을 토폴로지 순서로 표시합니다.The graph shows all your commits in topological order.

Git graph
(그림 14) Git 그래프(Figure 14) Git graph

Git 그래프의 주요 요소는 다음과 같습니다 (그림 15).The key elements of the git graph include (Figure 15):

  1. Git 그래프는 오른쪽에 맞추어지므로 기본 분기 또는 선택한 분기와 연결된 커밋은 오른쪽에 표시되고 나머지 그래프는 왼쪽에 표시됩니다.the git graph is right-aligned, so commits associated with the default branch or the selected branch appear on the right while the rest of the graph grows on the left.
  2. 병합 커밋은 첫 번째 부모와 두 번째 부모에 연결되는 회색 점으로 표시됩니다.merge commits are represented by grey dots connected to their first parent and second parent.
  3. 일반 커밋은 파란색 점으로 표시됩니다.normal commits are represented by blue dots.
  4. 커밋의 부모 커밋이 다음 50개 커밋의 뷰포트에 표시되지 않는 경우 커밋 연결을 삭제합니다.if the parent commit of a commit is not visible in the view port on the next 50 commits, then we excise the commit connection. 화살표를 클릭하면 커밋이 부모 커밋에 연결됩니다.Once you click the arrow, the commit is connected to its parent commit.
Git graph elements
(그림 15) Git 그래프 요소(Figure 15) Git graph elements

커밋의 git 태그 보기 View git tags on commits

팀에서 Git 태그를 사용하여 리포지토리 기록의 특정 위치를 표시하는 경우 이제 커밋에 만든 태그가 표시됩니다.If your team has been using Git tags to mark a specific point in the history of your repository, then your commits will now show the tags that you have created. 커밋 목록 뷰 및 세부 정보 페이지에서 특정 커밋의 태그 (그림 16) 를 볼 수 있습니다.You will be able view tags (Figure 16) for a specific commit in the commit list view and the details page.

Show tags
(그림 16) 태그 표시(Figure 16) Show tags

커밋에 태그 추가Add tags to commits

명령줄에서 태그를 만들어 리포지토리에 푸시하는 대신 이제 커밋으로 이동하여 태그를 추가하면 됩니다 (그림 17).Instead of creating tags from the command line and pushing the tags to the repository, you can now simply go to a commit and add a tag (Figure 17). 태그 만들기 대화 상자에서도 리포지토리의 다른 참조에 태그를 지정할 수 있습니다.The tag creation dialog will also let you tag any other ref on the repo.

Create tag details
(그림 17) 태그 세부 정보 만들기(Figure 17) Create tag details

커밋 목록 뷰에서는 상황에 맞는 메뉴도 지원합니다 (그림 18).The commit list view also supports a context menu (Figure 18). 커밋 정보 페이지로 이동하지 않고도 태그를 만들고 새 분기를 만들 수 있습니다 (그림 19).No need to go to the commit details page to create tags and create new branches (Figure 19).

Create tag history
(그림 18) 태그 기록 만들기(Figure 18) Create tag history
Tag branch
(그림 19) 태그 분기(Figure 19) Tag branch

업데이트된 변경 집합 및 보류 집합 페이지Updated changeset and shelveset pages

TFVC에서 변경 집합 및 보류 집합 페이지를 최신화했습니다.We have modernized the changeset and shelveset pages in TFVC. 두 페이지 모두 보조 기술을 사용하는 사용자가 더욱 쉽게 사용할 수 있게 되었습니다.Both pages are made more accessible for those of you who use assistive technologies. 새 페이지에는 변경 집합 제목 및 변경 집합에 대한 만든 이 정보를 비롯한 관련 정보를 포함하는 새 머리글도 있습니다 (그림 20).The new pages also have a new header that contains the changeset title and associated information about the changeset, such as author details (Figure 20).

Changeset page
(그림 20) 변경 집합 페이지(Figure 20) Changeset page

또한 변경 집합 및 보류 집합 페이지 모두 새 markdown 토론 컨트롤(그림 21)을 호스트하는데, 이 컨트롤을 통해 markdown에 주석을 입력하고, 사용자를 @mention하고, #을 사용하여 작업 항목을 연결하고, 파일과 이미지를 쉽게 첨부할 수 있습니다.Both changeset and shelveset pages also host the a new markdown discussion control (Figure 21) that will allow to type comments in markdown, @mention users, associate work items using #, and easily attach files and images.

Changeset discussion
(그림 21) 변경 집합 토론(Figure 21) Changeset discussion

향상된 커밋 필터링Improved commit filtering

이제 고급 필터링 옵션으로 커밋 기록 결과를 필터링할 수 있습니다 (그림 22).You can now filter the commit history results (Figure 22) by advanced filtering options. 다음을 기준으로 커밋을 필터링할 수 있습니다.You can filter commits by:

  • 전체 기록full history.
  • 간단한 병합을 포함한 전체 기록full history with simplified merges.
  • 첫 번째 부모first parent.
  • 간단한 기록(기본 필터 설정)simple history (this is the default filter setting).
Changeset discussion
(그림 22) 향상된 커밋 필터링(Figure 22) Improved commit filtering

TFVC에서 Git으로 리포지토리 가져오기Import repositories from TFVC to Git

TFVC 리포지토리에서 동일한 계정의 Git 리포지토리로 코드를 마이그레이션할 수 있습니다.You can migrate code from your TFVC repositories to Git repositories in the same account. 마이그레이션을 시작하려면 리포지토리 선택기 드롭다운에서 __리포지토리 가져오기__를 선택합니다 (그림 23).To start migration, select import repository from the repository selector drop-down (Figure 23).

Repository selector drop-down
(그림 23) 리포지토리 선택기 드롭다운(Figure 23) Repository selector drop-down

개별 폴더 또는 분기를 Git 리포지토리를 가져오거나 전체 TFVC 리포지토리를 가져올 수 있습니다(분기 제외)(그림 24).Individual folders or branches can be imported to the Git repository, or the entire TFVC repository can be imported (minus the branches) (Figure 24). 최대 180일 동안의 기록을 가져올 수도 있습니다.You can also import up to 180 days of history.

Import repo complete
(그림 24) 리포지토리 가져오기 완료(Figure 24) Import repo complete

Git LFS 파일 잠금Git LFS file locking

Git LFS 파일 잠금 기능을 추가했습니다.We have added the Git LFS file locking feature. 따라서 차이점 비교 불가능한 대형 파일을 작업하는 팀에서 두 명 이상의 사용자가 같은 파일을 동시에 편집할 때 작업이 손실되는 문제를 방지할 수 있습니다.This allows teams working with large, undiffable files to avoid losing work when two or more people attempt to edit the same file at once. 사용자는 파일을 편집하기 전에 잠가서 서버에 알립니다.Before anyone can begin editing the file, they take a lock, which notifies the server. 다른 사용자가 잠그려고 하면 서버에서 요청을 거부하고 해당 파일을 다른 사용자가 이미 작업하고 있음을 두 번째 사용자에게 알립니다.When anyone else attempts to take a lock, the server rejects the request, letting the second person know that someone else is already working on that file. 이 기능을 사용하려면 Git LFS 2.1 이상으로 업그레이드하세요.Please upgrade to Git LFS 2.1 or higher to use this feature.

Git 커밋 주석에서 새 토론 컨트롤 사용Git commit comments use the new discussion control

Git 커밋에 있는 간단한 주석이 새 토론 컨트롤을 사용하도록 업데이트되었습니다.Lightweight comments left on Git commits has been updated to use the new discussion control. 따라서 이러한 주석에서 Markdown이 지원되며 웹에서 모든 코드 주석 처리 기능이 완전해져서 Git 및 TFVC 모두가 최신 환경을 사용할 수 있습니다.This brings support for Markdown in those comments, and rounds out all of the code-commenting features in the web for both Git and TFVC to use the latest experience.

새 트리 뷰 컨트롤New tree view control

끌어오기 요청 파일 뷰, Git 커밋 정보, Git 푸시 정보, TFVC 보류 집합 정보, TFVC 변경 집합 정보, TFVC 변경 집합 허브 및 Git 기록 허브가 새 트리 뷰 컨트롤로 업데이트되었습니다 (그림 25).The Pull Request Files view, Git commit details, Git push details, TFVC Shelveset details, TFVC Changeset details, TFVC Changesets hub and Git history hub have been updated with a new tree view control (Figure 25). 트리 뷰의 유용성이 일부 개선됩니다.The tree view has a few usability improvements. 우선, 빈 폴더 노드를 자동으로 축소하고 뷰에 있는 파일 수를 극대화하는 압축된 트리 뷰를 표시하도록 뷰를 변경했습니다.First, we’ve changed the view to show a condensed tree view that automatically collapses empty folder nodes, maximizing the number of files that are in view.

또한 트리에서 주석이 보다 간결하게 표시됩니다.The tree also shows comments in a more compact way. 주석이 있는 파일에는 각 주석 스레드의 자식 항목이 표시되고, 스레드를 만든 사용자를 나타내는 아바타가 함께 표시됩니다.Files with comments show a child item for each comment thread, with the avatar indicating the user that created the thread. 새 주석 스레드 및 회신이 있는 스레드는 파란색 점으로 표시되고 회신 수가 수로 요약되어 있습니다.New comment threads and those with replies are indicated by the blue dot, and the count of replies is summarized with a count.

New tree view
(그림 25) 새 트리 뷰(Figure 25) New tree view

끌어오기 요청 개선 사항 Pull Request Improvements

PR 만든 이 및 검토자를 위해 개선된 CTAImproved CTAs for PR author and reviewers

분기 정책을 사용하는 팀의 경우, 끌어오기 요청을 볼 때 필요한 작업이 무엇인지 정확히 알기 어려운 경우가 때때로 있습니다.For teams using branch policies, it can sometimes be hard to know exactly what action is required when you view a pull request. 예를 들어, 주요 행동 유도 문구가 완료 단추인 경우 완료할 수 있다는 의미인가요?If the main call to action is the Complete button, does that mean it’s ready to complete? 이제 PR 뷰에서는 페이지를 보고 있는 사용자와 구성된 분기 정책 상태에 대한 정보를 사용하여 해당 사용자에게 가장 적합한 행동 유도 문자를 표시합니다.Using information about the person viewing the page and the state of configured branch policies, the PR view will now present the call to action that makes the most sense for that user.

정책이 구성되어 있지만 아직 통과되지 않은 경우 완료 단추 (그림 26) 에서는 자동 완성 기능을 사용하도록 권장합니다.When policies are configured, but aren’t yet passing, the Complete button (Figure 26) will now encourage the use of the Auto-complete feature. 정책이 차단되는 경우 PR을 완료할 수 있을 것 같지 않으므로 이러한 정책이 마침내 통과될 때 PR을 완료하는 옵션을 제공합니다.It’s not likely that you’ll be able to complete the PR successfully if policies are blocking, so we offer an option that will complete the PR when those policies eventually pass.

Auto-complete feature
(그림 26) 자동 완성 기능(Figure 26) Auto-complete feature

검토자의 경우 PR을 완료하기보단 승인하는 경우가 많으므로 아직 승인하지 않은 경우 검토자에게 승인 단추 (그림 27) 가 기본 CTA로 강조 표시됩니다.For reviewers, it’s more likely that you’ll want to approve a PR than complete it, so reviewers will see the Approve button (Figure 27) highlighted as the main CTA if you haven’t approved yet.

CTA approve
(그림 27) CTA 승인(Figure 27) CTA approve

승인하면 검토자도 PR을 완료하는 사용자인 사례의 경우 검토자에게 완료(또는 자동 완성) 단추가 CTA로 강조 표시됩니다.Once approved, reviewers will see the Complete (or Auto-complete) button highlighted as the CTA for those cases where a reviewer is also the person completing the PR.

실행 가능한 주석Actionable comments

주석이 여러 개인 PR에서는 모든 대화를 계속 추적하기가 어려울 수 있습니다.In a PR with more than a few comments, it can be hard to keep track of all of the conversations. 주석을 보다 잘 관리할 수 있도록 해결된 항목을 확인하는 프로세스를 다음과 같은 몇 가지 개선 사항을 통해 간소화했습니다.To help you better manage comments, we’ve simplified the process of resolving items that have been addressed with a number of enhancements:

  • 모든 PR의 헤더에 해결된 주석의 수가 표시됩니다 (그림 28).In the header for every PR, you’ll now see a count of the comments that have been resolved (Figure 28).
PR header
(그림 28) PR 헤더(Figure 28) PR header
  • 주석이 해결된 경우 한 번 클릭으로 확인할 수 있습니다 (그림 29).When a comment has been addressed, you can resolve it with a single click (Figure 29).
Resolve button
(그림 29) 해결 단추(Figure 29) Resolve button
  • 확인하는 중 추가할 주석이 있으면 회신과 확인을 하나의 제스처로 수행할 수 있습니다 (그림 30).If you have comments to add while you’re resolving, you can reply and resolve in a single gesture (Figure 30).
Reply and resolve
(그림 30) 응답 및 해결(Figure 30) Reply and resolve
  • 주석을 확인하면 모든 주석이 해결될 때까지 수가 증가합니다 (그림 31).As comments are resolved, you’ll see the count go up until everything has been addressed (Figure 31).
Comment count address rate
(그림 31) 주석 수 해결률(Figure 31) Comment count address rate
  • 개요의 필터가 개선되어 다양한 주석 상태별로 필터링할 수 있고 각 필터 옵션에 대한 주석 수를 표시할 수 있습니다 (그림 32).The filter in the Overview has been improved to enable filtering by various comment states and to show the count of comments for each filter option (Figure 32).
Filter improvements
(그림 32) 필터 개선 사항(Figure 32) Filter improvements

업데이트 뷰에 다시 지정 및 강제 보내기 표시Updates view shows rebase and force push

끌어오기 요청 정보 뷰의 업데이트 탭이 개선되어 강제 보내기가 발생한 경우와 기본 커밋이 변경된 경우 표시됩니다 (그림 33).In the Pull Request details view, the Updates tab has been improved to show when a force push has occurred and if the base commit has changed (Figure 33). 이 두 기능은 PR을 완료하기 전에 토픽 분기에서 변경 사항을 다시 지정하는 경우에 정말 유용합니다.These two features are really useful if you rebase changes in your topic branches before completing your PRs. 이제 검토자에게 어떤 일이 일어났는지 정확히 알 수 있도록 충분한 정보가 제공됩니다.Reviewers will now have enough info to know exactly what’s happened.

Updates views
(그림 33) 업데이트 보기(Figure 33) Updates views

사용자별 끌어오기 요청 필터링Pull request filtering by people

이제 끌어오기 요청을 더 쉽게 찾을 수 있습니다.It’s now easier to find pull requests! 특정 만든 이가 만들거나 특정 검토자에게 할당된 PR을 찾을 수 있는 새 필터링 옵션을 추가했습니다 (그림 34).We’ve added new filtering options to allow you to find PRs created by a specific author or assigned to a specific reviewer (Figure 34). 만든 이 또는 검토자 필터에서 사용자를 간단히 선택하면 목록이 업데이트되어 필터와 일치하는 PR만 표시됩니다.Simply select a user from the author or reviewer filter, and the list will be updated to show only the PRs that match the filter.

Filtering by people
(그림 34) 사용자별 필터링(Figure 34) Filtering by people

끌어오기 요청 정책을 무시하는 경우 이유 필요Reason required when bypassing pull request policies

끌어오기 요청 정책을 무시하는 경우 이유를 지정해야 합니다.When you are bypassing a pull request policies, you are required to specify a reason. 정책을 무시하도록 선택하는 경우 끌어오기 요청 완료 대화 상자에 새 이유 필드가 표시됩니다 (그림 35).In the Complete pull request dialog, you will see a new Reason field, if they choose to bypass (Figure 35).

Bypass dialog
(그림 35) 바이패스 대화 상자(Figure 35) Bypass dialog

이유를 입력하고 끌어오기 요청을 완료하면 __개요__에 메시지가 표시됩니다 (그림 36).After entering the reason and completing the pull request, the message will be displayed in the Overview (Figure 36).

Bypass message
(그림 36) 바이패스 메시지(Figure 36) Bypass message

팀과 끌어오기 요청 공유Share pull requests with teams

끌어오기 요청 공유 작업을 통해 간편하게 검토자에게 요청에 대해 알릴 수 있습니다 (그림 37).The Share Pull Request action is a handy way to notify reviewers (Figure 37). 이 릴리스에서는 팀 및 그룹에 대한 지원이 추가되어 단 한 단계 실행만으로 끌어오기 요청과 관련된 모두에게 알림을 제공할 수 있습니다.In this release, we’ve added support for teams and groups, so you can notify everyone involved the pull request in a single step.

Share PR with teams
(그림 37) 팀과 PR 공유(Figure 37) Share PR with teams

팀 지원을 위한 끌어오기 요청 향상Pull request improvements for teams

한 사용자가 여러 팀의 구성원인 경우 이러한 팀에 할당된 모든 PR이 내 끌어오기 요청 보기에 나열됩니다 (그림 38).If you’re a member of multiple teams, you will now see all of the PRs assigned to those teams listed in the My Pull Requests view (Figure 38). 이제 내 끌어오기 요청 보기 한 곳만 방문하면 작업해야 할 모든 PR을 볼 수 있습니다.This makes the My Pull Requests view the one stop you need to visit to see all the PRs on your plate.

PR improvements for teams
(그림 38) 팀에 대한 PR 개선 사항(Figure 38) PR improvements for teams

이후 릴리스에서는 단일 프로젝트의 모든 PR을 쉽게 볼 수 있도록 __Code__의 끌어오기 요청 허브에 팀이 추가될 것입니다.In a future release, we’ll add teams to the Pull Requests hub under Code to make it easier to see all of your PRs for a single project.

끌어오기 요청 설명에 대한 기본 알림Default notifications for pull request comments

새 설명 알림을 통해 PR에서 발생하는 대화에 대한 최신 정보를 지속해서 확인할 수 있습니다 (그림 39).Stay up to date with the conversations happening in your PRs with the new comment notifications (Figure 39). 직접 만든 PR의 경우 사용자들이 새 설명 스레드를 추가하거나 기존 스레드에 회신할 때마다 자동으로 알림을 받게 됩니다.For PRs that you've created, you will automatically be notified any time a user adds a new comment thread or replies to an existing thread. 다른 사용자의 PR에 대해 설명을 작성하면 직접 만들거나 회신한 설명 스레드에 대한 이후의 모든 회신에 대해 알림을 받게 됩니다.When you comment on another user's PR, you'll be notified about any future replies to comment threads that you create or reply to.

Default PR notifications
(그림 39) 기본 PR 알림(Figure 39) Default PR notifications

이러한 알림은 기본 구독의 일부로 사용할 수 있으며 알림 설정 페이지에서 구성할 수 있습니다.These notifications are available as part of the out of the box subscriptions, and are configurable on the Notifications settings page.

패키지 관리 향상 Package Management Improvements

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

패키지 관리 사용자 환경이 업데이트되어 속도가 더욱 빨라지고, 사용자가 보고한 공통 문제가 해결되었으며, 예정된 패키지 수명 주기 기능에 필요한 공간이 만들어졌습니다 (그림 40).We've updated the Package Management user experience to make it faster, address common user-reported issues, and make room for upcoming package lifecycle features (Figure 40). 업데이트된 환경 페이지에서 업데이트에 대해 자세히 알아보세요.Learn more about the update on the Updated experience page.

Package Management
(그림 40) 패키지 관리(Figure 40) Package Management

패키지 관리에 npm 추가 정보 및 다운로드 단추 추가Package Management adds npm READMEs and download button

이제 패키지에서 README.md가 포함된 npm 패키지 추가 정보를 볼 수 있습니다 (그림 41).You can now see the README of any npm package that includes a README.md in the package (Figure 41). 추가 정보는 팀에서 패키지에 대한 정보를 문서화하고 공유하는 데 도움이 될 수 있습니다.READMEs can help your team document and share knowledge about your packages.

명령 모음의 다운로드 단추를 사용하여 npm 패키지를 다운로드할 수도 있습니다.You can also download any npm package using the Download button in the command bar.

Package Management npm README
(그림 41) 패키지 관리 npm 추가 정보(Figure 41) Package Management npm README

NuGet 복원 및 NuGet 명령 빌드 작업NuGet Restore and NuGet Command build tasks

NuGet 설치 관리자(이제 __NuGet 복원__이라고 함) 작업에 대한 주요 업데이트가 수행되었으며 __NuGet 명령__이라는 새로운 NuGet 작업이 추가되었습니다.We’ve made major updates to the NuGet Installer (now called NuGet Restore) task, and added a new NuGet task: NuGet Command. 가장 주목할 만한 사항은 NuGet 명령NuGet 복원 작업에서 이제 기본적으로 nuget.exe 4.0.0을 사용한다는 것입니다.Most notably, the NuGet Command and NuGet Restore tasks now use nuget.exe 4.0.0 by default.

__NuGet 복원__은 Visual Studio 빌드 단계 전에 패키지를 복원하는 가장 일반적인 시나리오에 맞게 최적화되어 있습니다.NuGet Restore is now optimized for the most common scenario of restoring packages before a Visual Studio Build step. 단일 NuGet 피드를 공유하는 소규모 프로젝트에 대한 지원도 향상되어, 이제 Team Services 피드를 선택하여 자동 생성 NuGet.Config에 추가할 수 있습니다.It also has better support for small projects that share a single NuGet feed: you can now pick a Team Services feed and have it added to an auto-generated NuGet.Config.

더욱 복잡한 NuGet 작업의 경우 NuGet 명령 작업을 통해 유연하게 명령 및 인수 집합을 지정할 수 있습니다 (그림 42).For more complex NuGet operations, the NuGet Command task provides the flexibility to specify any command and set of arguments (Figure 42).

NuGet command
(그림 42) NuGet 명령(Figure 42) NuGet command

빌드 및 릴리스 향상 Build and Release Improvements

새 빌드 정의 편집기 New build definition editor

빌드 정의 편집기를 다시 디자인하여 더욱 편리하고 직관적인 환경을 제공하고 일부 문제점을 해결하며 새 기능을 추가했습니다.We’ve redesigned our build definition editor to provide a more intuitive experience, fix some pain points, and add new capabilities. 사용자가 더욱 쉽게 템플릿을 사용하고, 작업을 추가하고, 설정을 변경할 수 있게 되었습니다.We hope that you’ll find it easier to use templates, add tasks, and change settings. 또한 이제 프로세스 매개 변수를 사용하여 복잡한 작업 없이 쉽게 가장 중요한 데이터를 지정할 수 있습니다.And now you can use process parameters to make it easier to specify the most important bits of data without having to go deep into your tasks.

템플릿 검색Search for a templates

원하는 템플릿을 검색하여 적용하거나 빈 프로세스를 시작하세요 (그림 43).Search for the template you want and then apply it, or start with an empty process (Figure 43).

Build template search
(그림 43) 빌드 템플릿 검색(Figure 43) Build template search

작업을 빠르게 찾아 원하는 위치에 추가Quickly find and add a task right where you want it

사용할 작업을 검색하여 찾으면 왼쪽에 있는 현재 선택된 작업 다음에 추가하거나 원하는 위치로 끌어서 놓을 수 있습니다 (그림 44).Search for the task you want to use, and then after you’ve found it, you can add it after the currently selected task on the left side, or drag and drop it where you want it to go (Figure 44).

Build task search
(그림 44) 빌드 작업 검색(Figure 44) Build task search

또한 작업을 끌어서 놓아 이동하거나, Ctrl 키를 누른 상태에서 끌어서 놓아 복사할 수 있습니다.You can also drag and drop a task to move it, or drag and drop while holding the Ctrl key to copy the task.

프로세스 매개 변수를 사용하여 작업에 키 인수 전달Use process parameters to pass key arguments to your tasks

이제 빌드 정의 또는 템플릿을 사용하는 사용자가 프로세스 매개 변수 (그림 45) 를 사용하여 복잡한 작업 없이 쉽게 가장 중요한 데이터를 지정할 수 있습니다.You can now use process parameters (Figure 45 to make it easier for those who use your build definition or template to specify the most important bits of data without having to go deep into your tasks.

Process parameters
(그림 45) 프로세스 매개 변수(Figure 45) Process parameters

기본 제공 템플릿 중 일부(예: Visual StudioMaven)에서 새 빌드를 만들면 작동 방식을 확인할 예를 볼 수 있습니다.If you create a new build from some of the built-in templates (for example Visual Studio and Maven) you can see examples of how these work.

새 편집기에는 소스 설정에 대한 빠른 액세스 제공 등 다른 몇 가지 향상된 기능도 포함되어 있습니다.The new editor includes a few other enhancements, such as giving you quicker access to your sources settings.

새 편집기를 사용하여 첫 번째 빌드 정의를 만드는 연습을 보려면 CI/CD for newbies(초보자를 위한 CI/CD)를 참조하세요.For a walkthrough of creating your first build definition using the new editor, see CI/CD for newbies.

2017 사용자 환경 페이지에서 자세한 내용을 알아보세요.Learn more on the 2017 user experience page.

여러 버전의 확장 작업Multiple versions of Extension tasks

이제 확장 작성자는 특정 작업의 여러 버전이 포함된 확장을 만들 수 있으므로 프로덕션에 있는 각 주 버전에 대한 패치를 제공할 수 있습니다.Extension authors can now create extensions with multiple versions of a given task, which enables them to ship patches for each major version they have in production.

확장 내에서 사용자 지정 빌드 작업을 만들기 위한 참조를 참조하세요.See Reference for creating custom build tasks within extensions.

조건부 빌드 작업 Conditional build tasks

오류가 있는 경우 메시지를 보내거나 정리를 수행하는 작업과 같이 빌드 작업을 더 세밀하게 제어하도록 네 가지 기본 제공 옵션이 제공되어 작업이 실행되는 경우를 제어할 수 있습니다 (그림 46).If you’re looking for more control over your build tasks, such as a task to clean things up or send a message when something goes wrong, we’re now offering four built-in choices for you to control when a task is run (Figure 46).

Conditional build tasks
(그림 46) 조건부 빌드 작업(Figure 46) Conditional build tasks

특정 분기에서만 실행되거나, 특정 트리거를 사용하여 실행되거나, 특정 조건에서만 실행되는 작업과 같이 더욱 유연한 제어가 필요한 경우 다음과 같이 고유한 사용자 지정 조건을 표시할 수 있습니다.If you are looking for more flexibility, such as a task to run only for certain branches, with certain triggers, under certain conditions, you can express your own custom conditions:

and(failed(), eq(variables['Build.Reason'], 'PullRequest'))

Specify conditions for running a task(작업 실행 조건 지정) 페이지를 참조하세요.See Specify conditions for running a task page.

컨테이너 기반 응용 프로그램 빌드 및 배포를 위한 기본 제공 작업Built-in tasks for building and deploying container based applications

이 릴리스에서는 기본적으로 Docker 확장의 작업을 대부분 제품으로 가져와 개선했으며, 더욱 쉬운 컨테이너 시나리오를 위해 새로운 여러 작업 및 템플릿을 도입했습니다.With this release we have pulled most of the tasks in our Docker extension into the product by default, improved them, and introduced a set of new tasks and templates for making a set of container scenarios easier.

  • Docker: Docker 이미지를 빌드하거나, 푸시하거나, 실행합니다. 또는 Docker 명령을 실행합니다.Docker: Build, push, or run Docker images, or run a Docker command. 이 작업은 Docker 또는 Azure Container Registry와 함께 사용할 수 있습니다.This task can be used with Docker or Azure Container registry. 이제 ACR을 사용하는 기본 제공 서비스 주체 인증을 통해 사용 편의성을 더욱 높일 수 있습니다.You can now use our built-in service principal authentication with ACR to make it even easier to use.
  • Docker Compose: 다중 컨테이너 Docker 응용 프로그램을 빌드하거나, 푸시하거나, 실행합니다.Docker-Compose: Build, push, or run multi-container Docker applications. 이 작업은 Docker 또는 Azure Container Registry와 함께 사용할 수 있습니다.This task can be used with Docker or Azure Container registry.
  • Kubernetes: kubectl 명령을 실행하여 Azure Container Service의 Kubernetes 클러스터를 배포하거나, 구성하거나, 업데이트합니다.Kubernetes: Deploy, configure, or update your Kubernetes cluster in Azure Container Service by running kubectl commands.
  • Service Fabric: 컨테이너를 Service Fabric 클러스터에 배포합니다.Service Fabric: Deploy containers to a Service Fabric Cluster. Service Fabric은 클라우드에서 Windows 컨테이너를 실행하는 데 가장 적합한 제품입니다.Service Fabric is the best choice today for running Windows Containers in the cloud.

Azure 웹앱 배포 업데이트Azure Web App deployment updates

Azure 웹 응용 프로그램의 여러 기능이 다음과 같이 향상되었습니다.We have made many enhancements for Azure Web Applications:

  • Azure App Service 배포 작업에서 Java WAR 파일, Node.js, Python 및 PHP 응용 프로그램 배포를 지원합니다.Azure App Service deployment task supports Java WAR files, Node.js, Python, and PHP applications to be deployed.
  • Azure App Service 배포 작업에서 컨테이너를 사용하는 Linux용 Azure 웹앱에 대한 배포를 지원합니다.Azure App Service deployment task supports deploying to Azure Web App for Linux using containers.
  • Azure Portal의 지속적인 업데이트가 확장되어 노드 응용 프로그램을 지원합니다.Azure portal Continuous Delivery is expanded now support Node applications.
  • Azure App Service 관리 작업이 Azure App Service에 대한 시작, 중지, 다시 시작 또는 슬롯 교환에 추가되었습니다.Azure App Service manage task is added to Start, Stop, Restart or Slot swap for an Azure App Service. 또한 필요한 PHP 또는 Python 버전 설치를 지원하는 사이트 확장 설치나 IIS 관리자 또는 Application Insights 설치도 지원합니다.It also supports installing site extensions to enable installation of the required PHP or Python version or installing IIS Manager or Application Insights.

CI/CD 구성을 위해 최신 Azure CLI 버전에 CI/CD 지원도 도입했습니다.We have also introduced CI/CD support into the latest version of the Azure CLI for configuring CI/CD. 예를 들면 다음과 같습니다.Here is an example:

az appservice web source-control config --name mywebapp --resource-group mywebapp_rg --repo-url https://myaccount.visualstudio.com/myproject/_git/myrepo --cd-provider vsts --cd-app-type AspNetCore

.NET Core 작업에서 프로젝트 파일 지원.NET Core tasks support project files

최신 업데이트에서는 project.json 외에도 *.csproj 파일을 지원하도록 .NET Core 작업이 개선되었습니다.With the current update, we are enhancing .NET core tasks to support *.csproj files in addition to project.json. 이제 빌드 에이전트의 Visual Studio 2017에서 csproj 파일을 사용하여 .NET Core 응용 프로그램을 빌드할 수 있습니다.You can now use Visual Studio 2017 on your build agents to build .NET core applications using csproj files.

SSH 배포 향상SSH deployment improvements

Copy Files Over SSH build/release(SSH 빌드/릴리스를 통해 파일 복사) 작업에서 이제 대상 경로에 물결표()를 사용할 수 있으므로 원격 사용자의 홈 디렉터리에 파일을 복사하는 작업이 간소화됩니다.The Copy Files Over SSH build/release task now supports tildes() in the destination path to simplify copying files to a remote user’s home directory. 새 옵션을 사용하면 복사할 파일이 없는 경우 빌드/릴리스에 오류가 발생할 수 있습니다.Also, a new option allows causing the build/release to fail when no files are found to copy.

SSH 빌드/릴리스 작업은 이제 원격 Linux 또는 macOS 컴퓨터에서 Windows 줄 끝이 사용된 스크립트의 실행을 지원합니다.The SSH build/release task now supports running scripts with Windows line endings on remote Linux or macOS machines.

빌드 또는 릴리스 중 SSH 키 설치Install an SSH key during a build or release

새 미리 보기 작업인 SSH 키 설치(미리 보기) 는 빌드 또는 릴리스 전에 SSH 키를 설치하고 빌드 또는 릴리스가 완료되면 에이전트에서 SSH 키를 제거합니다.A new preview task, Install SSH Key (Preview), installs an SSH key prior to a build or release and removes it from the agent when the build or release completes. 설치된 키를 사용하여 Git 리포지토리 또는 하위 모듈에서 코드를 페치하거나 배포 스크립트 또는 SSH 인증이 필요한 다른 작업을 실행할 수 있습니다.The installed key can be used for fetching code from a Git repository or submodules, running deployment scripts, or other activities that require SSH authentication. 앞으로 암호 및 다른 기능을 지원하도록 향상될 것입니다.It will be improved in the future to support passphrases and other capabilities.

Visual Studio 2017이 지정되었지만 에이전트에 없는 경우 작업이 실패함Tasks fail if Visual Studio 2017 is specified but not present on agent

Visual Studio Build(Visual Studio 빌드) 및 MSBuild 작업을 통해 특정 버전의 Visual Studio를 선택할 수 있습니다.The Visual Studio Build and MSBuild tasks enable you to select a specific version of Visual Studio. 지금까지는 Visual Studio 2017 버전을 사용할 수 없는 경우 이러한 작업에서 자동으로 사용 가능한 다음 버전을 선택했습니다.Until now, if the Visual Studio 2017 version was not available, these tasks would automatically pick the next available version.

이러한 동작이 변경되었습니다.We’re changing this behavior. 이제는 Visual Studio 2017을 선택했으나 에이전트에 없는 경우 빌드가 실패합니다.Now the build will fail if you select Visual Studio 2017 but it is not present on the agent.

이렇게 변경한 이유는 다음과 같습니다.We made this change for the following reasons:

  • .NET Core와 같은 최신 앱 유형은 이전 빌드 도구로 컴파일되지 않습니다.Newer app types such as .NET Core do not compile with older build tools. 최신 앱 유형에는 Visual Studio 2017 이상이 명시적으로 필요합니다.They explicitly require Visual Studio 2017 or newer.

  • 정확히 동일한 버전의 Visual Studio를 사용하는 경우 더욱 일관성 있고 예측 가능한 결과를 얻게 됩니다.You get more consistent and predictable results when you use the same exact version of Visual Studio.

  • 빌드 작업을 대체할 때마다 이해하기 어려운 컴파일 오류가 발생할 수 있습니다.Whenever build tasks fall back, you may get compilation errors that are difficult to understand.

이전 버전의 Visual Studio만 있는 에이전트가 아니라 Visual Studio 2017이 있는 에이전트가 포함된 풀과 연결된 큐를 사용하는지 확인하세요.Make sure to use a queue connected with a pool that has agents with Visual Studio 2017, and no agents that have only earlier versions of Visual Studio.

사용자 에이전트 자동 작업 영역 정리Private agent automatic workspace cleanup

에이전트 풀을 구성하여 부실 작업 디렉터리 및 리포지토리를 정기적으로 정리할 수 있습니다 (그림 47).You can now configure an agent pool to periodically clean up stale working directories and repositories (Figure 47). 예를 들어 이 풀에서 빌드 및 릴리스 정의 삭제 후 남아 있는 작업 영역을 삭제합니다.For example, the pool will delete workspaces left behind by deleted build and release definitions.

Agent maintenance
(그림 47) 에이전트 유지 관리(Figure 47) Agent maintenance

이 옵션을 사용하면 사용자 빌드 및 릴리스 에이전트에서 디스크 공간이 부족해질 가능성이 줄어듭니다.Using this option should reduce the potential for your private build and release agents to run out of disk space. 하지만 유지 관리는 컴퓨터 단위로 수행되지 않고 에이전트 단위로 수행되므로 하나의 컴퓨터에 여러 개의 에이전트가 있으면 여전히 디스크 공간 문제가 발생할 수 있습니다.The maintenance is done per agent (not per machine), so if you have multiple agents on a single machine you could still run into disk space issues.

빌드 에이전트 업그레이드 상태Build agent upgrade status

에이전트를 업그레이드하는 경우 큐 및 풀 관리 포털에 업그레이드 상태가 표시됩니다.When an agent is being upgraded, it now indicates the status of the upgrade in the queue and pool management portal.

사용 중이 아닌 컴퓨터의 사용자 에이전트 선택Selection of private agents on machines not in use

이제 시스템에서 사용자 에이전트에 빌드 또는 릴리스를 할당할 때 컴퓨터 이름을 요소로 사용합니다.The system now uses machine name as a factor when allocating a build or a release to a private agent. 따라서 시스템에서 작업 할당 시 사용 중인 컴퓨터의 에이전트보다 유휴 컴퓨터의 에이전트가 먼저 사용됩니다.As a result, the system will prefer an agent on an idle machine over an agent on a busy machine when it allocates the job.

파이프라인 큐Pipelines queue

이제 에이전트 기반 가격 모델에서 파이프라인 기반 가격 모델로 이동했습니다.We have now moved from the agent-based pricing model to pipeline-based pricing model. 이 새 모델에서 사용자는 계정에 구성된 파이프라인 수만큼 동시에 빌드 또는 릴리스를 실행할 수 있습니다.In this new model, users can run as many builds or releases concurrently as the number of pipelines configured in their account. 이 제한을 초과하는 추가 빌드 및 릴리스는 큐에 추가되고 이전 빌드 및 릴리스가 완료될 때까지 대기합니다.Additional builds and releases beyond this limit are queued and wait for earlier builds and releases to complete. 파이프라인 큐 기능은 사용자에게 빌드 또는 릴리스가 있는 위치에 대한 추가 가시성을 제공합니다.The Pipelines queue feature provides users with more visibility into where their builds or releases are.

__파이프라인 큐__를 시작할 때 다음 정보를 볼 수 있습니다.On launching the Pipelines queue, you can see the following information:

  1. 파이프라인이 실행되기를 기다리는 빌드 및 릴리스와 대기 큐에서의 해당 위치.Builds and releases waiting for a pipeline to execute and their position in the waiting queue.
  2. 사용 가능한 파이프라인을 사용하여 현재 실행 중인 빌드 및 릴리스.Builds and releases currently running using available pipelines.

빌드/릴리스가 파이프라인을 기다리는 동안 빌드/릴리스 로그 페이지 내부에서 이 보기를 직접 시작하고 파이프라인 큐의 현재 위치 및 세부 정보를 찾을 수도 있습니다.While your build/release is waiting for a pipeline, you can also directly launch this view from inside the build/release logs page and find its current position in the pipeline queue and other details.

빌드 요약의 릴리스 작업Release action in Build summary

이제 빌드 요약 작업 표시줄에서 사용 가능한 릴리스 작업을 지원하므로 빌드에 대한 릴리스를 쉽게 만들 수 있습니다.We are now supporting a Release action, available in the Build summary action bar, so it is easy for you to create a release for a build.

변수 그룹에 대한 보안Security for variable groups

변수 그룹에 대한 보안은 이제 작성자 및 __관리자__와 같은 역할 집합을 통해 관리됩니다.Security for variable groups is now governed through a set of roles such as Creator and Administrator.

기본적으로 아래의 역할이 할당됩니다.By default, the below roles are assigned.

  • 참가자에 대한 작성자 역할Creator role to Contributors
  • 프로젝트 컬렉션 관리자, 프로젝트 관리자, 빌드 관리자 및 릴리스 관리자에 대한 관리자 역할Administrator role to Project Collection Administrators, Project Administrators, Build Administrators, and Release Administrators
  • 유효한 프로젝트 사용자에 대한 독자 역할Reader role to Valid Project Users

모든 변수 그룹 또는 특정 변수 그룹에 대한 기본값을 재정의할 수 있습니다.The defaults can be overridden for all variable groups or for a specific one.

iOS DevOps 향상iOS DevOps enhancements

Apple App Store 확장에서 이제 2단계 인증과 외부 테스터로 빌드를 릴리스하는 작업을 지원합니다 (그림 48).The Apple App Store extension now supports two-step verification (two-factor authentication) and releasing builds to external testers (Figure 48).

Apple App Store connection
(그림 48) Apple App Store 연결(Figure 48) Apple App Store connection

Apple 인증서 설치(미리 보기) 는 후속 Xcode 또는 Xamarin.iOS 빌드에서 사용할 에이전트에 P12 서명 인증서를 설치하는 새 빌드 작업입니다.Install Apple Certificate (Preview) is a new build task that installs a P12 signing certificate on the agent for use by a subsequent Xcode or Xamarin.iOS build.

Apple 프로파일 설치(미리 보기) 는 후속 Xcode 또는 Xamarin.iOS 빌드에서 사용할 프로비전 프로필을 에이전트에 설치하는 새로운 빌드 작업입니다.Install Apple Profile (Preview) is a new build task for installing provisioning profiles on the agent for use by a subsequent Xcode or Xamarin.iOS build.

이제 MSBuild, Xamarin.Android 및 Xamarin.iOS 빌드 작업에서 Mac용 Visual Studio 도구 집합을 사용한 빌드를 지원합니다.MSBuild, Xamarin.Android, and Xamarin.iOS build tasks now support building with the Visual Studio for Mac tool set.

Java 코드 검사 기능 향상Java code coverage enhancements

코드 검사 결과 게시 빌드 작업은 빌드의 일부로 Cobertura 또는 JaCoCo 코드 검사를 보고합니다.The Publish Code Coverage Results build task reports Cobertura or JaCoCo code coverage as part of a build. 이제 요약 파일보고서 디렉터리 필드에서 와일드카드 및 minimatch 패턴을 지정하여 빌드 간에 변경되는 경로에 대해 빌드 단위로 파일 및 디렉터리를 확인할 수 있습니다.It now supports specifying wildcards and minimatch patterns in Summary File and Report Directory fields, allowing the files and directories to be resolved on a per-build basis for paths that change between builds.

Maven 및 SonarQube 기능 향상Maven and SonarQube improvements

이제 Maven 빌드 작업에서 Maven pom.xml 파일에 지정된 것과 다른 경우 분석 결과에 대해 SonarQube 프로젝트를 지정할 수 있습니다.The Maven build task now allows specifying a SonarQube project for analysis results in cases where it differs from what is specified in the Maven pom.xml file.

향상된 Jenkins 통합Improved Jenkins integration

Jenkins 작업을 큐에 넣기 빌드/릴리스 작업에서 Team Services에 Jenkins 콘솔 출력을 표시하는 동시에 Jenkins 다중 분기 파이프라인 작업을 실행할 수 있습니다 (그림 49).The Jenkins Queue Job build/release task now supports running Jenkins multibranch pipeline jobs while displaying the Jenkins console output in Team Services (Figure 49). 파이프라인 결과는 Team Services 빌드 요약에 게시됩니다.Pipeline results are published to the Team Services build summary.

Improved Jenkins integration
(그림 49) 향상된 Jenkins 통합(Figure 49) Improved Jenkins integration

Azure 가상 컴퓨터 확장 집합 배포Azure virtual machine scale set deployment

배포에 사용되는 일반적인 패턴은 응용 프로그램의 각 버전에 대한 전체 컴퓨터 이미지를 만든 다음 배포하는 것입니다.A common pattern being used for deployment is to create a full machine image for each version of the application and then deploy that. 새로운 변경할 수 없는 컴퓨터 이미지 빌드 작업을 통해 더 쉽게 수행할 수 있습니다.To make that easier we have a new Build immutable machine image task. 이 작업에서는 응용 프로그램 및 모든 필수 구성 요소를 배포한 후 Packer를 사용하여 컴퓨터 이미지를 생성합니다.This task uses Packer to generate a machine image after deploying applications and all the required prerequisites. 또한 배포 스크립트나 Packer 구성 템플릿을 사용하여 컴퓨터 이미지를 만든 다음 Azure Storage 계정에 저장합니다.The task takes either the deployment script or the packer configuration template to create the machine image and stores it in an Azure Storage account. 그런 다음 이러한 유형의 변경할 수 없는 이미지 배포에서 잘 작동하는 Azure 가상 머신 확장 집합 배포에 이 이미지를 사용할 수 있습니다.This image can then be used for Azure virtual machine scale set deployments that work well with this type of immutable image deployment.

Azure 리소스 그룹 배포에서 템플릿 매개 변수 재정의Override template parameters in Azure resource group deployments

현재 Azure 리소스 그룹 배포 작업에서 사용자는 특정 구문에 따라 template.json 및 parameters.json을 선택하고 텍스트 상자에 매개 변수 재정의 값을 제공합니다.Currently in Azure resource group deployment tasks, users select the template.json and the parameters.json and provide the override parameter values in a text box, following a specific syntax. 이제 이 기능이 향상되어 템플릿 매개 변수가 편집하고 재정의할 수 있는 눈금에서 렌더링됩니다 (그림 50).This experience is now enhanced so the template parameters are rendered in a grid which allows them to be edited and overridden (Figure 50). 매개 변수 재정의 필드 옆에 있는 ... 을 클릭하여 이 기능에 액세스할 수 있습니다. 그러면 템플릿 매개 변수와 기본값 및 허용된 값(template 및 parameter .json 파일에 정의된 경우)이 함께 표시되는 대화 상자가 열립니다.You can access this feature by clicking the ... next to the override parameters field, which opens a dialog with the template parameters along with their default values and allowed values (if defined in the template and parameter .json files). 이 기능을 사용하려면 소스에서 CORS 규칙을 사용해야 합니다.This feature requires that CORS rules are enabled at the source. template 및 parameter json 파일이 Azure Storage Blob에 있는 경우 Azure Storage 서비스 설명서를 참조하여 CORS를 사용하도록 설정하세요.If template and parameter json files are in Azure storage blob, refer to the Azure Storage Services documentation to enable CORS.

Azure RG parameters
(그림 50) Azure RG 매개 변수(Figure 50) Azure RG parameters

분기 및 태그 필터가 있는 여러 릴리스 트리거Multiple release triggers with branch and tag filters

이제 Release Management에서 “빌드” 형식의 여러 아티팩트 소스에 CD 트리거를 설정할 수 있습니다.Release management now supports setting up CD triggers on multiple artifact sources of type “Build”. 추가할 경우 지정된 아티팩트 소스에 새 아티팩트 버전을 사용할 수 있으면 새 릴리스가 자동으로 생성됩니다.When added, a new release is created automatically when a new artifact version is available for any of the specified artifact sources. 새 빌드의 소스 분기를 지정하여 릴리스를 트리거할 수도 있습니다.You can also specify the source branch that the new build should be from to trigger a release. 또한 태그 필터를 설정하여 릴리스를 트리거해야 하는 빌드를 추가로 필터링할 수 있습니다.Additionally, Tag filters can be set to further filter the builds that should trigger a release.

릴리스에서 아티팩트 소스에 대한 기본값 설정Set defaults for artifact sources in a release

사용자는 정의에서 아티팩트 소스를 연결할 때 릴리스에서 배포할 기본 아티팩트 버전을 정의할 수 있습니다 (그림 51).Users can define the default artifact version to deploy in a release when linking an artifact source in a definition (Figure 51). 릴리스가 자동으로 생성되면 모든 아티팩트 소스에 대해 기본 버전이 배포됩니다.When a release is created automatically, the default version for all the artifact sources would be deployed.

Default artifact version
(그림 51) 기본 아티팩트 버전(Figure 51) Default artifact version

배포 요청자 및 승인자의 의무 분리Separation of duties for deployment requester and approvers

이전에는 릴리스 작성자가 환경에 대한 릴리스 배포를 승인하는 것을 환경 소유자가 제한할 수 있었습니다.Previously, environment owners could restrict release creators from approving deployments of the release to an environment. 그러나 다른 사용자가 만든 릴리스는 배포를 수동으로 시작하고 직접 승인할 수 있었습니다.You could, however, manually start deployment of a release created by another user, and approve it yourself.

이제 배포 작성자를 배포를 위한 별도의 사용자 역할로 간주하여 이러한 차이를 해결했습니다.We have now filled this gap by considering the deployment creator as a separate user role for deployments. 릴리스 작성자나 배포 작성자의 배포 승인을 제한할 수 있습니다.Either the release creator or deployment creator can be restricted from approving the deployments.

릴리스 수준 승인Release level approvals

이제 다른 환경에 성공적으로 배포한 후 자동으로 트리거된 배포를 자동으로 승인하도록 선택할 수 있습니다 (그림 52).You can now choose to automatically approve deployments that were automatically triggered after successful deployment to another environment (Figure 52). 일부 배포를 승인하지 않도록 선택한 경우 승인자가 동일한 일련의 배포를 한 번에 승인할 수 있습니다.Approving a chain of deployments (which have the same approvers) can be done at one go if you choose to not approve every deployment.

배포 전 승인자가 “userA”와 “userB”로 설정되고, 모두 배포를 승인해야 하는 Dev와 Test라는 두 환경이 있다고 가정해 보겠습니다.Let’s say you have two environments Dev and Test, with the predeployment approvers set to “userA” and “userB,” with both of them required to approve the deployment. Test에 대한 정책이 아래와 같이 설정된 경우 배포 시간 동안에는 userA와 userB가 Dev만 승인하기에 충분합니다.If the policy on Test is set as shown below, during deployment time it will be sufficient for userA and userB to approve only Dev. Test에 대한 배포는 자동 승인됩니다.Deployment to Test will get auto-approved. Test에 대한 배포가 수동으로 트리거될 경우 올바른 승인을 보장하려면 배포 전에 승인해야 합니다.If the deployment to Test is triggered manually, the approvals will be required before deployment to ensure correct approvals.

Release level approvals
(그림 52) 릴리스 수준 승인(Figure 52) Release level approvals

Azure Government 클라우드에 배포Deploy to Azure Government Cloud

이제 Government 클라우드에 대한 Azure 구독이 있는 고객은 국가별 클라우드를 대상으로 하도록 Azure Resource Manager 서비스 끝점을 구성할 수 있습니다.Customers with Azure subscriptions in Government Clouds can now configure Azure Resource Manager service endpoint to target national clouds.

따라서 Release Management를 사용하면 동일한 배포 작업을 통해 Government 클라우드에서 호스트되는 Azure 리소스에 응용 프로그램을 배포할 수 있습니다 (그림 53).With this, you can now use Release Management to deploy any application to Azure resources hosted in government clouds, using the same deployment tasks (Figure 53).

Government cloud
(그림 53) Government 클라우드(Figure 53) Government cloud

최대 병렬 배포 수 설정Set maximum number of parallel deployments

이 기능을 통해 보류 중인 여러 릴리스가 지정된 환경에 배포되는 방식을 제어할 수 있습니다 (그림 54).This feature gives you control on how multiple pending releases are deployed into a given environment (Figure 54). 예를 들어 릴리스 파이프라인이 QA 환경에서 빌드의 유효성 검사를 수행하는 경우 빌드 생성 속도가 배포 완료 속도보다 빠르면 여러 에이전트와 병렬로 유효성 검사되는 빌드 수를 구성할 수 있습니다.For example, if your release pipeline performs validation of builds in a QA environment and the rate of generation of builds is faster than the rate of completion of the deployments, you may configure multiple agents and as many builds to get validated in parallel. 즉, 생성된 각 빌드의 유효성을 검사하며 대기 시간은 사용 가능한 에이전트 수에 따라 달라집니다.That means each of the builds generated gets validated, and the wait time is dependent in the number of available agents. 이 기능을 사용하면 가장 최근의 n개 빌드에 대해 병렬로 유효성 검사를 수행하도록 하여 유효성 검사를 최적화하고 이전 배포 요청을 취소할 수 있습니다.With this feature, we let you optimize validations by enabling you to perform validation on the n most recent builds in parallel and cancel the older deployment requests.

Parallel deployments
(그림 54) 병렬 배포(Figure 54) Parallel deployments

수동 작업에 대한 시간 제한 향상Timeout enhancements for the Manual Intervention task

__수동 작업__은 지정된 시간 제한이나 60일 중 더 빨리 끝나는 기간에 보류 중이면 그 후에 자동으로 거부하거나 다시 시작할 수 있습니다.The Manual Intervention task can now be automatically rejected or resumed after it is pending for the specified timeout or 60 days, whichever is earlier. 시간 제한 값은 작업의 제어 옵션 섹션에서 지정할 수 있습니다.The timeout value can be specified in the control options section of the task.

Release Management 병렬 실행Release Management parallel execution

Release Management에서 단계에 대한 병렬 실행 옵션을 지원합니다 (그림 55).Release Management now supports a parallel execution option for a phase (Figure 55). 다중 구성이나 다중 에이전트를 단계 승수 옵션으로 사용하여 단계를 팬아웃하려면 이 옵션을 선택합니다.Select this option to fan out a phase by using either Multi-configuration or Multi-agent as a phase multiplier option.

Parallel execution support
(그림 55) 병렬 실행 지원(Figure 55) Parallel execution support

다중 구성: 각 다중 구성 값에 대해 단계를 실행하려면 이 옵션을 선택합니다.Multi-configuration: Select this option to run the phase for each multi-configuration value. 예를 들어 두 개의 다른 지역에 동시에 배포하려는 경우 [변수] 탭에서 “east-US, west-US” 값으로 정의된 ReleasePlatform 변수를 사용하면 값이 “east-US”인 단계와 “west-US”인 단계가 병렬로 실행됩니다.For example, if you wanted to deploy to two different geos at the same time, using a variable ReleasePlatform defined on the Variables tab with values "east-US, west-US" would run the phase in parallel, one with a value of "east-US" and the other "west-US”. 다중 에이전트: 여러 에이전트에 하나 이상의 작업이 있는 단계를 병렬로 실행하려면 이 옵션을 선택합니다.Multi-agent: Select this option to run the phase with one or more tasks on multiple agents in parallel.

Azure Portal의 웹앱 배포 기록Web app deployment history in Azure portal

App Service 배포 작업을 사용하여 배포를 수행하면 Release Management에서 Azure App Service의 배포 로그를 업데이트합니다.Release management now updates the deployment logs of Azure App Service when a deployment is done by using the App Service deployment task. Azure Portal의 App Service 블레이드에서 지속적인 업데이트 옵션을 선택하여 배포 기록을 볼 수 있습니다.You can view deployment history in the Azure portal by selecting the Continuous delivery option in the App Service blade.

테스트 기능 향상 Testing Improvements

에이전트 단계를 사용하여 테스트 실행Run tests using agent phases

__Visual Studio 테스트 작업__을 사용하면 에이전트 단계를 사용하여 자동화된 테스트를 실행할 수 있습니다 (그림 56).Using the Visual Studio Test task, you can now run automated tests using agent phases (Figure 56).

이제 빌드, 릴리스 및 테스트 전체에서 통합된 자동화 에이전트를 사용할 수 있습니다.We now have a unified automation agent across build, release and test. 이 기능은 다음과 같은 이점을 제공합니다.This brings in the following benefits:

  1. 테스트 요구 사항에 맞게 에이전트 풀을 활용할 수 있습니다.You can leverage an agent pool for your testing needs.
  2. 동일한 __Visual Studio 테스트 작업__을 사용하여 단일 에이전트 기반 실행, 다중 에이전트 기반 배포 테스트 실행, 다중 구성 실행 등 요구에 따라 다양한 모드로 테스트를 실행하여 다양한 브라우저에서 테스트를 실행합니다.—––Run tests in different modes using the same Visual Studio Test task, based on your needs—single agent–based run, multi-agent–based distributed test run or a multi-configuration run to run tests on, say, different browsers.
Run tests using Agent Phases
(그림 56) 에이전트 단계를 사용하여 테스트 실행(Figure 56) Run tests using Agent Phases

자세한 내용은 이 Microsoft 애플리케이션 수명 주기 관리 게시물을 참조하세요.For more information, refer to this Microsoft Application Lifecycle Management post.

자동화된 테스트의 요청 시 트리거On-demand triggering of automated tests

테스트 허브는 테스트 계획 및 테스트 도구 모음에서 자동화된 테스트 사례 트리거를 지원합니다 (그림 57).The Test hub now supports triggering automated test cases from test plans and test suites (Figure 57). 테스트 허브에서 자동화된 테스트를 실행하려면 릴리스 환경에서 예약된 방식으로 테스트를 실행하는 방법과 유사한 설정이 필요합니다.Running automated tests from the Test hub will need a setup similar to the way you run tests in a scheduled fashion in release environments. Run automated tests from test plans(테스트 계획에서 자동화된 테스트 실행) 템플릿을 사용하여 릴리스 정의에서 환경을 설정하고 테스트 계획을 연결하여 자동화된 테스트를 실행해야 합니다.You will need to setup an environment in the release definition using the Run automated tests from test plans template and associate the test plan to run the automated tests. 환경을 설정하고 테스트 허브에서 자동화된 테스트를 실행하는 방법에 대한 단계별 지침은 설명서를 참조하세요.See the documentation for the step by step guidance on how to setup environments and run automated tests from the Test hub.

On-demand automated tests trigger
(그림 57) 주문형 자동화된 테스트 트리거(Figure 57) On-demand automated tests trigger

웨어하우스 개선 사항 Warehouse Improvements

Analysis Services 큐브 처리의 성능 개선Performance improvements in Analysis Services cube processing

링크를 기반으로 작업 항목 트리 계층 구조 차원을 만드는 데 사용되는 vDimWorkItemTreeOverlay 보기에 대한 성능이 개선되었습니다.We’ve made performance improvements to the vDimWorkItemTreeOverlay view, which is used to create Work Item Tree Hierarchy dimension based on the links. 성능이 System.LinkTypes.Hierarchy 링크에 따라 달라지기는 하지만, 처리 기간은 다른 링크(예: System.LinkTypes.Related)의 영향도 받는 것으로 관찰되었습니다.Although it depends on System.LinkTypes.Hierarchy links, we observed that the processing duration was affected by other links as well (e.g. System.LinkTypes.Related). 읽는 데이터의 양을 제한하는 링크 형식 추가를 건너뛰도록 보기를 최적화했습니다.We optimized the view to skip addition link types which limits the amount of data read. 이 변경으로 특정 웨어하우스의 처리 시간이 크게 줄어듭니다.This change significantly decreases processing time for certain warehouses.

대/소문자를 구분하지 않는 스키마 조정Case-insensitive schema reconciliation

웨어하우스 데이터베이스의 스키마는 스키마 조정 프로세스에서 모든 연결된 컬렉션 데이터베이스의 필드를 병합하여 만듭니다.The schema of the warehouse database is created by merging fields from all the attached collection databases in the schema reconciliation process. 이전에는 모든 비교에서 대/소문자를 구분했으며 관리자가 필드 참조 이름에 대한 정확한 일치가 있는지 확인해야 했습니다.Previously, all comparisons were case-sensitive and administrators had to make sure there is an exact match on field reference names. 따라서 대/소문자에 미묘한 차이가 있는 경우 문제가 되었습니다.This led to problems where there were subtle differences in casing. 이 릴리스에서는 해당 프로세스에서 이러한 불일치가 좀 더 허용됩니다.With this release we make the process more tolerant to such discrepancies.

관리 기능 향상 Administration Improvements

알림을 위한 전자 메일 받는 사람 결합Combined email recipients for notifications

동일한 전자 메일 알림을 받는 사람이 받는 사람: 줄에 함께 포함되며 단일 전자 메일이 전송됩니다.Recipients for the same email notification are now included together on the to: line and sent a single email. 이전에는 개별 전자 메일이 각각 받는 사람에게 전송되었습니다.Previously, individual emails were sent to each recipient. 따라서 알림을 받은 다른 사용자를 파악하고 전자 메일을 통해 이벤트에 대해 대화를 나누기가 어려웠습니다.This made it difficult to know who else received the notification and to have a conversation about the event over email. 이 기능은 여러 받는 사람을 대상으로 할 수 있는 팀 구독뿐만 아니라 기본 알림에도 적용됩니다.This feature applies to out-of-the-box as well as team subscriptions that are capable of targeting multiple recipients. 예를 들어 끌어오기 요청을 변경하면 끌어오기 요청의 모든 검토자에게 단일 전자 메일이 전송됩니다.For example, all reviewers of a pull request are now sent a single email when a change is made to the pull request.

전자 메일 받는 사람 결합에 대해 자세히 알아보세요.Learn more about combining email recipients.

기본 알림Out-of-the-box notifications

사용자와 팀은 다음과 같이 사용자 및 팀과 직접 관련된 작업이 계정에 있는 경우 전자 메일을 통해 자동으로 알림을 받습니다.Users and teams are now automatically notified via email when there is activity in the account directly relevant to them, such as:

  • 작업 항목이 사용자에게 할당된 경우when a work item is assigned to a user.
  • 사용자나 팀이 검토자로 끌어오기 요청에 추가된 경우when a user or team is added as a reviewer to a pull request.
  • 사용자나 팀이 업데이트되는 끌어오기 요청에서 검토자인 경우when a user or team is a reviewer on a pull request that is updated.
  • 다른 사용자가 끌어오기 요청 설명에 응답하는 경우when another user responds to a pull request comment.
  • 사용자가 요청한 빌드가 완료된 경우when a build requested by a user completes.
  • 확장이 설치되거나 요청된 경우(관리자 전용)when an extension is installed or requested (admins only).

사용자는 사용자 프로필 메뉴 아래의 알림 설정으로 이동한 다음 적절한 토글을 전환하여 이러한 구독을 취소할 수 있습니다.Users can unsubscribe from any of these subscriptions by going to Notification settings under the user profile menu and then switching off the appropriate toggle(s).

계정 관리자는 설정 기어 아래의 컬렉션 수준 알림 허브로 이동하여 이러한 자동 구독 중 하나 이상을 사용하지 않도록 설정할 수 있습니다.An account admin can disable one or more of these automatic subscriptions by navigating to the collection-level Notifications hub under the settings gear. 이러한 구독은 “...”작업에서 __사용 안 함__을 클릭하여 사용하지 않도록 설정할 수 있습니다.Any of these subscriptions can be disabled by clicking Disable under the "..." action. 구독을 사용하지 않도록 설정하면 사용자의 개인 알림 설정 페이지에 더 이상 나타나지 않습니다.Once a subscription is disabled, it will no longer appear for users in their personal notification settings page.

기본 알림에 대해 자세히 알아보세요.Learn more about out-of-the-box notifications.

확장 관리 권한Extension management permissions

관리자는 컬렉션의 확장을 관리할 수 있는 권한을 다른 사용자 및 그룹에 부여할 수 있습니다 (그림 58).An admin can now grant other users and groups permission to manage extensions for the collection (Figure 58). 이전에는 컬렉션 관리자(예: Project Collection Administrators 그룹의 멤버)만 확장 요청을 검토하거나, 확장을 설치하거나, 사용하지 않도록 설정하거나, 제거할 수 있었습니다.Previously only collection administrators (i.e. members of the Project Collection Administrators group) could review extension requests, install, disable, or uninstall extensions.

이 권한을 부여하려면 관리자는 Marketplace 메뉴를 열고 [확장 관리]를 선택하여 확장 관리 허브로 이동한 다음 보안 단추를 클릭할 수 있습니다.To grant this permission, an administrator can navigate to the Extensions admin hub by opening the Marketplace menu, selecting Manage extensions, and then click the Security button:

Extension management permissions
(그림 58) 확장 관리 권한(Figure 58) Extension management permissions

확장이 설치된 경우, 주의가 필요한 경우 등에 대한 알림 받기Getting notified when extensions are installed, require attention, and more

관리자 또는 확장을 관리할 수 있는 사용자는 확장을 설치하거나, 제거하거나, 사용하도록 설정하거나, 사용하지 않도록 설정하는 경우 자동으로 알림을 받습니다.Admins, or those with the ability to manage extensions, are now automatically notified when an extension is installed, uninstalled, enabled, disabled, or requires attention. 이 기능은 여러 사용자가 확장을 관리할 책임이 있는 대규모 배포에서 특히 유용합니다.This is especially useful in larger deployments where multiple people have the responsibility of managing extensions. 관리자는 프로필 메뉴 아래의 알림 설정으로 이동하고 확장 토글을 전환하여 이러한 알림을 끌 수 있습니다.Admins can turn off these notifications by navigating to Notification settings under the profile menu and switching off the extensions toggle.

또한 관리자는 확장 관련 이벤트에 대해 사용자 정의 구독을 정의할 수 있습니다.Admins can also define custom subscriptions for extension-related events. 예를 들어 관리자는 모든 확장이 업데이트될 때마다 알림을 받을 수 있습니다.For example, an admin can get notified whenever any extension is updated.

또한 사용자는 해당 확장 요청에 대한 자동 알림을 끌 수도 있습니다.Users can also now turn off automatic notifications about their extension requests.

TFS 관리자가 고급 액세스 수준에 구독자를 추가하도록 허용Allowing TFS admins to add subscribers to the advanced access level

고급 액세스 수준은 Team Foundation Server 이후 버전에서 제거됩니다.The Advanced access level will be removed from future versions of Team Foundation Server. 그러나 그때까지 TFS 관리자는 업데이트 2를 사용하여 MSDN 플랫폼 및 Visual Studio Test Professional 구독자를 고급 액세스 수준에 추가할 수 있습니다.However, until that happens, TFS admins will have the ability to add MSDN Platform and Visual Studio Test Professional subscribers to the Advanced access level with Update 2.

Visual Studio Enterprise 구독자는 고급 대신 Visual Studio Enterprise 액세스 수준에 추가해야 합니다.Visual Studio Enterprise subscribers should be added to the Visual Studio Enterprise access level instead of Advanced. 테스트 관리자 확장을 구매한 경우 구매한 팀 프로젝트 내의 사용자 허브에서 계속 관리할 수 있습니다.If you have purchased the Test Manager extension, please continue to manage this in the Users hub within the Team Project that you made the purchase.

Microsoft Teams 통합 Microsoft Teams Integration

Microsoft Teams를 사용하여 공동 작업하는 조직은 이제 팀 채널 내에서 해당 TFS 프로젝트의 활동을 볼 수 있습니다.Organizations using Microsoft Teams to collaborate can now see activity from their TFS projects within their team’s channels. 따라서 팀은 Microsoft Teams에서 작업할 때 관련 작업 항목 변경, 끌어오기 요청, 빌드, 릴리스 등에 대한 최신 정보를 확인할 수 있습니다.This allows teams to stay informed about relevant work item changes, pull requests, builds, and releases and more as they are working in Microsoft Teams. 자세한 내용은 설명서를 참조하세요.For more information see our documentation.


알려진 문제Known Issues

작업 항목 폼이 웹에서 제대로 렌더링되지 않음Work item forms do not render correctly in the web

  • 문제:Issue:

    다중값 컨트롤과 같은 사용자 지정 컨트롤을 웹 클라이언트가 아닌 Visual Studio 클라이언트에 대해 설치한 경우 웹에서 작업 항목 폼을 렌더링할 수 없습니다.If you have a custom control, such as the multi-value control, installed for the Visual Studio client but not the web client, work item forms in the web fail to render.

  • 해결 방법:Workaround:

    최신 버전의 컨트롤로 업데이트해야 합니다.You will need to update to the latest version of your control. 누락된 컨트롤 요소를 포함하지 않는 웹 레이아웃을 추가해야 합니다.It is necessary to add a web layout that doesn’t contain the missing control element. TFS 작업 항목 추적을 위한 사용자 지정 컨트롤 페이지에서 TFS 2017 업데이트에 대한 최신 다중 값 컨트롤을 찾을 수 있습니다.You can find the latest multi-value control for TFS 2017 Update on the Custom Controls for TFS Work Item Tracking page. 레이아웃에 대한 자세한 내용은 All FORM XML elements reference (TFS 2015)(모든 FORM XML 요소 참조(TFS 2015)) 페이지를 참조하세요.For more information on the layout, see All FORM XML elements reference (TFS 2015) page.

TFS 버전이 최종 릴리스가 아니라 RC2입니다.TFS version is RC2 instead of the final release

  • 문제:Issue:

    2017년 8월 1일 전에 TFS 2017 업데이트 2를 다운로드하고 설치하면 RC2 버전이 설치됩니다.After downloading TFS 2017 Update 2 before August 1, 2017, and installing, you have an RC2 version.

  • 해결 방법:Workaround:

    이 문제는 2017년 8월 1일에 수정된 설치 링크의 일시적인 문제 때문입니다.This was due to an intermittent issue in the installation links that was fixed on August 1, 2017. TFS 2017 업데이트 2를 다시 다운로드하고 이 최종 릴리스를 설치하세요.Please redownload TFS 2017 Update 2 and install this final release.


The Developer Community Portal Team Foundation Server 2017에 대해 고객이 보고한 문제를 참조하세요. See customer-reported issues reported for Team Foundation Server 2017.


위쪽
Top of Page