Team Foundation Server 2018 업데이트 2 릴리스 정보Team Foundation Server 2018 Update 2 Release Notes


Developer Community | 시스템 요구 사항 및 호환성 | 사용 조건 | TFS DevOps 블로그 | SHA-1 해시 | | 최신 Visual Studio 2019 릴리스 정보Developer Community | System Requirements and Compatibility | License Terms | TFS DevOps Blog | SHA-1 Hashes | | Latest Visual Studio 2019 Releases 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 change the language of this page by clicking the globe icon in the page footer and selecting your desired language.


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

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. visualstudio.com/downloads 페이지를 방문하여 다른 TFS 2018 제품을 다운로드하세요.Visit the visualstudio.com/downloads page to download other TFS 2018 products.

TFS 2012 이상에서 Team Foundation Server 2018 업데이트 2로 바로 업그레이드할 수 있습니다.Direct upgrade to Team Foundation Server 2018 Update 2 is supported from TFS 2012 and newer. TFS 배포가 TFS 2010 이하인 경우 TFS 2018 업데이트 2로 업그레이드하기 전에 중간 단계를 수행해야 합니다.If your TFS deployment is on TFS 2010 or earlier, you need to perform some interim steps before upgrading to TFS 2018 Update 2. 자세한 정보는 아래 차트 및 TFS 설치 페이지를 참조하세요.Please see the chart below and the TFS Install page for more information.

TFS Upgrade Matrix
TFS 업그레이드 행렬TFS Upgrade Matrix

중요

TFS 2018 업데이트 2로 업그레이드하기 전에 TFS 2018 RTM으로 업그레이드할 필요가 없습니다.You do not need to upgrade to TFS 2018 RTM before upgrading to TFS 2018 Update 2.


Release Notes Icon 릴리스 날짜: 2018년 5월 7일Release Date: May 7, 2018

이제 TFS 2018 업데이트 2로 업그레이드하고, XAML 컨트롤러를 연결하고, XAML 빌드를 계속 실행할 수 있습니다.You can now upgrade to TFS 2018 Update 2 and continue to connect your XAML controllers and run XAML builds. TFS 2018 RTW 및 업데이트 1에서 XAML 빌드에 대한 지원을 제거한 경우, 일부 사용자는 레거시 XAML 빌드로 인해 업그레이드할 수 없어 차단을 해제하려고 합니다.When we removed support for XAML build in TFS 2018 RTW and Update 1, some of you could not upgrade due to having legacy XAML builds, and we want to unblock you. TFS 2018 업데이트 2는 기존 빌드에 대한 XAML 빌드를 지원하지만, XAML 빌드는 더 이상 사용되지 않아 더 이상 투자할 필요가 없기 때문에 최신 빌드 정의 형식으로 변환하는 것이 좋습니다.Although TFS 2018 Update 2 supports XAML builds for your legacy builds, XAML build is deprecated and there will be no further investment, so we highly recommend converting to a newer build definition format.

TFS 2018 업데이트 2의 새로운 기능에 대한 요약Summary of What's New in TFS 2018 Update 2

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


TFS 2018 업데이트 2의 새로운 기능에 대한 세부 정보Details of What's New in TFS 2018 Update 2

기능에 대한 세부 정보를 확인할 수 있는 각 영역은 다음과 같습니다.You can find details about features in each area:

코드Code

파일을 볼 때 일반적으로 선택한 분기의 팁에 버전이 표시됩니다.When viewing a file, you usually see the version at the tip of the selected branch. 팁의 파일 버전은 새 커밋으로 변경될 수 있습니다.The version of a file at the tip may change with new commits. 이 보기에서 링크를 복사하면 커밋 SHA가 아닌 분기 이름만 URL에 포함되므로 부실 링크가 될 수 있습니다.If you copy a link from this view, your links can become stale because the URL only includes the branch name, not the commit SHA. 이제는 파일 보기를 쉽게 전환하여 분기 대신 커밋을 참조하도록 URL을 업데이트할 수 있습니다.You can now easily switch the Files view to update the URL to refer to the commit rather than the branch. “y” 키를 누르면 보기가 현재 분기의 팁 커밋으로 전환됩니다.If you press the "y" key, your view switches to the tip commit of the current branch. 그런 다음, 영구 링크를 복사할 수 있습니다.You can then copy permanent links.

API를 통해 최근에 삭제된 리포지토리 복구Recover a recently-deleted repository through API

소스 제어에서 오래된 리포지토리를 정리할 때 경우에 따라 실수를 할 수 있습니다.Sometimes mistakes can be made when cleaning up old repositories in source control. Git 리포지토리가 지난 30일 이내에 삭제된 경우 REST API를 통해 복구할 수 있습니다.If a Git repository is deleted within the last 30 days, it can be recovered through the REST API. 자세한 내용은 목록복구 작업에 대한 설명서를 참조하세요.See the documentation for the list and recover operations for more information.

SSH: 추가 암호화/키 지원 및 오래된 암호화 사용 중단SSH: Support additional ciphers/keys and deprecate outdated ciphers

보안과 호환성을 향상하기 위해 SSH에 지원되는 암호화 목록을 업데이트했습니다.To improve security and compatibility, we have updated the list of ciphers supported for SSH. OpenSSH의 지침에 따라 2개의 새 암호화와 3개의 사용되지 않는 암호화를 추가했습니다.We have added two new ciphers and deprecated three, matching OpenSSH's direction. 사용되지 않는 암호화는 이 릴리스에서 계속 작동하지만,The deprecated ciphers continue to work in this release. 나중에 사용량이 떨어지면 제거됩니다.They will be removed in the future as usage falls off.

추가됨:Added:

  • AES128 CTRAES128 CTR
  • AES256 CTRAES256 CTR

사용되지 않음:Deprecated:

  • AES128AES128
  • AES192AES192
  • AES256AES256

리포지토리 설정을 사용하여 성능 덮어쓰기 및 보호 방지Avoid overwrites and protect performance using repository settings

이 업데이트에는 Git가 원활하게 실행될 수 있도록 하는 새로운 두 가지 리포지토리 설정이 있습니다.In this Update, you will find two new repository settings to help keep Git running smoothly.

대/소문자 적용 은 서버를 기본 대/소문자 구분 모드(“File.txt” 및 “file.txt”에서 동일한 파일을 참조함)에서 Windows 및 macOS에 친숙한 모드(“File.txt” 및 “file.txt”가 동일한 파일임)로 전환합니다.Case enforcement switches the server from its default case-sensitive mode, where "File.txt" and "file.txt" refer to the same file, to a Windows and macOS-friendly mode where "File.txt" and "file.txt" are the same file. 이 설정은 파일, 폴더, 분기 및 태그에 영향을 줍니다.This setting affects files, folders, branches, and tags. 또한 참가자가 소문자만 구분을 실수로 도입하지 않도록 방지합니다.It also prevents contributors from accidentally introducing case-only differences. 대부분의 참가자가 Windows 또는 macOS를 실행하는 경우 대/소문자 적용을 사용하는 것이 좋습니다.Enabling case enforcement is recommended when most of your contributors are running Windows or macOS.

파일 크기 제한 을 사용하면 새 파일 또는 업데이트된 파일이 설정한 크기 제한을 초과하지 않도록 방지할 수 있습니다.Limit file sizes allows you to prevent new or updated files from exceeding a size limit you set. Git 리포지토리의 기록에 존재하는 큰 파일의 수가 많을수록 복제 및 페치 작업의 성능이 저하됩니다.The greater number of large files that exist in a Git repository's history, the worse clone and fetch operation performance becomes. 이 설정은 실수로 이러한 파일을 도입하지 않도록 방지합니다.This setting prevents accidental introduction of these files.

대/소문자 적용case enforcement

변경된 파일이 1,000개 이상 있는 커밋에 대해 향상된 필터링 기능Enhanced filter capability for commits with more than 1000 files changed

1,000개가 넘는 파일을 수정한 커밋 또는 끌어오기 요청에서 파일을 검색하는 것이 비효율적이기 때문에 관심이 있는 파일을 찾는 데 추가 로드 링크를 여러 번 클릭해야 했습니다.Searching for a file in commits or pull requests that have modified more than 1000 files was inefficient; you would need to click on Load more link several times to find the file that you were interested in. 이제는 트리 보기에서 콘텐츠를 필터링하는 경우 로드된 상위 1,000개 파일을 살펴보는 대신 커밋의 모든 파일에서 해당 파일을 검색합니다.Now, when you filter content in the tree view, the search for that file is done across all files in the commit instead of just looking at the top 1000 files loaded. 1,000개가 넘는 파일이 수정되는 경우에도 커밋 세부 정보 페이지의 성능이 향상됩니다.The performance of the commit details page is also improved when there are more than 1000 files modified.

강제 푸시로 인해 손실된 커밋 찾기Find lost commits due to a Force Push

로컬 참조의 상위 요소가 아니더라도 Git 강제 푸시를 수행하고 원격 참조를 업데이트할 수 있습니다. 이로 인해 다른 사용자가 커밋을 잃을 수 있으며 근본 원인을 식별하기가 매우 어려울 수 있습니다.You can perform a Git force push and update a remote ref even if it is not an ancestor of the local ref. This may cause others to lose commits and it can be very hard to identify the root cause. 누락된 커밋과 관련된 문제를 해결하는 데 도움이 되도록 새 푸시 보기에 강제 푸시를 눈에 띄게 만들었습니다.In the new pushes view, we have made force pushes noticeable in order to help troubleshoot issues related to missing commits.

강제 푸시force push

강제 푸시 태그를 클릭하면 제거된 커밋으로 이동합니다.Clicking on the force push tag takes you to the removed commit.

제거된 커밋removed commits

이제는 기록되는 원인Blame now has history

원인 보기는 코드 줄을 마지막으로 변경한 사용자를 식별하는 데 유용합니다.The Blame view is great for identifying the last person to change a line of code. 그러나 코드 줄을 이전 에 변경한 사용자를 알아야 하는 경우가 있습니다.However, sometimes you need to know who made the previous change to a line of code. 향상된 최신 기능인 이 커밋 전에 원인 보기 가 도움이 될 수 있습니다.The newest improvement in blame can help - View blame prior to this commit. 이름에서 알 수 있듯이, 이 기능을 사용하면 특정 줄을 변경한 버전 이전의 파일 버전으로 다시 이동하여 해당 버전에 대한 원인 정보를 볼 수 있습니다.As the name suggests, this feature allows you to jump back in time to the version of the file prior to the version that changed a particular line, and view the blame info for that version. 선택한 코드 줄이 변경된 파일에 맞춰 각 버전을 살펴보면서 계속 드릴할 수 있습니다.You can continue to drill back in time looking at each version of the file that changed the selected line of code.

원인 기록Blame history

diff 보기에서 자동 줄 바꿈 설정/해제 및 공백 토글Toggle word wrap and white space in diff views

파일 diff 뷰어에서 사용할 수 있는 두 가지 기능은 다음과 같습니다. 자동 줄 바꿈 설정/해제공백 설정/해제.Two new features are available in the file diff viewer: Toggle Word Wrap and Toggle White Space. 첫 번째 기능은 diff 보기에서 단어 줄 바꿈 설정을 적용할 수 있게 합니다.The first allows the word wrap setting to be applied while in a diff view. 이는 줄 바꿈이 빈번하지 않은 파일이 포함된 PR을 검토할 때 특히 유용하며, 마크다운 파일이 좋은 예입니다.This is particularly useful for reviewing PRs that contain files without frequent line breaks - markdown files are a good example. 공백 토글 옵션은 줄 또는 파일에서 공백만 변경하는 경우에 유용합니다.The option to toggle white space is helpful when only whitespace has changed in a line or file. 이 설정을 토글하면 diff에서 공백 문자(공백의 점, 탭의 화살표 등)가 강조 표시됩니다.Toggling this setting displays and highlights the whitespace characters (dots for spaces, arrows for tabs, etc.) in the diff.

이러한 설정을 관리하려면 끌어오기 요청 편집기 또는 diff 보기에서 편집기 기본 설정 기어 아이콘을 클릭합니다.To manage these settings, click on the editor preferences gear in the pull request editor or diff view. 파일 보기의 오른쪽 클릭 메뉴에서 사용자 기본 설정 옵션을 선택합니다.In the Files view, select the User Preferences option on the right-click menu.

편집기 기어 아이콘Editor gear

공백 표시 및 차이 표시, 자동 줄 바꿈 사용, 코드 접기 사용미니맵 표시 와 같은 다양한 편집기 기능을 선택합니다.Select the various editor features including Show and diff white space, Enable word wrap, Enable code folding, and Show minimap.

편집기 성능Editor perfs

코드 접기(일부 편집기에서는 “개요”라고 함)는 웹 보기에서도 사용할 수 있습니다.Code folding (called "outlining" in some editors) is also being enabled for the web view. 코드 접기를 사용하도록 설정하면, 빼기 기호를 클릭하여 코드 섹션을 접고 더하기 기호를 클릭하여 접힌 섹션을 펼칩니다.When code folding is enabled, click on the minus signs to collapse sections of code -- click on plus signs to expand collapsed sections. 또한 F1 명령 팔레트는 전체 파일에서 다양한 들여쓰기 수준을 접을 수 있는 옵션을 제공하므로 큰 파일을 더 쉽게 읽고 검토할 수 있게 합니다.The F1 command palette also exposes options for folding various indentation levels across an entire file, making it easier to read and review large files.

코드 접기Code folding

빌드 및 릴리스에 대해 Git 리포지토리에 푸시하는 트랙 코드Track code pushes to a Git repo to builds and releases

이제 푸시 페이지에 병합 커밋의 빌드 및 릴리스 상태가 표시됩니다.Now you can view the build and release status of merge commits in the Pushes page. 푸시 옆에 있는 상태를 클릭하면 성공을 확인하거나 실패를 조사할 수 있도록 푸시가 포함된 특정 빌드 또는 릴리스가 표시됩니다.By clicking the status next to the push, you will find the specific build or release that the push is included in so that you can verify success or investigate failure.

CI-CD 상태 푸시Pushes ci-cd status

이메일 알림에 렌더링된 마크다운Rendered markdown in email notifications

마크다운은 다양한 서식, 링크 및 이미지를 PR(끌어오기 요청) 설명 및 주석에 추가하는 데 유용합니다.Markdown is great for adding rich formatting, links, and images in pull request (PR) descriptions and comments. 이제 PR에 대한 이메일 알림에 원시 콘텐츠 대신 렌더링된 값이 표시되어 가독성이 향상되었습니다.Email notifications for PRs now display the rendered markdown instead of the raw contents, which improves readability.

인라인 이미지는 아직 인라인으로 렌더링되지 않지만(단지 링크로만 표시됨), 나중에 추가할 수 있도록 백로그로 유지하고 있습니다.Inline images are not yet rendered inline (they are just shown as links), but we have that on our backlog to add in the future.

PR 알림 마크다운PR notification markdown

Windows 탐색기에서 바로 수행하는 TFVC 명령Perform TFVC commands right from Windows Explorer

Windows 파일 탐색기에 통합된 경량 버전 제어 환경을 제공하는 TFVC Windows 셸 확장은 이제 TFS 2018을 지원합니다.The TFVC Windows Shell Extension, that gives a lightweight version control experience integrated into Windows File Explorer, now supports TFS 2018. 이 도구는 Windows 탐색기 바로 가기 메뉴에서 직접 다양한 TFVC 명령에 편리하게 액세스할 수 있습니다.This tool gives convenient access to many TFVC commands right in the Windows Explorer context menu.

TFS 성능 도구의 일부였던 이 도구는 Visual Studio Marketplace에서 독립 실행형 도구로 릴리스되었습니다.Formerly part of the TFS Power tools, the tool has been released as a standalone tool on the Visual Studio Marketplace.

셸 확장Shell extension

끌어오기 요청에 참여할 수 있는 컨트롤Control who can contribute to pull requests

이전에는 Git 리포지토리를 볼 수 있는 사용자는 모두 끌어오기 요청을 처리할 수 있었습니다.Previously, anyone who could view a Git repository could work with its pull requests. 끌어오기 요청 만들기 및 주석 처리에 대한 액세스를 제어하는 끌어오기 요청에 참여 라는 새 권한이 추가되었습니다.We have added a new permission called Contribute to pull requests that controls access to creating and commenting on pull requests. 이 새 권한은 이전에 읽기 권한을 보유한 모든 사용자 및 그룹에도 기본적으로 부여됩니다.All users and groups that previously held the Read permission are also granted this new permission by default. 이 새 권한의 도입에 따라 추가적인 유연성과 제어 기능이 관리자에게 제공됩니다.The introduction of this new permission gives administrators additional flexibility and control. Readers(읽기 권한자) 그룹이 진정으로 읽기 전용이 되어야 하는 경우 끌어오기 요청에 참여 권한을 거부할 수 있습니다.If you require your Readers group to be truly read-only, you can deny the Contribute to pull requests permission.

자세한 내용은 리포지토리 권한 설정에 대한 빠른 시작 설명서를 참조하세요.See the quickstart documentation for setting repository permissions for more information.

스레드 컨텍스트가 포함된 끌어오기 요청 주석 알림Pull request comment notifications include the thread context

대부분의 경우 PR(끌어오기 요청)에 대한 응답은 매우 간단하며 변경 내용이 있거나 적용되었음을 인정합니다.Many times, replies to pull request (PR) comments are pretty brief, acknowledging that a change will be or has been made. 웹 보기에 이러한 주석이 표시되면 문제가 되지 않지만, 이메일 알림에서 주석을 읽는 경우 원래 주석의 컨텍스트가 손실됩니다.This is not a problem when viewing these comments in the web view, but if you are reading a comment in an email notification, the context of the original comment is lost. 이는 간단하게 해결할 수 있는 문제가 아닙니다.A simple "I'll fix it" has no meaning.

이제는 PR 주석에 응답할 때마다 주석 이메일의 이메일 메시지 본문에 이전 회신이 포함됩니다.Now, whenever a reply is made to a PR comment, the comment emails include the prior replies in the body of the email message. 이렇게 하면 스레드 참가자가 받은 편지함에서 주석의 전체 컨텍스트를 직접 볼 수 있으므로 웹 보기를 열 필요가 없습니다.This allows the thread participants to see the full context of the comment right from their inbox - no need to open the web view.

PR 주석 알림 스레드PR comment notifications thread

작업 항목 설정 완료Complete work items settings

끌어오기 요청을 완료할 때 작업 항목을 완료하는 기능에는 이제 기본 동작을 제어하는 새 리포지토리 설정이 있습니다.The feature to complete work items when completing pull requests now has a new repository setting to control the default behavior. 끌어오기 요청으로 작업 항목을 완료하기 위한 사용자 기본 설정을 기억합니다 에 대한 새 설정은 기본적으로 사용하도록 설정되어 있으며, 나중에 리포지토리에서 끌어오기 요청을 완료할 때 사용자의 마지막 상태를 유지합니다.The new setting to Remember user preferences for completing work items with pull requests is enabled by default, and honors the user's last state when completing future pull requests in the repo. 새 설정을 사용하지 않도록 설정되면 병합 후 연결된 작업 항목 완료 옵션도 리포지토리의 모든 끌어오기 요청에 대해 기본적으로 사용하지 않도록 설정됩니다.If the new setting is disabled, then the Complete linked work items after merging option defaults to disabled for all pull requests in the repository. 사용자는 PR을 완료할 때 연결된 작업 항목을 전환하도록 선택할 수 있지만 매번 옵트인해야 합니다.Users can still choose to transition linked work items when completing PRs, but they will need to opt-in each time.

끌어오기 요청 상태 확장성Pull request status extensibility

분기 정책은 코드의 품질을 높이는 좋은 방법이 될 수 있습니다.Using branch policies can be a great way to increase the quality of your code. 그러나 이러한 정책은 TFS에서 기본적으로 제공하는 통합으로만 제한되었습니다.However, those policies have been limited to only the integrations provided natively by TFS. 새로운 끌어오기 요청 상태 API 및 해당 분기 정책을 사용하여 네이티브 TFS 기능과 마찬가지로 타사 서비스에서 끌어오기 요청 워크플로에 참여할 수 있습니다.Using the new pull request Status API and the corresponding branch policy, third party services can participate in the pull request workflow just like native TFS features.

서비스가 끌어오기 요청에 대한 상태 API에 게시되면 새 상태 섹션의 PR 세부 정보 보기에 바로 나타납니다.When a service posts to the Status API for a pull request, it immediately appears in the PR details view in a new Status section. 상태 섹션은 해당 설명을 표시하고 서비스에서 제공하는 URL에 대한 링크를 만듭니다.The status section shows the description and creates a link to the URL provided by the service. 상태 항목은 웹 확장에서 추가할 새 작업에 대해 확장할 수 있는 작업 메뉴(...)도 지원합니다.Status entries also support an action menu (...) that is extensible for new actions added by web extensions.

상태 섹션status section

상태만으로는 PR의 완료를 차단할 수 없습니다. 정책이 필요합니다.Status alone does not block completion of a PR - that is where the policy comes in. PR 상태가 게시되면 정책을 구성할 수 있습니다.Once PR status has been posted, a policy can then be configured. 분기 정책 환경에서 외부 서비스의 승인을 요구 할 때 새 정책을 사용할 수 있습니다.From the branch policies experience, a new policy is available to Require approval from external services. +서비스 추가 를 선택하여 프로세스를 시작합니다.Select + Add service to begin the process.

상태 정책 추가status policy add

대화 상자의 목록에서 상태를 게시하는 서비스를 선택하고 원하는 정책 옵션을 선택합니다.In the dialog, select the service that is posting the status from the list and select the desired policy options.

상태 정책 대화 상자status policy dialog

정책이 활성화되면 정책 섹션의 필수 또는 옵션 에 상태가 적절히 표시되고 PR 완료가 적절히 적용됩니다.Once the policy is active, the status is shown in the Policies section, under Required or Optional as appropriate, and the PR completion is enforced as appropriate.

상태 API에 대해 자세히 알아보고 직접 사용해 보려면 설명서샘플을 확인해 보세요.To learn more about the status API, and to try it out for yourself, check out the documentation and samples.

끌어오기 요청 서비스 후크 병합 이벤트Pull request service hooks merge events

끌어오기 요청 서비스 후크를 사용하는 확장에는 이제 병합 이벤트에 대한 세부 정보 및 필터링 옵션이 있습니다.Extensions using pull request service hooks now have more details and filtering options for merge events. 병합이 시도될 때마다 병합의 성공 또는 실패와 관계없이 이벤트가 발생합니다.Any time a merge is attempted, the event is fired regardless of the success or failure of the merge. 병합 시도가 실패하면 실패한 원인에 대한 세부 정보가 포함됩니다.When a merge attempt results in a failure, details about the reason for the failure is included.

PR 서비스 후크 병합 이벤트PR service hooks merge events

끌어오기 요청으로 완료된 작업 항목에 대해 향상된 오류 메시지Improved error messages for work items completing with a pull request

끌어오기 요청으로 작업 항목을 완료하려고 할 때 연결된 작업 항목이 완료됨 상태로 전환되지 않을 수 있습니다.When attempting to complete work items with a pull request, it is possible that the associated work item cannot be transitioned to the completed state. 예를 들어 특정 필드가 필요할 수 있으며 상태를 전환하기 전에 사용자 입력이 필요합니다.For example, a specific field might be required and needs user input before the state can transition. 작업 항목 전환을 차단하는 항목이 있는 경우 이를 알려줌으로써 필요한 변경 작업을 수행할 수 있도록 환경이 향상되었습니다.We have improved the experience to inform you when something is blocking the work item transition, enabling you to take action to make the necessary changes.

작업 항목 PR 오류Error work items PR

끌어오기 요청에 대한 언급Mention a pull request

이제 PR 주석 및 작업 항목 토론에서 끌어오기 요청을 언급할 수 있습니다.You can now mention pull requests in PR comments and work item discussions. PR을 언급하는 환경은 작업 항목의 환경과 비슷하지만 해시 표시(#) 대신 느낌표(!)를 사용합니다.The experience for mentioning a PR is similar to that of a work item, but uses an exclamation point ! instead of a hash mark #.

PR을 언급하려고 할 때마다 !를 입력하면 최근 PR 목록에서 PR을 선택할 수 있는 대화형 환경이 표시됩니다.Whenever you want to mention a PR, enter a !, and you will see an interactive experience for picking a PR from your list of recent PRs. 제안 목록을 필터링하기 위한 키워드를 입력하거나 언급하려는 PR의 ID를 입력합니다.Enter keywords to filter the list of suggestions, or enter the ID of the PR you want to mention. PR이 언급되면 ID 및 전체 제목이 있는 인라인으로 렌더링되며 PR 세부 정보 페이지에 연결됩니다.Once a PR is mentioned, it is rendered inline with the ID and the full title, and it will link to the PR details page.

끌어오기 요청에 대한 언급Mention a pull request

끌어오기 요청 레이블을 사용하여 검토자 지원Help reviewers using pull request labels

끌어오기 요청에 대한 추가 정보를 검토자에게 전달하는 것이 중요한 경우도 있습니다.Sometimes it is important to communicate extra information about a pull request to the reviewers. 끌어오기 요청은 아직 진행 중인 작업이거나 예정된 릴리스에 대한 핫픽스일 수 있으므로 제목에 추가 텍스트(예: “[WIP]” 접두사 또는 “병합 안 함”)를 추가할 수 있습니다.Maybe the pull request is still a work in progress, or it is a hotfix for an upcoming release - so you append some extra text in the title, perhaps a "[WIP]" prefix or "DO NOT MERGE". 이제 레이블은 중요한 세부 정보를 전달하고 끌어오기 요청을 구성하는 데 사용할 수 있는 추가 정보를 사용하여 끌어오기 요청에 태그를 지정하는 방법을 제공합니다.Labels now provide a way to tag pull requests with extra information that can be used to communicate important details and help organize pull requests.

PR 요청 레이블PR request labels

이름이 바뀐 파일에 기반한 끌어오기 요청 주석Pull request comments follow renamed files

끌어오기 요청이 활성 상태인 동안 파일 이름이 변경되거나 파일이 이동되는 경우가 있습니다.Sometimes files are renamed or moved while a pull request is active. 이전에는 이름이 바뀐 파일에 주석이 있는 경우 코드의 최신 보기에 주석이 표시되지 않았습니다.Previously, if there were comments on those renamed files, the latest view of the code would not display the comments. 이제 이름 변경을 따르도록 주석 추적 기능이 향상되어 이름이 바뀌었거나 이동된 파일의 최신 버전에 대한 주석이 표시됩니다.We have now improved comment tracking to follow the renames, displaying comments on the latest version of renamed or moved files.

끌어오기 요청 병합 커밋 보기View pull request merge commit

끌어오기 요청 diff 보기는 소스 분기에 도입된 변경 내용을 강조 표시하는 데 유용합니다.Pull request diff views are great at highlighting the changes introduced in the source branch. 그러나 대상 분기를 변경하면 diff 보기가 예상한 것과 다르게 표시될 수 있습니다.However, changes to the target branch may cause the diff view to look different than expected. 이제 새 명령(병합 커밋 보기)을 사용하여 끌어오기 요청에 대한 “미리 보기” 병합 커밋의 diff를 볼 수 있습니다.A new command is now available to view the diff of the "preview" merge commit for the pull request - View merge commit. 이 병합 커밋은 병합 충돌을 확인하고 끌어오기 요청 빌드와 함께 사용하기 위해 만들어지며, 끌어오기 요청이 최종적으로 완료될 때 병합 커밋이 표시되는 모양을 반영합니다.This merge commit is created to check for merge conflicts and to use with a pull request build, and it reflects what the merge commit will look like when the pull request is eventually completed. diff에 반영되지 않은 변경 내용이 대상 분기에 있는 경우 병합 커밋 diff가 소스 분기와 대상 분기 모두에서 최근 변경 내용을 확인하는 데 유용할 수 있습니다.When the target branch has changes not reflected in the diff, the merge commit diff can be useful for seeing the latest changes in both the source and target branches.

끌어오기 요청 병합 커밋 보기View pull request merge commit

병합 커밋 보기 명령과 함께 유용한 또 다른 명령은 병합 다시 시작 입니다(동일한 명령 메뉴에서 사용 가능).Another command that is useful in conjunction with the View merge commit command is Restart merge (available on the same command menu). 끌어오기 요청이 처음 만들어진 후에 대상 분기가 변경된 경우 이 명령을 실행하면 병합 커밋 diff 보기를 업데이트하여 새 미리 보기 병합 커밋이 만들어집니다.If the target branch has changed since the pull request was initially created, running this command creates a new preview merge commit, updating the merge commit diff view.

최근에 사용한 검토자Recently used reviewers

동일한 사용자가 코드를 자주 검토하는 경우 이전보다 쉽게 검토자를 추가할 수 있습니다.If you frequently have your code reviewed by the same individuals, you will find it easier than ever to add reviewers. 끌어오기 요청에 검토자를 추가할 때 검토자 입력란에 포커스를 놓으면 최근에 추가된 검토자 목록이 자동으로 표시되므로 이름으로 검색할 필요가 없습니다.When adding reviewers to your pull requests, a list of your recently added reviewers is automatically displayed when you put focus into the reviewers input box -- no need to search by name. 다른 모든 검토자와 마찬가지로 해당 검토자를 선택합니다.Select them as you would any reviewer.

MRU 검토자MRU reviewers

끌어오기 요청 자동 완성에 대한 나머지 정책 기준 보기View remaining policy criteria for pull request auto-complete

자동 완성은 분기 정책을 사용하는 팀에 유용한 기능이지만, 선택적 정책을 사용하는 경우 끌어오기 요청이 완료되지 않도록 차단하는 것이 정확히 명확하지 않을 수 있습니다.Auto-complete is a useful feature for teams using branch policies, but when using optional policies, it can be unclear exactly what is blocking a pull request from being completed. 이제 끌어오기 요청에 대한 자동 완성을 설정하면 완료를 보류하는 정책 기준의 정확한 목록이 설명선 상자에 명확하게 나열됩니다.Now, when setting auto-complete for a pull request, the exact list of policy criteria that are holding up completion are clearly listed in the callout box. 각 요구 사항이 충족되면 나머지 요구 사항이 없고 끌어오기 요청이 병합될 때까지 항목이 목록에서 제거됩니다.As each requirement is met, items are removed from the list until there are no remaining requirements and the pull request is merged.

PR 자동 완성 목록PR auto-complete lists

끌어오기 요청에 대한 수학적 논의Discuss math in pull requests

끌어오기 요청 주석에 수식 또는 이나 수학 함수 식이 포함될 필요가 있나요?Need to include an equation or mathematical expression in your pull request comments? 이제 인라인 및 블록 주석 처리를 모두 사용하여 주석에 KaTeX 함수가 포함 수 있습니다.You can now include KaTeX functions in your comments, using both inline and block commenting. 자세한 내용은 지원되는 함수 목록을 참조하세요.See the list of supported functions for more information.

수학 함수가 있는 PR 마크다운 주석PR markdown comment with math

포크에 대한 끌어오기 요청 제안Pull request suggestions for forks

토픽 분기가 리포지토리에서 업데이트될 때마다 토픽 분기에 대한 새 PR(끌어오기 요청)을 만들도록 요구하는 “제안”이 표시됩니다.Whenever a topic branch is updated in a repository, a "suggestion" to create a new pull request (PR) for the topic branch is shown. 이는 새 PR을 만드는 데 매우 유용하며, 포크된 리포지토리에서 작업하는 사용자에 대해서도 사용할 수 있게 되었습니다.This is very useful for creating new PRs, and we have enabled it for those working in a forked repo, too. 포크에서 분기를 업데이트하면 다음에 포크 또는 업스트림 리포지토리에 대한 코드 허브를 방문할 때 끌어오기 요청을 만들도록 요구하는 제안이 표시됩니다.If you update a branch in a fork, the next time you visit the Code hub for either the fork or the upstream repo, you will see the suggestion to create a pull request. “끌어오기 요청 만들기” 링크를 선택하면 소스 및 대상 분기와 리포지토리가 미리 선택되어 있는 PR 만들기 환경으로 이동합니다.If you select the "Create a pull request" link, you will be directed to the create PR experience, with the source and target branches and repos pre-selected.

포크에 대한 PR 제안PR suggest for forks

끌어오기 요청 정책에 대한 경로 필터Path filters for pull request policies

대부분의 경우 빌드의 유효성을 검사하고 테스트를 실행하기 위해 단일 리포지토리에 CI(연속 통합) 파이프라인으로 작성된 코드가 포함됩니다.Many times, a single repository contains code that is built by multiple continuous integration (CI) pipelines to validate the build and run tests. 이제 통합된 빌드 정책에서 경로 필터링 옵션을 지원하여 각 PR에 대해 필요하고 자동으로 트리거될 수 있는 여러 PR 빌드를 쉽게 구성할 수 있습니다.The integrated build policy now supports a path filtering option that makes it easy to configure multiple PR builds that can be required and automatically triggered for each PR. 필요에 따라 각 빌드에 대한 경로를 지정하고 트리거 및 요구 사항 옵션을 원하는 대로 설정하기만 하면 됩니다.Just specify a path for each build to require, and set, the trigger and requirement options as desired.

PR 정책에 대한 경로 필터Path filters for PR policies

또한 상태 정책에는 빌드 외에도 경로 필터링 옵션을 사용할 수 있습니다.In addition to build, status policies also have the path filtering option available. 이렇게 하면 모든 사용자 지정 또는 타사 정책에서 특정 경로에 대한 정책 적용을 구성할 수 있습니다.This allows any custom or third party policies to configure policy enforcement for specific paths.

작업Work

작업 항목 양식의 바로 가기 키Keyboard shortcuts in the work item form

바로 가기 키를 사용하여 작업 항목을 자신에게 할당하고(Alt+i), 토론으로 이동하고(Ctrl+Alt+d), 작업 항목에 빠른 링크를 복사합니다(Shift+Alt+c).Assign a work item to yourself (Alt + i), jump to discussion (Ctrl + Alt + d), and copy a quick link to the work item (Shift + Alt + c) using keyboard shortcuts. 새 바로 가기의 전체 목록을 보려면 작업 항목 폼을 열고 “?”를 입력하거나 아래 표를 참조하세요.For the full list of new shortcuts, type "?" with a work item form open or see the table below.

작업 항목 양식의 바로 가기 키Keyboard shortcuts in work item form

현대화 열 옵션Modernized column options

백로그, 쿼리테스트 허브에서 작업 항목 그리드의 열을 구성하는 데 사용된 열 옵션 대화 상자에서 새 패널 디자인을 사용하도록 업데이트되었습니다.The Column options dialog used to configure the columns of the work item grid in the Backlog, Queries, and Test hubs has been updated to use a new panel design. 필드를 검색하여 찾거나, 열을 끌어서 놓아 다시 정렬하거나, 더 이상 필요하지 않은 기존 열을 제거합니다.Search to find a field, drag and drop to reorder columns, or remove existing columns you no longer want.

현대화 열 옵션Modernized column options

마지막 실행 정보 기준 쿼리Query last run by information

프로젝트의 공유 쿼리 트리가 커짐에 따라 쿼리가 더 이상 사용되지 않고 삭제할 수 있는지 확인하기가 어려울 수 있습니다.As your project's Shared Queries tree grows, it can be difficult to determine if a query is no longer used and can be deleted. 공유 쿼리 를 관리하는 데 도움이 되도록 쿼리 REST API에 새로운 두 가지 메타데이터 부분(마지막으로 실행한 사용자 및 마지막으로 실행한 날짜)을 추가하여 부실한 쿼리를 삭제하는 정리 스크립트를 작성할 수 있습니다.To help you manage your Shared Queries, we have added two new pieces of metadata to our query REST APIs, last executed by and last executed date, so that you can write clean-up scripts to delete stale queries.

작업 항목 그리드에서 제거된 HTML 태그HTML tags stripped in work item grids

고객 의견에 따라 웹, Excel 및 Visual Studio IDE의 작업 항목 쿼리 결과 보기에서 여러 줄 텍스트 필드의 동작을 업데이트하여 HTML 서식이 제거되었습니다.Based on customer feedback, we have updated the behavior of multi-line text fields in work item query results views in the web, Excel, and Visual Studio IDE to remove HTML formatting. 이제 쿼리에 여러 줄 텍스트 필드가 열로 추가되면 일반 텍스트로 표시됩니다.When added as a column to the query, multi-line text fields now display as plain text. 설명에 HTML이 포함된 기능의 예는 다음과 같습니다.Here is an example of a feature with HTML in the description.

HTML 태그 제거Strip HTML tags

이전에는 쿼리 결과가 <div><b><u>Customer Value</u>...와 비슷하게 렌더링되었습니다.In the past, the query results would have rendered something like <div><b><u>Customer Value</u>...

Not In 쿼리 연산자 지원 추가Added support for Not In query operator

“In” 쿼리 연산자를 지원하는 필드에서 이제 “Not In”을 지원합니다.Fields that support the "In" query operator now support "Not In". 중첩된 “Or” 절을 많이 만들지 않고도 ID 목록에 대한 “Not In”, 상태 목록에 대한 “Not In” 등과 같은 작업 항목에 대한 쿼리를 작성할 수 있습니다.Write queries for work items "Not In" a list of IDs, "Not In" a list of states, and much more, all without having to create many nested "Or" clauses.

Not In 쿼리 연산자Not In query operator

@MyRecentActivity 및 @RecentMentions에 대한 쿼리Query for @MyRecentActivity and @RecentMentions

중요할 수 있는 작업 항목을 찾는 데 도움이 되도록 ID 필드에 대한 두 가지 쿼리 매크로를 새로 도입했습니다.We have introduced two new query macros for the ID field to help you find work items that may be important to you. @RecentMentions를 사용하여 지난 30일 동안 언급한 항목을 보거나 @MyRecentActivity를 사용하여 최근에 보거나 편집한 작업 항목을 살펴봅니다.See what items you were mentioned in over the last 30 days using @RecentMentions or take a look at work items you have recently viewed or edited using @MyRecentActivity.

작업 항목 추적 알림의 사용자 지정 필드 및 태그 필터Custom fields and tags filter in work item tracking notifications

이제 사용자 지정 필드 및 태그에 조건을 사용하여 알림을 정의할 수 있습니다. 이러한 알림이 변경될 때뿐만 아니라 특정 값이 충족될 때도 마찬가지입니다. 또한 작업 항목에 설정할 수 있는 더욱 강력한 알림 세트를 허용합니다.Notifications can now be defined using conditions on custom fields and tags; not only when they change but when certain values are met, and allows for a more robust set of notifications that can be set for work items.

사용자 지정 작업 항목 알림 설정custom work item notification settings

내 작업 항목 페이지에 대한 언급됨 지원Mentioned support for the My work items page

내 작업 항목 페이지 아래에 언급됨 피벗을 새로 추가했습니다.We have added a new Mentioned pivot under the My work items page. 이 피벗 내에서 지난 30일 동안 언급된 작업 항목을 검토할 수 있습니다.Inside this pivot, you can review the work items where you have been mentioned in the last 30 days. 이 새 보기를 사용하면 사용자 입력이 필요한 항목에 대한 작업을 빠르게 수행하고, 사용자와 관련된 대화에서 최신 상태를 유지할 수 있습니다.With this new view, you can quickly take action on items that require your input and stay up to date on conversations that are relevant to you.

내 작업 항목에서 언급된 작업mentioned work under My work items

이 동일한 피벗은 모바일 환경을 통해서도 사용할 수 있으므로 모바일과 데스크톱 간에 일관성을 유지할 수 있습니다.This same pivot is also available through our mobile experience, bringing consistency between both mobile and desktop.

언급된 작업mentioned work

계획 필터링Filtering on plans

배달 계획 확장은 이제 일반적인 필터링 구성 요소를 사용하며 작업 항목 및 보드 에 대한 그리드 필터링 환경과 일치합니다.The Delivery Plans extension now makes use of our common filtering component, and is consistent with our grid filtering experiences for work items and Boards. 이 필터링 제어를 사용하면 팀 멤버 모두에게 향상된 유용성과 일관된 인터페이스가 제공됩니다.This filtering control brings improved usability and a consistent interface to all members of your team.

계획 필터링Filtering on Plans

업데이트된 계획 탐색Updated plans navigation

대부분의 사용자가 특정 계획이나 일단의 계획에 대해 관심이 있으며, 즐겨찾기를 사용하여 콘텐츠에 빠르게 액세스합니다.Many of you care about a specific plan or set of plans and use favorites for quick access to the content. 먼저, 디렉터리 페이지 대신 가장 최근에 방문한 계획으로 이동하도록 계획 허브를 업데이트했습니다.First, we have updated the Plans hub to navigate to your most recently visited plan instead of the directory page. 다음으로, 즐겨찾기 선택기를 사용하여 다른 계획으로 빠르게 전환하거나, 이동 경로를 사용하여 디렉터리 페이지로 다시 이동할 수 있습니다.Second, once there, you can use the favorites picker to quickly switch to another plan or use the breadcrumb to navigate back to the directory page.

업데이트된 계획 탐색Updated Plans navigation

작업 보드에서 요구 사항/사용자 펼치기/접기Expand/collapse requirements/people on the task board

이제 한 번의 클릭으로 스프린트 작업 보드 의 모든 항목을 펼치거나 접을 수 있습니다.You can now expand or collapse all the items on the sprint Task board with just a single click.

작업 보드 펼치기/접기Expand collapse Task board

특정 사용자에게 무시 규칙 권한 부여Grant the bypassrule permission to specific users

다른 소스에서 작업 항목을 마이그레이션할 때 조직에서 작업 항목의 원래 속성을 모두 유지하려는 경우가 많습니다.Often, when migrating work items from another source, organizations want to retain all the original properties of the work item. 예를 들어 원래 만든 날짜를 유지하고 원래 시스템의 값으로 만들어진 버그를 만들 수도 있습니다.For example, you may want to create a bug that retains the original created date and created by values from the system where it originated.

작업 항목 업데이트에 대한 API에는 해당 시나리오를 사용할 수 있게 하는 무시 규칙 플래그가 있습니다.The API to update a work item has a bypassrule flag to enable that scenario. 이전에는 해당 API 요청을 만든 ID가 프로젝트 컬렉션 관리자 그룹의 멤버여야 했습니다.Previously, the identity who made that API request had to be a member of the Project Collection Administrators group. 무시 규칙 플래그가 있는 API를 실행하기 위한 프로젝트 수준의 권한을 추가했습니다.We have added a permission at the project level to execute the API with the bypassrule flag.

무시 규칙 부여Grant bypassrule

빌드 및 릴리스Build and Release

XAML 빌드XAML builds

TFS 2015에는 웹 기반, 플랫폼 간 빌드 시스템을 도입했습니다.In TFS 2015, we introduced a web-based, cross-platform build system. XAML 빌드는 TFS 2018 RTW 또는 업데이트 1에서 지원되지 않지만 TFS 2018 업데이트 2에서 XAML 빌드를 활성화했습니다.XAML builds are not supported in TFS 2018 RTW or Update 1, but we have re-enabled XAML builds in TFS 2018 Update 2. 따라서 XAML 빌드를 마이그레이션하는 것이 좋습니다.We encourage you to migrate your XAML builds.

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

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

  • XAML 빌드 정의를 편집하거나 새 XAML 빌드를 큐에 넣을 때 VS 또는 Team Explorer 2017을 사용해야 합니다.You will need to use VS or Team Explorer 2017 to edit XAML build definitions or to queue new XAML builds.

  • 새 XAML 빌드 에이전트를 만들어야 할 경우 TFS 2015 빌드 에이전트 설치 관리자를 사용하여 설치해야 합니다.If you need to create new XAML build agents, you will need to install them using the TFS 2015 build agent installer.

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

향상된 다단계 빌드 기능Enhancements to multi-phase builds

단계를 사용하여 빌드 단계를 구성하고, 단계마다 서로 다른 요구를 사용하여 서로 다른 에이전트를 대상으로 지정할 수 있었습니다.You have been able to use phases to organize your build steps and to target different agents using different demands for each phase. 이제 단계를 빌드하는 몇 가지 기능이 추가되어 다음과 같은 작업을 수행할 수 있습니다.We have added several capabilities to build phases so that you can now:

  • 각 단계마다 다른 에이전트 큐를 지정합니다.Specify a different agent queue for each phase. 즉, 다음과 같이 수행할 수 있습니다.This means you can, for example:

    • macOS 에이전트에서 빌드의 한 단계를 실행하고, Windows 에이전트에서 다른 단계를 실행합니다.Run one phase of a build on a macOS agent and another phase on a Windows agent. 이 방법이 얼마나 유용한지를 보여주는 멋진 예제를 보려면 다음 연결(); 2017 비디오를 참조하세요. 모바일 앱 및 서비스용 CI/CD DevOps 파이프라인.To see a cool example of how useful this can be, see this Connect(); 2017 video: CI/CD DevOps Pipeline for mobile apps and services.
    • 빌드 에이전트 풀에서 빌드 단계를 실행하고, 테스트 에이전트 풀에서 단계를 테스트합니다.Run build steps on a build agent pool and test steps on a test agent pool.
  • 테스트를 병렬로 실행하여 더 빠르게 실행합니다.Run tests faster by running them in parallel. 병렬 처리가 “다중 에이전트”로 구성되고 “VSTest” 작업이 포함된 단계는 이제 구성된 에이전트 수에 따라 테스트 실행을 자동으로 병렬 처리합니다.Any phase that has parallelism configured as "Multi-agent" and contains a "VSTest" task now automatically parallelize test execution across the configured agent count.

  • 각 단계에서 OAuth 토큰에 액세스할 수 있도록 스크립트를 허용하거나 거부합니다.Permit or deny scripts to access the OAuth token each phase. 예를 들어 REST API를 통해 VSTS와 통신하도록 빌드 단계에서 실행되는 스크립트를 허용할 수 있으며, 동일한 빌드 정의에서 테스트 단계에서 실행되는 스크립트를 차단할 수 있습니다.This means, for example, you can now allow scripts running in your build phase to communicate with VSTS over REST APIs, and in the same build definition block the scripts running in your test phase.

  • 특정 조건에서만 단계를 실행합니다.Run a phase only under specific conditions. 예를 들어 이전 단계가 성공했을 때만 또는 기본 분기에서 코드를 빌드할 때만 실행되도록 단계를 구성할 수 있습니다.For example, you can configure a phase to run only when previous phases succeed, or only when you are building code in the main branch.

자세한 내용은 빌드 및 릴리스 관리 단계를 참조하세요.To learn more, see Phases in Build and Release Management.

리포지토리에 변경 내용이 없는 경우 예약된 빌드 건너뛰기Skip scheduled builds if nothing has changed in the repo

인기 있는 요청을 통해 코드에서 변경된 내용이 없을 때 예약된 빌드가 실행되지 않도록 지정할 수 있습니다.By popular request, you can now specify that a scheduled build not run when nothing has changed in your code. 일정에 있는 옵션을 사용하여 이 동작을 제어할 수 있습니다.You can control this behavior using an option on the schedule. 기본적으로 동일한 일정에서 마지막으로 예약된 빌드가 전달되고 변경 내용이 더 이상 리포지토리에 체크인되지 않으면 새 빌드를 예약하지 않습니다.By default, we will not schedule a new build if your last scheduled build (from the same schedule) has passed and no further changes have been checked in to your repo.

GitHub Enterprise의 지속적인 통합을 통한 빌드Build with continuous integration from GitHub Enterprise

GitHub Enterprise 를 버전 제어에 사용하는 경우 CI(지속적인 통합) 빌드를 수행하는 데 더 나은 통합이 이루어졌습니다.You now have better integration for performing continuous integration (CI) builds if you use GitHub Enterprise for version control. 이전에는 외부 Git 커넥터를 통한 코드 변경에 대한 폴링이 제한되어 있어 서버 로드가 증가하고 빌드가 트리거되기 전에 지연이 발생할 수 있었습니다.Previously, you were limited to polling for code changes using the External Git connector, which may have increased the load on your servers and caused delays before builds were triggered. 이제는 공식적인 GitHub Enterprise 지원을 통해 팀 CI 빌드가 즉시 트리거됩니다.Now, with official GitHub Enterprise support, team CI builds are immediately triggered. 또한 LDAP 또는 기본 제공 계정과 같은 다양한 인증 방법을 사용하여 연결을 구성할 수 있습니다.In addition, the connection can be configured using various authentication methods, such as LDAP or built-in accounts.

GitHub Enterprise 빌드 소스 옵션GitHub Enterprise build source option

빌드 또는 릴리스 중에 보안 파일을 에이전트에 다운로드할 수 있습니다.Secure files can be downloaded to agents during build or release

보안 파일 다운로드 작업은 VSTS 보안 파일 라이브러리에서 암호화된 파일을 에이전트 컴퓨터에 다운로드하도록 지원합니다.The new Download Secure File task supports downloading (to agent machines) encrypted files from the VSTS Secure Files library. 파일이 다운로드되면 암호가 해독되어 에이전트의 디스크에 저장됩니다.As the file is downloaded, it is decrypted and stored on the agent's disk. 빌드 또는 릴리스가 완료되면 파일이 에이전트에서 삭제됩니다.When the build or release completes, the file is deleted from the agent. 이를 통해 VSTS에 안전하게 암호화되고 저장되는 인증서 또는 프라이빗 키와 같은 중요한 파일을 빌드 또는 릴리스에서 사용할 수 있습니다.This allows your build or release to use sensitive files, such as certificates or private keys that are otherwise securely encrypted and stored in VSTS. 자세한 내용은 보안 파일 설명서를 참조하세요.For more information, see Secure files documentation.

소스 리포지토리에서 설치할 수 있는 Apple 프로비전 프로필Apple provisioning profiles can be installed from source repositories

Apple 프로비전 프로필 설치 작업은 이미 VSTS 보안 파일 라이브러리에 저장된 프로비전 프로필을 에이전트 컴퓨터에 설치하도록 지원합니다.The Install Apple Provisioning Profile task already supports installing (on agent machines) provisioning profiles that are stored in the VSTS Secure Files library. 프로비전 프로필은 Xcode에서 iOS, macOS, tvOS 및 watchOS와 같은 Apple 앱을 서명하고 패키지하는 데 사용됩니다.Provisioning profiles are used by Xcode to sign and package Apple apps, such as for iOS, macOS, tvOS, and watchOS. 이제 프로비전 프로필은 소스 코드 리포지토리에서 설치할 수 있습니다.Now, provisioning profiles can be installed from source code repositories. 이러한 파일의 보안을 강화하기 위해 보안 파일 라이브러리를 사용하는 것이 좋지만, 향상된 이 기능은 이미 소스 제어에 저장된 프로비전 프로필을 처리합니다.Though use of the Secure Files library is recommended for greater security of these files, this improvement addresses provisioning profiles already stored in source control.

Apple 프로비전Apple provisioning

빌드 태그를 사용하여 빌드할 GitHub 소스 추적Trace GitHub sources to builds using build tags

GitHub 또는 GitHub Enterprise의 빌드는 이미 관련된 커밋에 연결됩니다.Builds from GitHub or GitHub Enterprise already link to the relevant commit. 빌드한 빌드에 대한 커밋을 추적할 수 있는 것도 마찬가지로 중요합니다.It is equally important to be able to trace a commit to the builds that built it. 이제는 TFS에서 소스에 태그 지정을 사용하도록 설정할 수 있습니다.That is now possible by enabling source tagging in TFS. 빌드 정의에서 GitHub 리포지토리를 선택하는 동안 태그 서식과 함께 태그를 지정하려는 빌드 형식을 선택합니다.While choosing your GitHub repository in a build definition, select the types of builds you want to tag, along with the tag format.

소스에 태그 지정 옵션Tag sources options

그런 다음, GitHub 또는 GitHub Enterprise 리포지토리에 빌드 태그가 표시되는지 살펴봅니다.Then watch build tags appear on your GitHub or GitHub Enterprise repository.

GitHub에서 태그가 지정된 소스 예Tagged sources examples in GitHub

빌드 및 릴리스 중에 설치할 수 있는 특정 JDK(Java Development Kit)Specific Java Development Kits (JDKs) can be installed during builds and releases

특정 JDK는 특정 Java 프로젝트를 빌드하는 데 필요할 수 있지만 에이전트 컴퓨터에서 사용할 수 없습니다.For building certain Java projects, specific JDKs may be required but unavailable on agent machines. 예를 들어 IBM, Oracle 또는 오픈 소스 JDK의 이전 버전 또는 다른 버전이 프로젝트에 필요할 수 있습니다.For example, projects may require older or different versions of IBM, Oracle, or open-source JDKs. Java 도구 설치 관리자 작업은 빌드 또는 릴리스 중에 프로젝트에 필요한 JDK를 다운로드하여 설치합니다.The Java Tool Installer task downloads and installs the JDK needed by your project during a build or release. JAVA_HOME 환경 변수는 빌드 또는 릴리스 기간 동안 적절하게 설정됩니다.The JAVA_HOME environment variable is set accordingly for the duration of the build or release. 특정 JDK는 파일 공유, 소스 코드 리포지토리 또는 Azure Blob Storage를 사용하여 Java 도구 설치 관리자 에서 사용할 수 있습니다.Specific JDKs are available to the Java Tool Installer using a file share, a source code repository, or Azure Blob Storage.

향상된 Xcode 빌드 구성Improved Xcode build configuration

Xcode 작업은 Xcode 빌드, 테스트 및 패키징 구성을 향상시키는 새로운 주 버전(4.*)으로 업데이트되었습니다.The Xcode task has been updated with a new major version (4.*) that improves configuration of Xcode building, testing, and packaging. Xcode 프로젝트에 하나의 공유 구성표만 있으면 자동으로 사용됩니다.If your Xcode project has a single, shared scheme, it is automatically used. 추가 인라인 도움말이 추가되었습니다.Additional inline help was added. xcrun 패키징과 같이 사용되지 않는 기능은 Xcode 작업의 속성에서 제거되었습니다.Deprecated features, such as xcrun packaging, were removed from the Xcode task's properties. 최신의 Xcode 작업 4.* 버전을 사용하려면 기존 빌드 및 릴리스 정의를 수정해야 합니다.Existing build and release definitions must be modified to use this latest 4.* version of the Xcode task. 새 정의의 경우, 더 이상 사용되지 않는 이전 Xcode 작업 버전의 기능이 필요하면 정의에서 해당 버전을 선택할 수 있습니다.For new definitions, if you need a previous Xcode task version's deprecated capabilities, you can select that version in your definition.

릴리스 게이트Release gates

연속 모니터링은 DevOps 파이프라인의 필수적인 부분입니다.Continuous monitoring is an integral part of DevOps pipelines. 배포 후 릴리스의 앱이 정상인지 확인하는 것은 배포 프로세스의 성공만큼 중요합니다.Ensuring the app in a release is healthy after deployment is as critical as the success of the deployment process. 기업은 프로덕션 환경에서 앱 상태를 자동으로 감지하고 고객이 보고하는 인시던트를 추적하기 위한 다양한 도구를 채택했습니다.Enterprises have adopted various tools for automatic detection of app health in production and for keeping track of customer reported incidents. 지금까지 승인자는 릴리스를 승격하기 전에 모든 시스템에서 앱의 상태를 수동으로 모니터링해야 했습니다.Until now, approvers had to manually monitor the health of the apps from all the systems before promoting the release. 그러나 릴리스 관리는 이제 연속 모니터링을 릴리스 파이프라인에 통합하도록 지원합니다.However, Release Management now supports integrating continuous monitoring into release pipelines. 이 기능을 사용하여 앱에 대한 모든 상태 신호가 동시에 성공할 때까지 시스템에서 이러한 상태 신호 모두를 반복적으로 쿼리한 후에 릴리스를 계속합니다.Use this to ensure the system repeatedly queries all the health signals for the app until all of them are successful at the same time, before continuing the release.

먼저 릴리스 정의에서 배포 전 또는 배포 후 게이트를 정의하는 것으로 시작합니다.You start by defining pre-deployment or post-deployment gates in the release definition. 각 게이트는 앱의 모니터링 시스템에 해당하는 하나 이상의 상태 신호를 모니터링할 수 있습니다.Each gate can monitor one or more health signals corresponding to a monitoring system of the app. 기본 제공 게이트는 “Azure Monitor(애플리케이션 인사이트) 경고” 및 “작업 항목”에 사용할 수 있습니다.Built-in gates are available for "Azure monitor (application insight) alerts" and "Work items". Azure 함수를 통해 제공되는 유연성을 사용하여 다른 시스템과 통합할 수 있습니다.You can integrate with other systems using the flexibility offered through Azure functions.

게이트가 정의된 릴리스Gated releases

실행 시 릴리스 는 모든 게이트를 샘플링하고 각 게이트로부터 상태 신호를 수집하기 시작합니다.At the time of execution, the Release starts to sample all the gates and collect health signals from each of them. 동일한 간격으로 모든 게이트에서 수집된 신호가 성공할 때까지 각 간격마다 샘플링을 반복합니다.It repeats the sampling at each interval until signals collected from all the gates in the same interval are successful.

샘플링 간격Sampling interval

새 배포에 사용할 수 있는 정보가 충분하지 않을 수 있으므로 모니터링 시스템의 초기 샘플이 정확하지 않을 수 있습니다.Initial samples from the monitoring systems may not be accurate, as not enough information may be available for the new deployment. “평가 전 지연” 옵션을 사용하면 모든 샘플이 성공한 경우에도 이 기간에 릴리스 가 진행되지 않습니다.The "Delay before evaluation" option ensures the Release does not progress during this period, even if all samples are successful.

게이트 샘플링 중에는 에이전트 또는 파이프라인이 사용되지 않습니다.No agents or pipelines are consumed during sampling of gates. 자세한 내용은 릴리스 게이트 설명서를 참조하세요.See the documentation for release gates for more information.

릴리스를 트리거하는 아티팩트에 따라 선택적으로 배포Deploy selectively based on the artifact triggering a release

여러 아티팩트 소스를 릴리스 정의에 추가하고 이 릴리스를 트리거하도록 구성할 수 있습니다.Multiple artifact sources can be added to a release definition and configured to trigger a release. 소스 중 하나에 새 빌드를 사용할 수 있으면 새 릴리스가 만들어집니다.A new release is created when a new build is available for either of the sources. 릴리스를 트리거한 소스에 관계없이 동일한 배포 프로세스가 실행됩니다.The same deployment process is executed regardless of what source triggered the release. 이제 트리거하는 소스를 기반으로 하여 배포 프로세스를 사용자 지정할 수 있습니다.You can now customize the deployment process based on the triggering source. 자동 트리거 릴리스의 경우 Release.TriggeringArtifact.Alias 릴리스 변수가 채워져 릴리스를 트리거한 아티팩트 소스를 식별합니다.For auto-triggered releases, the release variable Release.TriggeringArtifact.Alias is now populated to identify the artifact source that triggered the release. 이 변수는 작업 조건, 단계 조건 및 작업 매개 변수에서 프로세스를 동적으로 조정하는 데 사용할 수 있습니다.This can be used in task conditions, phase conditions, and task parameters to dynamically adjust the process. 예를 들어 환경을 통해 변경된 아티팩트만 배포하면 되는 경우가 있습니다.For example, if you only need to deploy the artifacts that changed through environments.

엔티티 관련 보안 관리Manage entity-specific security

이전에는 역할 기반 보안에서 보안 액세스 역할이 설정되는 경우 이러한 역할은 배포 그룹, 변수 그룹, 에이전트 큐 및 서비스 엔드포인트에 대한 허브 수준에서 사용자 또는 그룹에 대해 설정되었습니다.Previously in role based security, when the security access roles were set, they were set for a user or group at hub level for Deployment groups, Variable groups, Agent queues, and Service endpoints. 이제 특정 엔터티에 대한 상속을 설정/해제할 수 있으므로 원하는 방식으로 보안을 구성할 수 있습니다.Now you can turn on and off inheritance for a particular entity so you can configure security just the way you want to.

보안 대화 상자Security dialog

여러 환경 승인Approve multiple environments

릴리스를 사용한 승인 관리가 이제 더 간단해 졌습니다.Managing approvals with releases is now simpler. 병렬로 배포되는 여러 환경에 대해 동일한 승인자가 있는 파이프라인의 경우, 승인자는 현재 각 승인에 대해 개별적으로 작업을 수행해야 합니다.For pipelines having the same approver for multiple environments that deploy in parallel, the approver currently needs to act on each of the approvals separately. 이제 이 기능을 사용하면 여러 개의 보류 중인 승인을 동시에 완료할 수 있습니다.With this feature, you can now complete multiple pending approvals at the same time.

여러 환경 승인approve multiple environments

릴리스 템플릿 확장성Release template extensibility

릴리스 템플릿을 사용하면 릴리스 프로세스를 정의할 때 시작할 수 있는 기준을 만들 수 있습니다.Release templates let you create a baseline for you to get started when defining a release process. 이전에는 계정에 새 템플릿을 업로드할 수 있었지만, 이제는 작성자가 자신의 확장에 릴리스 템플릿을 포함할 수 있습니다.Previously, you could upload new ones to your account, but now authors can include release templates in their extensions. GitHub 리포지토리에서 예제를 찾을 수 있습니다.You can find an example on the GitHub repo.

조건부 릴리스 작업 및 단계Conditional release tasks and phases

조건부 빌드 작업와 마찬가지로, 이제는 특정 조건이 충족되는 경우에만 작업 또는 단계를 실행할 수 있습니다.Similar to conditional build tasks, you can now run a task or phase only if specific conditions are met. 이렇게 하면 롤백 시나리오 모델링에 도움이 됩니다.This will help you in modeling rollback scenarios.

기본 제공 조건이 사용자의 요구를 충족시키지 못하거나 작업 또는 단계가 실행될 때 더 세분화된 제어가 필요한 경우 사용자 지정 조건을 지정할 수 있습니다.If the built-in conditions do not meet your needs, or if you need more fine-grained control over when the task or phase runs, you can specify custom conditions. 조건을 중첩된 함수 집합으로 표현합니다.Express the condition as a nested set of functions. 에이전트에서 가장 안쪽에 있는 함수를 평가하고 바깥쪽으로 작동합니다.The agent evaluates the innermost function and works its way outward. 최종 결과는 작업이 실행될지 여부를 결정하는 부울 값입니다.The final result is a Boolean value that determines if the task is to be run.

조건부 릴리스 단계conditional release phases

서비스 엔드포인트에 대한 요청 기록Requests history for service endpoints

서비스 엔드포인트를 사용하면 외부 및 원격 서비스에 연결하여 빌드 또는 배포 작업을 실행할 수 있습니다.Service endpoints enable connection to external and remote services to execute tasks for a build or deployment. 엔드포인트는 프로젝트 범위에서 구성되고 여러 빌드 및 릴리스 정의 간에 공유됩니다.The endpoints are configured in project scope and shared between multiple build and release definitions. 이제 서비스 엔드포인트 소유자는 엔드포인트를 사용하여 빌드 및 배포에 대한 통합된 보기를 가져올 수 있으므로 감사 및 거버넌스 기능을 향상시키는 데 도움이 됩니다.Service endpoint owners can now get a consolidated view of builds and deployments using an endpoint, that can help to improve auditing and governance.

엔드포인트 요청 기록Endpoint requests history

편집 가능한 Git 및 GitHub 아티팩트 형식의 기본 속성Default properties for Git and GitHub artifact types are now editable

이제 아티팩트가 연결된 후에도 Git 및 GitHub 아티팩트 형식의 기본 속성을 편집할 수 있습니다.You can now edit the default properties of Git and GitHub artifact types even after the artifact has been linked. 이 기능은 안정적인 버전의 아티팩트에 대한 분기가 변경된 시나리오에서 특히 유용하며, 이후의 연속 배달 릴리스에서 이 분기를 사용하여 최신 버전의 아티팩트를 가져와야 합니다.This is particularly useful in scenarios where the branch for the stable version of the artifact has changed, and future continuous delivery releases should use this branch to obtain newer versions of the artifact.

편집 가능한 아티팩트 속성Editable artifact properties

릴리스 보기의 수동 대량 배포 환경Bulk deploy environments manually from release view

이제 릴리스의 여러 환경에 배포 작업을 수동으로 동시에 트리거할 수 있습니다.You can now manually trigger a Deploy action to multiple environments of a release at the same time. 이렇게 하면 실패한 구성 또는 배포가 있는 릴리스에서 여러 환경을 선택하고 한 번의 작업으로 모든 환경에 다시 배포할 수 있습니다.This allows you to select multiple environments in a release with failed configurations or deployments, and re-deploy to all of the environments in one operation.

대량 배포Bulk deploy

Jenkins의 프로젝트를 사용하는 것이 훨씬 향상되었습니다.Consuming projects from Jenkins just got even better.

먼저, Jenkins 다중 분기 파이프라인 프로젝트를 릴리스 정의의 아티팩트 소스로 사용할 수 있습니다.First, you can now consume Jenkins multi-branch pipeline projects as artifact sources in a release definition.

다음으로, 이전에는 Jenkins 서버의 루트 폴더에서만 Jenkins 프로젝트를 아티팩트로 연결할 수 있었지만, 지금은 폴더 수준에서 구성한 Jenkins 프로젝트를 사용할 수 있습니다.Second, while previously you could link Jenkins projects as artifacts only from the root folder of a Jenkins server, now Jenkins projects can be consumed when organized at folder level. 아티팩트 소스로 사용할 프로젝트를 선택하는 소스 목록에 폴더 경로와 함께 Jenkins 프로젝트 목록이 표시됩니다.You see the list of Jenkins projects, along with folder paths, in the list of sources from which you select the project to be consumed as artifact source.

Jenkins 폴더 수준Jenkins folder level

Docker 허브 또는 Azure Container Registry를 아티팩트 소스로 사용Docker Hub or Azure Container Registry as an artifact source

이 기능을 사용하면 릴리스에서 Docker 허브 레지스트리 또는 ACR(Azure Container Registry)에 저장된 이미지를 사용할 수 있습니다.This feature enables releases to use images stored in a Docker Hub registry or an Azure Container Registry (ACR). 이는 ACR의 지역에서 복제 기능을 사용하거나 프로덕션 환경에 대한 이미지만 있는 컨테이너 레지스트리에서 환경(예: 프로덕션)에 배포하여 새로운 지역별 변경 내용을 출시하는 것과 같은 시나리오를 지원하기 위한 첫 번째 단계입니다.This is a first step towards supporting scenarios such as rolling out new changes region-by-region by using the geo-replication feature of ACR or deploying to an environment (such as production) from a container registry that has images for only the production environment.

이제 릴리스 정의의 + 추가 아티팩트 환경에서 Docker 허브 또는 ACR을 최고급 아티팩트로 구성할 수 있습니다.You can now configure Docker Hub or ACR as a first-class artifact in the + Add artifact experience of a release definition. 지금은 릴리스를 수동으로 또는 다른 아티팩트를 통해 트리거해야 하지만, 곧 새 이미지를 레지스트리에 푸시하는 트리거가 추가될 예정입니다.For now the release has to be triggered manually or by another artifact but we look forward to adding a trigger based on the push of a new image to the registry soon.

Docker 허브 아티팩트 소스Dockerhub artifact source

기본 아티팩트 버전Default artifact versions

이제 버전 제어 아티팩트를 릴리스 정의에 연결할 때 몇 가지 기본 버전 옵션이 있습니다.There are now several default version options when linking version control artifacts to a release definition. 특정 커밋/변경 집합을 구성하거나 기본 분기에서 선택할 수 있도록 최신 버전을 구성하기만 하면 됩니다.You can configure a specific commit/changeset or simply configure the latest version to be picked from the default branch. 일반적으로 최신 버전을 선택하도록 구성하지만, 이는 향후의 모든 지속적인 배포에 대해 특별한 아티팩트 버전을 지정해야 하는 일부 환경에서 특히 유용합니다.Normally you configure it to pick up the latest version, but this is especially useful in some environments where a golden artifact version needs to be specified for all future continuous deployments.

기본 아티팩트 버전Default artifact versions

향상된 릴리스 트리거 분기Release triggers branch enhancements

이제 빌드 정의에 지정된 기본 분기를 기반으로 하여 릴리스 트리거 필터를 구성할 수 있습니다.You can now configure a release trigger filter based on the default branch specified in the build definition. 이는 기본 빌드 분기에서 모든 스프린트를 변경하고 릴리스 트리거 필터를 모든 릴리스 정의에서 업데이트해야 하는 경우에 특히 유용합니다.This is particularly helpful if your default build branch changes every sprint and the release trigger filters needs to be updated across all the release definitions. 이제 빌드 정의에서 기본 분기를 변경하기만 하면 모든 릴리스 정의에서 이 분기를 자동으로 사용합니다.Now you just need to change the default branch in the build definition and all the release definitions automatically use this branch. 예를 들어 팀에서 각 스프린트 릴리스 페이로드에 대한 릴리스 분기를 만드는 경우 빌드 정의에서 새 스프린트 릴리스 분기를 가리키도록 업데이트하고 릴리스에서 이를 자동으로 선택합니다.For example, if your team is creating release branches for each sprint release payload, you update it in the build definition to point to a new sprint release branch and the release picks this up automatically.

릴리스 트리거Release triggers

패키지 관리 아티팩트에 대한 릴리스 트리거Release trigger for a package management artifact

이제 릴리스 정의에 패키지 관리 아티팩트에 대한 트리거를 설정하여 새 버전의 패키지가 게시될 때 새 릴리스가 자동으로 만들어지도록 할 수 있습니다.Now you can set a trigger on a Package Management artifact in a Release definition so that a new release is automatically created when a new version of the package has been published. 자세한 내용은 릴리스 관리의 트리거에 대한 설명서를 참조하세요.See the documentation for triggers in Release Management for more information.

특정 환경에 대한 변수 그룹 범위 지정Scope a variable group to specific environments

이전에는 변수 그룹이 릴리스 정의에 추가되면 이 그룹에 포함된 변수를 릴리스의 모든 환경에서 사용할 수 있었습니다.Previously, when a variable group was added to a release definition, the variables it contained were available to all the environments in the release. 이제 변수 그룹을 특정 환경으로 범위를 조정할 수 있습니다.Now, you have the flexibility to scope the variable groups to specific environment(s) instead. 이렇게 하면 단일 환경에서 사용할 수 있지만 동일한 릴리스의 다른 환경에서는 사용할 수 없습니다.This makes them available to one environment but not other environments of the same release. 이는 환경 간에 서로 다른 SMTP 이메일 서비스와 같은 외부 서비스가 있는 경우에 유용합니다.This is great when you have an external service, such as an SMTP email service, which is different between environments.

변수 그룹 연결Link variable group

Azure Container Registry 및 Docker 허브에서 자동으로 릴리스Release automatically from Azure Container Registry and Docker Hub

컨테이너화된 앱을 배포하는 경우 컨테이너 이미지가 먼저 컨테이너 레지스트리에 푸시됩니다.When deploying containerized apps, the container image is first pushed to a container registry. 푸시가 완료되면 컨테이너 이미지를 컨테이너 또는 Kubernetes 클러스터용 웹앱에 배포할 수 있습니다.After the push is complete, the container image can be deployed to a Web App for Containers or a Kubernetes cluster. 이제 Docker 허브 또는 Azure Container Registry 에 저장된 이미지를 아티팩트 소스로 추가하여 업데이트 시 릴리스를 자동으로 만들 수 있습니다.You can now enable automatic creation of releases on updates to the images stored in Docker Hub or Azure Container Registry by adding them as an artifact source.

Azure Container Registry를 소스로 사용Azure Container Registry as a source

Jenkins 아티팩트에 대한 기본 버전 지정Specify a default version for Jenkins artifacts

여러 아티팩트가 있는 릴리스가 자동으로 트리거되면 릴리스 정의에 저장된 기본 버전이 모든 아티팩트에 대해 선택됩니다.When a release with multiple artifacts is auto-triggered, default versions saved in the release definition are picked up for all artifacts. 이전에는 Jenkins 아티팩트에 기본 버전 설정이 없기 때문에 Jenkins를 보조 아티팩트로 사용하는 릴리스에서 지속적인 배포 트리거를 설정할 수 없었습니다.Previously, Jenkins artifacts did not have a default version setting, and so you couldn't set a continuous deployment trigger on a release using Jenkins as the secondary artifact.

이제는 친숙한 옵션을 사용하여 Jenkins 아티팩트에 대한 기본 버전을 지정할 수 있습니다.Now, you can specify a default version for Jenkins artifacts, with the options you are familiar with:

  • 최신 버전Latest
  • 릴리스를 만들 때 지정Specify at the time of release creation
  • 특정 버전Specific version

Jenkins 아티팩트에 대한 기본 버전Default version for Jenkins artifacts

확장에서 릴리스 게이트 참가Contribute release gates from extensions

릴리스 게이트를 사용하면 릴리스 파이프라인에 정보 기반 승인을 추가할 수 있습니다.Release gates enable addition of information driven approvals to the release pipelines. 상태 신호 집합은 배포 이전 또는 이후에 반복적으로 수집되어 릴리스를 다음 단계로 승격해야 하는지 여부를 결정합니다.A set of health signals are collected repeatedly prior to or post deployment, to determine whether the release should be promoted to the next stage or not. 기본 제공 게이트 집합이 제공되며, 지금까지 다른 서비스와 통합하기 위한 수단으로 "Azure 함수 호출"이 권장되었습니다.A set of built-in gates are provided, and "Invoke Azure function" has so far been recommended as a means to integrate with other services. 이제 다른 서비스와 통합하는 경로를 간소화하고 마켓플레이스 확장을 통해 게이트를 추가합니다.We now simplify the route to integrate with other services and add gates through marketplace extensions. 이제 사용자 지정 게이트 작업을 제공하고 릴리스 정의 작성자에게 게이트를 구성하는 향상된 환경을 제공할 수 있습니다.You can now contribute custom gate tasks and provide release definition authors an enhanced experience to configure the gate.

게이트 작업 작성에 대해 자세히 알아보세요.Learn more about authoring gate tasks.

배포 그룹을 사용하여 가상 머신에 배포 확장Scale deployments to Virtual Machines using Deployment Groups

강력한 기본 제공 다중 머신 배포를 제공하는 배포 그룹이 이제 출시되었습니다.Deployment Groups, that gives robust, out-of-the-box multi-machine deployment, is now generally available. 배포 그룹을 사용하면 전체적으로 애플리케이션의 고가용성을 보장하면서 여러 서버에서 배포를 오케스트레이션하고 롤링 업데이트를 수행할 수 있습니다.With Deployment Groups, you can orchestrate deployments across multiple servers and perform rolling updates, while ensuring high availability of your application throughout. 온-프레미스나 Azure 또는 클라우드의 가상 머신에 서버를 배포할 수도 있으며, 배포된 아티팩트 버전을 서버 수준까지 통합 추적할 수 있습니다.You can also deploy to servers on-premises or virtual machines on Azure or any cloud and have end-to-end traceability of deployed artifact versions down to the server level.

에이전트 기반 배포 기능은 이미 사용 가능한 동일한 빌드 및 배포 에이전트에 의존합니다.The agent-based deployment capability relies on the same build and deployment agents that are already available. 배포 그룹 단계에서 대상 컴퓨터의 전체 작업 카탈로그를 사용할 수 있습니다.You can use the full task catalog on your target machines in the Deployment Group phase. 확장성 관점에서 프로그래밍 방식 액세스에 대해 배포 그룹대상의 REST API를 사용할 수도 있습니다.From an extensibility perspective, you can also use the REST APIs for deployment groups and targets for programmatic access.

패키지Package

업스트림 소스를 통해 원활하게 공용 패키지 사용Seamlessly use public packages using upstream sources

이제 nuget.orgnpmjs.com에 대한 업스트림 소스를 사용할 수 있습니다.Upstream sources for nuget.org and npmjs.com are now available. 이점으로, 업스트림 소스에서 저장된 패키지를 관리(나열 취소, 사용 안 함, 게시 취소, 삭제 등)하는 기능과 사용하는 모든 업스트림 패키지를 저장하도록 보장하는 기능이 있습니다.Benefits include the ability to manage (unlist, deprecate, unpublish, delete, etc.) packages saved from upstream sources as well as guaranteed saving of every upstream package you use.

npmjs 업스트림npmjs upstream

TFS 피드의 보존 정책Retention policies in TFS feeds

지금까지 TFS 패키지 피드는 사용되지 않는 이전의 패키지 버전을 자동으로 정리하는 방법을 제공하지 않았습니다.Until now, TFS package feeds have not provided any way to automatically clean up older, unused package versions. 빈번한 패키지 게시자의 경우 일부 버전을 수동으로 삭제할 때까지 NuGet 패키지 관리자 및 다른 클라이언트의 피드 쿼리 속도가 느려질 수 있습니다.For frequent package publishers, this could result in slower feed queries in the NuGet Package Manager and other clients until some versions were manually deleted.

이제 TFS 피드에 보존 정책을 사용하도록 설정했습니다.We have now enabled retention policies on TFS feeds. 보존 임계값이 충족되면 보존 정책에서 가장 오래된 버전의 패키지를 자동으로 삭제합니다.Retention policies automatically delete the oldest version of a package once the retention threshold is met. 보기로 승격된 패키지는 무기한 보존되므로 프로덕션 환경에서 사용되거나 조직 전체에서 널리 사용되는 버전을 보호할 수 있습니다.Packages promoted to views are retained indefinitely, giving you the ability to protect versions that are used in production or used widely across your organization.

보존 정책을 사용하도록 설정하려면 피드를 편집하고 보존 정책 섹션의 패키지당 최대 버전 수 에 값을 입력합니다.To enable retention policies, edit your feed and enter a value in the Maximum number of versions per package in the Retention policies section.

보존retention

패키지 관리에서 필터링Filtering in package management

표준 페이지 레이아웃, 명령 모음 컨트롤 및 새 표준 필터 모음을 사용하도록 패키지 페이지가 업데이트되었습니다.The Packages page has been updated to use our standard page layout, command bar control, and the new standard filter bar.

패키지 UX 통합 필터 모음Package UX unified filter bar

배지를 사용하여 패키지 공유Share your packages using a badge

오픈 소스 커뮤니티에서는 일반적으로 리포지토리의 추가 정보에서 최신 버전의 패키지에 연결되는 배지를 사용합니다.In the open source community, it is common to use a badge that links to the latest version of your package in your repository's README. 이제 패키지에 대한 배지를 피드에 만들 수 있습니다.You can now create badges for packages in your feeds. 피드 설정에서 패키지 배지 사용 옵션을 선택하고, 패키지를 선택한 다음, 배지 만들기 를 클릭하면 됩니다.Just check the Enable package badges option in feed settings, select a package and then click Create badge. 배지 URL을 직접 복사하거나 패키지의 세부 정보 페이지에 배지를 다시 연결하는 미리 생성된 마크다운을 복사할 수 있습니다.You can copy the badge URL directly or copy pre-generated Markdown that links the badge back to your package's details page.

패키지 배지 만들기Create a package badge

이제 전체 페이지 목록으로 변경된 이전 패키지 버전 목록Previous package versions are now a full-page list

업데이트된 패키지 관리 환경에 대해 많은 피드백을 받았습니다. 이에 따라 패키지 세부 정보 페이지에서 이전 패키지 버전 목록을 이동 경로 선택기로 옮겼습니다.We received a lot of feedback on the updated Package Management experience, where we moved the list of previous package versions into a breadcrumb picker on the package details page. 이전 버전에 대한 자세한 정보를 제공하고 버전 번호를 복사하거나 이전 버전으로의 링크를 쉽게 만들 수 있는 새 버전 피벗을 추가했습니다.We have added a new Versions pivot that brings more information about prior versions and makes it easier to copy the version number or get a link to an old version.

버전 목록Versions list

패키지 목록에서 패키지 버전 품질 보기View quality of a package version in the package list

이제 패키지 목록에서 각 패키지 버전의 보기를 보고 품질을 빠르게 확인할 수 있습니다.On the package list, you can now see the view(s) of each package version to quickly determine their quality. 자세한 내용은 릴리스 보기 설명서를 참조하세요.See the release views documentation for more information. 자세한 내용은 ) 설명서를 참조하세요.) documentation for more information.

패키지 목록의 보기Views in package list

Gulp, Yarn 등 인증된 피드 지원Gulp, Yarn, and more authenticated feed support

오늘날 npm 작업은 패키지 관리 또는 외부 레지스트리(예: npm EnterpriseArtifactory)에 있는 인증된 npm 피드와 원활하게 작동하지만, 지금까지 해당 작업에서 인증된 피드를 지원하지 않는 한 작업 실행기(예: Gulp) 또는 대체 npm 클라이언트(예: Yarn)를 사용하는 것이 어려웠습니다.The npm task today works seamlessly with authenticated npm feeds (in Package Management or external registries like npm Enterprise and Artifactory), but until now it has been challenging to use a task runner like Gulp or an alternate npm client like Yarn unless that task also supported authenticated feeds. 후속 작업에서 인증된 피드를 성공적으로 사용할 수 있도록 .npmrc에 자격 증명을 추가하는 새 npm Authenticate 빌드 작업을 추가했습니다.We have added a new npm Authenticate build task that adds credentials to your .npmrc so that subsequent tasks can use authenticated feeds successfully.

인증된 피드Auth feeds

프로젝트 관리자가 포함된 패키지 피드 기본 권한Package feed default permissions now include Project Administrators

이전에는 피드를 만드는 경우 만드는 사용자를 유일한 피드 소유자로 설정하여 해당 사용자가 팀을 전환하거나 조직을 떠날 때 대규모 조직에 관리상의 문제가 발생할 수 있습니다.In the past, creating a feed sets the creating user as the only feed owner, which can cause administration challenges in large organizations if that user switches teams or leaves the organization. 이 단일 실패 지점을 제거하기 위해 이제 피드를 만들 때 사용자의 현재 프로젝트 컨텍스트를 사용하여 프로젝트 관리자 그룹을 가져와서 피드 소유자로 만듭니다.To remove this single point of failure, creating a feed now uses the user's current project context to get the Project Administrators group and make it an owner of the feed as well. 다른 모든 권한과 마찬가지로, 이 그룹을 삭제하고 피드 설정 대화 상자를 사용하여 피드 권한을 추가로 사용자 지정할 수 있습니다.As with any permission, you can remove this group and further customize feed permissions using the feed settings dialog.

패키지 재활용 및 복원Recycle and restore packages

사용하지 않는 패키지를 삭제하면 패키지 목록을 깨끗하게 유지하는 데 도움이 되지만 실수로 삭제할 수 있는 경우도 있습니다.Deleting unused packages can help keep the package list clean but sometimes it can be done by mistake. 이제 휴지통 에서 삭제된 패키지를 복원할 수 있습니다.Now you can restore deleted packages from the Recycle Bin. 삭제된 패키지는 30일 동안 휴지통에서 보관되어 필요한 경우 복원하는 데 충분한 시간을 제공합니다.Deleted packages are retained in the Recycle Bin for 30 days, giving you ample time to restore if you need to.

패키지 휴지통Package recycle bin

과거에 패키지 허브에 있는 패키지에 URL을 공유할 수도 있었지만, 링크를 사용하는 사용자에게 적용될 수도 있고 적용되지 않을 수도 있는 프로젝트를 URL에 포함해야 하기 때문에 사용하기가 어려웠습니다.Although you could share the URL to a package found in the Packages hub in the past, it was often difficult to use because you needed to include a project in the URL, that may or may not apply to those using the link. 이제 이 업데이트를 사용하면 받는 사람이 액세스할 수 있는 프로젝트를 자동으로 선택하는 URL을 사용하여 패키지를 공유할 수 있습니다.With this Update, you can now share packages using a URL that automatically select a project the recipient has access to.

URL 형식은 `https://<TFSserverURL>/_packaging?feed=<feed>&package=<package>&version=<version>&protocolType=<NuGet|Npm|Maven>&_a=package` 입니다.The URL format is: `https://<TFSserverURL>/_packaging?feed=<feed>&package=<package>&version=<version>&protocolType=<NuGet|Npm|Maven>&_a=package`

`<TFSserverURL>`를 제외한 모든 매개 변수는 선택 사항이지만, 패키지를 제공하는 경우 프로토콜 유형을 제공해야 합니다.All parameters except `<TFSserverURL>` are optional, but if you provide a package, you must provide the protocol type.

테스트Test

Visual Studio 전체가 필요하지 않은 Visual Studio 테스트 작업 Visual Studio Test task does not need full Visual Studio

빌드/릴리스의 Visual Studio 테스트 작업에는 에이전트에서 테스트를 실행하기 위해 Visual Studio가 필요합니다.The Visual Studio Test task in build/release requires Visual Studio on the agent to run tests. 프로덕션 환경에서 테스트를 실행하거나 단순히 여러 에이전트에 테스트를 배포하기 위해 Visual Studio를 설치하는 대신 새로운 Visual Studio 테스트 플랫폼 설치 관리자 작업을 사용합니다.Rather than installing Visual Studio to run tests in production environments or for merely distributing tests over multiple agents, use the new Visual Studio Test Platform Installer task. 이 작업은 nuget.org에서 테스트 플랫폼을 가져와서 도구 캐시에 추가합니다.This task acquires the test platform from nuget.org and adds it to the tools cache. 설치 관리자 작업은 vstest 요구 사항을 충족하고, 정의에 있는 후속 Visual Studio 테스트 작업은 Visual Studio 전체를 에이전트에 설치할 필요 없이 실행할 수 있습니다.The installer task satisfies the vstest demand and a subsequent Visual Studio Test task in the definition can run without needing a full Visual Studio install on the agent.

작업 카탈로그에서 설치 관리자 작업을 정의에 추가합니다.From the task catalog, add the installer task in your definition.

플랫폼 설치 관리자 작업Platform Installer task

후속 Visual Studio 테스트 작업에서 설치 관리자를 통해 얻은 비트를 사용하도록 구성합니다.Configure the subsequent Visual Studio Test task to use the bits acquired through the installer.

테스트 플랫폼 버전Test platform version

참고

제한 사항: NuGet의 테스트 플랫폼 패키지는 현재 코딩된 UI 테스트 실행을 지원하지 않습니다.Limitations: The Test Platform package on NuGet currently does not support running Coded UI test. 코딩된 UI 테스트에 대한 지원 사용은 백로그로 있습니다.Enabling support for Coded UI test is on the backlog. NuGet의 테스트 플랫폼 패키지는 플랫폼 간 패키지이지만 VSTest 작업은 현재 .NET 핵심 테스트 실행을 지원하지 않습니다.The Test Platform package on NuGet is cross-platform, but VSTest task currently does not support running .NET core tests. .NET 핵심 테스트를 실행하려면 'dot net' 작업을 사용합니다.To run .NET core tests, use the 'dot net' task.

기능 테스트 실행 및 테스트 에이전트 배포 작업은 이제 더 이상 사용되지 않습니다.Run Functional Tests and Deploy Test Agent tasks are now deprecated

작년에 빌드, 릴리스 및 테스트에서 에이전트를 통합하기 위한 여정을 시작했습니다.Last year, we started on the journey to unify agents across build, release, and test. 이는 WinRM 기반 테스트 에이전트 배포기능 테스트 실행 작업과 관련된 다양한 문제점을 해결하기 위한 것입니다.This was intended to address various pain points associated with using WinRM based Deploy Test Agent and Run Functional Tests tasks. 또한 모든 테스트 요구에 대해 다음을 포함한 VSTest(Visual Studio 테스트) 작업을 사용할 수 있습니다.It also enables you to use the Visual Studio Test (VSTest) task for all your testing needs, including:

  • 단위 테스트Unit tests
  • 기능(UI/비UI) 테스트Functional (UI/non-UI) tests
  • MSTest 기반 테스트MSTest based tests
  • 타사 프레임워크 기반 테스트Third party framework-based tests
  • 어셈블리 기반 테스트 사양 또는 테스트 계획/테스트 도구 모음을 사용하여 테스트 실행Assembly-based test specification or running tests with Test Plan/Test Suite
  • 단일 에이전트 테스트 실행 및 여러 에이전트에 대한 테스트 배포Single agent test execution as well as distributing tests over multiple agents

또한 관리자는 통합 에이전트 방법을 통해 CI/CD에 사용되는 모든 머신을 일관된 방식으로 관리할 수 있습니다.The unified agents approach also allows administrators to manage all machines that are used for CI/CD in a uniform manner.

Visual Studio 테스트 작업Visual Studio Test task

이 기능을 사용할 수 있도록 다음과 같은 몇 가지 중요한 부분을 제공했습니다.We have delivered several crucial pieces to enable this capability, including:

이제 위의 모든 요소들이 제대로 갖추어졌으므로 다음 두 가지 작업을 평가할 준비가 되었습니다.With all the above now in place, we are ready to deprecate these two tasks. 사용되지 않는 작업을 사용하는 기존 정의는 계속 작동하지만, 시간이 지남에 따라 VSTest를 사용하여 지속적인 향상된 기능을 활용하도록 전환하는 것이 좋습니다.While existing definitions that use the deprecated tasks will continue to work, we encourage you to move to using VSTest to take advantage of continued enhancement over time.

큰 테스트 결과 필터링Filter large test results

시간이 지남에 따라 테스트 자산이 누적되고 대규모 애플리케이션이 무수한 테스트로 쉽게 확장될 수 있습니다.Over time test assets accrue, and large applications can easily grow to thousands of tests. 팀에서는 테스트 실패, 관련 근본 원인 또는 문제의 소유권을 확인하면서 생산성을 높이기 위해 많은 양의 테스트 결과 집합을 탐색하는 더 나은 방법을 찾고 있습니다.Teams are looking for better ways to navigate through large sets of test results to be productive while identifying test failures, associated root cause, or ownership of issues. 이 기능을 사용할 수 있도록 [빌드 및 릴리스]의 테스트 탭 아래에 3개의 새 필터, 즉 테스트 이름, 컨테이너(DLL) 및 소유자(컨테이너 소유자)를 추가했습니다.To enable this, we have added three new filters under Tests Tab in Build and Release as Test Name, Container (DLLs) and Owner (Container Owner).

테스트 이름별 테스트 필터링Filter test by test name

또한 기존의 결과 필터는 이제 여러 결과에 대한 필터링 기능을 제공합니다.Additionally, the existing Outcome filter now provides the ability to filter for multiple outcomes. 사실상 다양한 필터 기준이 누적됩니다.The various filter criterion are cumulative in nature. 사용자가 방금 커밋한 변경에 대한 테스트 결과를 보려는 경우 컨테이너(DLL 이름), 소유자(DLL 소유자), 테스트 이름 또는 이 모든 항목에 대해 필터링하여 사용자와 관련된 결과를 얻을 수 있습니다.As a user, when I want to see the outcome of my tests for a change I just committed, I can filter on the Container (DLL name), Owner (DLL owner), Test Name, or all of them, to get to the results relevant to me.

테스트 결과 필터링Filter test outcome

잘 끊어지는 테스트 식별Identify flaky tests

때로는 테스트가 잘 끊어집니다. 즉 한 실행에서 실패하고, 다른 실행에서 아무런 변경 없이 통과됩니다.Sometimes tests are flaky - they fail on one run and pass on another without any changes. 잘 끊어지는 테스트는 실망스러울 수 있으며 테스트 유효성에 대한 신뢰가 훼손됩니다. 이에 따라 오류가 무시되고 버그가 발생합니다.Flaky tests can be frustrating and undermines confidence in test effectiveness - causing failures to be ignored and bugs to slip through. 이 업데이트를 통해 잘 끊어지는 테스트 문제를 해결할 수 있는 첫 번째 솔루션을 배포했습니다.With this Update, we have deployed the first piece of a solution to help tackle the problem of flaky tests. 이제 실패한 테스트를 다시 실행하도록 Visual Studio 테스트 작업을 구성할 수 있습니다.You can now configure the Visual Studio Test task to re-run failed tests. 그런 다음, 테스트 결과에서는 처음에는 테스트가 실패했으며 다시 실행에서 통과되었음을 나타냅니다.The test results then indicate which tests initially failed and then passed on re-run. 순서가 지정된 데이터 기반 테스트에 대한 다시 실행 지원은 나중에 제공될 예정입니다.Support for re-run of data driven and ordered tests are coming later.

Visual Studio 테스트 작업은 실패한 테스트를 다시 실행하는 최대 시도 횟수 및 광범위하게 분산된 오류가 발생하는 경우 테스트를 다시 실행하지 않도록 하는 실패에 대한 임계값 비율(예: 모든 테스트의 20% 미만이 실패한 경우에만 테스트 다시 실행)을 제어하도록 구성할 수 있습니다.The Visual Studio Test task can be configured to control the maximum number of attempts to re-run failed tests and a threshold percentage for failures (e.g. only re-run tests if less than 20% of all tests failed) to avoid re-running tests in event of wide spread failures.

실패한 테스트 다시 실행 섹션Re-run failed test section

빌드 및 릴리스 아래의 테스트 탭에서 테스트 결과를 “다시 실행에서 통과됨”으로 필터링하여 실행 중에 불안정한 동작이 있었던 테스트를 파악할 수 있습니다.In the Tests tab under Build and Release, you can filter the test results with Outcome as "Passed on rerun" to identify the tests that had an unreliable behavior during the run. 현재는 다시 실행에서 통과된 각 테스트의 마지막 시도가 표시됩니다.This currently shows the last attempt for each test that passed on re-run. 총 테스트 아래에서 “다시 실행에서 통과됨(n/m)”을 표시하도록 요약 보기도 수정되었습니다. 여기서 n은 다시 실행에서 통과된 테스트의 수이고, m은 통과된 총 테스트의 수입니다.The Summary view is also modified to show "Passed on rerun (n/m)" under Total tests, where n is the count of tests passed on re-run and m is total passed tests. 모든 시도에 대한 계층적 보기는 다음 몇 가지 스프린트에 제공됩니다.A hierarchical view of all attempts is coming in next few sprints.

실패한 테스트 다시 실행 결과Re-run failed test results

Visual Studio Test 작업에서 생성된 여러 로그 유형에 대해 향상된 기능 및 지원 미리 보기Preview improvements and support for different log types generated by Visual Studio Test task

실패한 테스트에 대한 표준 출력 및 표준 오류에 해당하는 여러 종류의 로깅 문으로 생성된 로그를 게시하도록 VSTest 작업이 향상되었습니다.We enhanced the VSTest task to publish logs generated by different kind of logging statements corresponding to standard output and standard error for failed tests. 또한 로그 파일에서 검색할 수 있는 기능과 함께 텍스트 및 로그 파일 형식을 볼 수 있도록 미리 보기 환경도 향상되었습니다.We have also improved the preview experience to support viewing text and log file formats, with capability to search in the log files.

WikiWiki

코드 및 작업 항목의 오른쪽에서 제목별 또는 내용별로 즐겨 찾는 Wiki 페이지를 검색할 수 있습니다.You can search for your favorite Wiki pages by title or content right alongside code and work items. Microsoft DevOps 블로그에서 Wiki 검색에 대한 자세한 내용을 참조할 수 있습니다.You can read more about Wiki search in the Microsoft DevOps Blog.

Wiki 는 다양한 콘텐츠에 사용할 수 있습니다.Wiki can be used for a variety of content. 경우에 따라 Wiki 의 콘텐츠를 인쇄하여 여유 시간에 읽거나, 펜과 종이로 주석을 추가하거나, 오프라인 PDF 복사본을 VSTS 프로젝트 외부의 사용자와 공유하는 것이 유용할 수도 있습니다.Sometimes it can be useful to print content from Wiki to read in your spare time, add comments using pen and paper, or even share an offline PDF copy with those outside of your VSTS project. 이제는 페이지의 바로 가기 메뉴를 클릭하고 페이지 인쇄 를 선택하면 됩니다.Now, simply click on the context menu of a page and select Print page.

Wiki 메뉴 인쇄 페이지 옵션Wiki menu print page option

참고

이 기능은 현재 Firefox에서 지원되지 않습니다.Currently this feature is not supported on Firefox.

바로 가기 키를 사용하여 Wiki 페이지에 쉽게 참여Contribute to Wiki pages with ease using keyboard shortcuts

이제 바로 가기를 사용하여 키보드만으로 Wiki 의 일반적인 편집 및 보기 작업을 더 빠르게 수행할 수 있습니다.You can now use shortcuts to perform common edit and view actions in Wiki even faster using only your keyboard.

다음과 같이 페이지를 보면서 하위 페이지를 추가하거나 편집하거나 만들 수 있습니다.While viewing a page, you can add, edit, or create a subpage, for example:

Wiki 보기 바로 가기 키 팝업Wiki view keyboard shortcuts popup

페이지를 편집하면서 빠르게 저장하거나, 저장 후 닫거나, 단순히 닫을 수 있습니다.While editing a page, you can quickly save, save and close, or just close.

Wiki 편집 바로 가기 키 팝업Wiki edit keyboard shortcuts popup

이러한 바로 가기는 굵게 의 경우 Ctrl+B, 기울임꼴 의 경우 Ctrl+I, 링크 설정의 경우 Ctrl+K 등과 같은 표준 편집 바로 가기에 추가되어 있습니다. 자세한 내용은 바로 가기 키 전체 목록을 참조하세요.These are in addition to standard editing shortcuts such as Ctrl+B for bold, Ctrl+I for italics, Ctrl+K for linking etc. See the full list of keyboard shortcuts for more information.

코드 리포지토리 마크다운에 서식 있는 마크다운 렌더링Rich markdown rendering in code repo markdown

이제 코드 리포지토리에 서식 있는 README.MD 파일을 만들 수 있습니다.You can now create rich README.MD files in the code repositories. 코드 리포지토리에 있는 MD 파일의 마크다운 렌더링은 이제 HTML 태그, 블록 따옴표, 이모지, 이미지 크기 조정 및 수식을 지원합니다.The markdown rendering of the MD files in code repositories now supports HTML tags, Block quotes, Emojis, image resizing, and mathematical formulas. 코드에서 Wiki 및 MD 파일의 마크다운 렌더링에는 패리티가 있습니다.There is parity in markdown rendering in Wiki and MD files in code.

수식을 지원하는 WikiWiki supports mathematical formulas

애플리케이션에서 수식과 방정식을 처리하는 경우 이제는 LaTeX 형식을 사용하여 Wiki에 넣을 수 있습니다.If your application deals with mathematical formulas and equations, you can now put them in Wiki using the LaTeX format.

Wiki 수식Wiki math

Wiki에서 작업 항목 참조Reference work items in Wiki

이제 '#' 키를 눌러 가장 최근에 액세스한 작업 항목의 목록을 가져오고 관심 있는 작업 항목을 선택하여 Wiki 페이지에서 작업 항목을 참조할 수 있습니다.Now you can reference work items in Wiki pages by pressing the '#' key to get a list of the most recently accessed work items and selecting the work item of interest. 릴리스 정보, 대규모 사용자 스토리, 사양 또는 작업 항목을 참조해야 하는 다른 페이지를 작성하는 경우에 특히 유용합니다.This is particularly useful while writing release notes, epics, specs, or other pages that require referring to a work item.

Wiki에서 작업 항목 참조Reference work items in Wiki

이제 작업 항목을 Wiki에 연결하거나 그 반대로도 연결할 수 있습니다.Now you can link a work item to a Wiki and vice versa. 작업 항목을 Wiki에 연결하여 대규모 사용자 스토리 페이지, 릴리스 정보 및 Wiki 페이지와 관련된 작업 항목을 추적하고 대규모 사용자 스토리 페이지가 완성된 비율을 확인하는 데 도움이 되는 계획 콘텐츠를 만들 수 있습니다.You can link work items to Wiki to create epic pages, release notes, and planning content that helps you track the work items associated with a Wiki page and validate what percentage of your epic page is complete.

Wiki에서 작업 항목 연결Link work items from a Wiki

연결된 작업 항목이 Wiki 페이지에 표시됩니다.Linked work items then show up on the Wiki page.

Wiki 페이지에 연결된 작업 항목Linked work items on Wiki page

새로운 “Wiki 페이지” 링크 형식을 통해 작업 항목의 Wiki 페이지에 대한 링크를 추가합니다.Add a link to a Wiki page from a work item through the new "Wiki page" link type.

작업 항목에서 Wiki에 연결Link to Wiki from work item

Wiki 페이지를 저장하는 Ctrl+SCtrl+S to save Wiki page

Wiki 페이지를 더 빠르고 더 쉽게 저장하는 방법을 원하는 경우가 많았습니다.We heard you wanted a quicker and easier way to save a Wiki page. 이제는 단순히 Ctrl+S 바로 가기 키를 사용하여 페이지를 기본 수정 메시지로 저장한 다음, 계속 편집할 수 있습니다.Now you can simply use Ctrl+S keyboard shortcut to save a page with a default revision message and continue editing. 사용자 지정 수정 메시지를 추가하려면 저장 단추 옆의 펼침 단추를 클릭하면 됩니다.If you would like to add a custom revision message just click on the chevron next to the save button.

Wiki 저장Wiki save

서식 있는 Wiki 콘텐츠를 HTML로 붙여넣기Paste rich Wiki content as HTML

이제 Confluence, OneNote, SharePoint 및 MediaWiki와 같은 브라우저 기반 애플리케이션의 Wiki 마크다운 편집기에서 서식 있는 텍스트를 붙여넣을 수 있습니다.You can now paste rich text in the markdown editor of Wiki from any browser-based applications such as Confluence, OneNote, SharePoint, and MediaWiki. 이는 복잡한 테이블과 같은 서식 있는 콘텐츠를 만들고 Wiki 에 표시하려는 사용자에게 특히 유용합니다.This is particularly useful for those who have created rich content such as complex tables and want to show it in Wiki. 콘텐츠를 복사하여 HTML로 붙여넣기만 하면 됩니다.Simply copy content and paste it as HTML.

서식 있는 Wiki 콘텐츠를 HTML로 붙여넣기Wiki rich content as HTML

Wiki에서 키보드를 사용하여 페이지 이동Move page in Wiki using keyboard

이전에는 사용자가 Wiki 에서 키보드를 사용하여 페이지를 다시 정렬하거나 페이지를 부모로 다시 지정할 수 없었으며, 이로 인해 키보드 조작을 선호하는 사용자에게 영향을 주었습니다.Earlier in Wiki, users could not reorder or re-parent pages using keyboard and this would impact users who prefer with keyboard operations. 이제는 Ctrl+Up 또는 Ctrl+Down 명령을 사용하여 페이지를 다시 정렬할 수 있습니다.Now you can reorder pages by using Ctrl + Up or Ctrl + Down commands. 페이지의 바로 가기 메뉴에서 페이지 이동 을 클릭하여 해당 페이지를 부모로 다시 지정하고, 새 부모 페이지를 선택하여 이동할 수도 있습니다.You can also re-parent pages by clicking Move page in the context menu of a page and select the new parent page to move.

Wiki 페이지 이동Move Wiki page

Wiki 페이지 이동 대화 상자Move Wiki page dialog

텍스트 강조 표시 필터링Filter text highlighting

Wiki 에서 탐색 창을 필터링하면 전체 페이지 계층 구조가 표시됩니다.Filtering the navigation pane in Wiki shows the entire page hierarchy. 예를 들어 “foobar”라는 제목의 페이지를 필터링하면 필터링된 탐색 창에 부모 페이지도 모두 표시됩니다.For example, if you filter a page titled "foobar" the filtered navigation pane would show all parent pages as well. 이로 인해 “foobar”라는 제목이 지정되지 않은 페이지가 필터링된 결과 집합에 표시되는 이유가 혼동될 수 있습니다.This can cause confusion as to why pages not titled "foobar" are showing up in filtered sets of results. 이제는 Wiki 에서 콘텐츠를 필터링하면 검색 중인 텍스트가 강조 표시되어 필터링된 제목과 그렇지 않은 제목을 명확하게 보여줍니다.Now, filtering content in Wiki highlights the text being searched to give a clear picture of the titles that are filtered and those that are not.

Wiki의 텍스트 강조 표시 필터링Filter text highlighting in Wiki

모든 코드 탐색 창에서도 비슷한 동작을 관찰할 수 있습니다.You will observe similar behavior in all code navigation panes as well. 예를 들어 끌어오기 요청, 커밋, 변경 집합 및 보류 집합의 파일 탐색 창이 있습니다.For example, the file navigation pane in pull requests, commits, changesets, and shelvesets.

PR의 텍스트 강조 표시 필터링Filter text highlighting in PR

Wiki 페이지 편집 시 콘텐츠 미리 보기Preview content as you edit Wiki pages

데이터에 따르면, 사용자가 콘텐츠를 편집하는 동안 거의 항상 Wiki 페이지를 여러 번 미리 봅니다.Data shows that users almost always Preview a Wiki page multiple times while editing content. 사용자는 각 페이지 편집마다 미리 보기 를 평균적으로 1-2회 클릭합니다.For each page edit, users click on Preview 1-2 times on average. 이로 인해 느리고 최적화되지 않은 편집 환경이 되고, 특히 마크다운을 처음 사용하는 사용자에게는 시간이 많이 걸릴 수 있습니다.This results in a slow and sub-optimal edit experience and can be particularly time consuming for those new to markdown. 이제는 편집하면서 페이지의 미리 보기를 볼 수 있습니다.Now you can see the preview of your page while editing.

Wiki 미리 보기Wiki preview

일반General

프로필 카드Profile Cards

TFS에는 특정 개인과 관련된 정보(예: 개인이 만든 끌어오기 요청, 개인에게 할당된 작업 항목 등)가 표시되는 여러 영역이 있습니다.There are multiple areas in TFS where information associated to a particular individual is shown, such as, but not limited to: pull requests created by an individual, and work items assigned to an individual. 그러나 완전한 컨텍스트를 얻는 데 필요한 개인 자체에 대한 정보는 제한되어 있습니다.However, there is limited information about the individual itself for you to gain complete context. TFS에서는 새 프로필 카드가 기존 프로필 카드를 대체합니다.The new Profile Card replaces the existing profile card in TFS. 업데이트된 프로필 카드를 사용하면 TFS 계정 내의 사용자와 상호 작용하고 이들에 대해 자세한 정보를 확인할 수 있습니다.The updated profile card allows you to interact with and learn more about users within your TFS account. 기본 이메일 및 IM 클라이언트와 통합함으로써 AD(Active Directory) 사용자가 이메일을 보내고 프로필 카드에서 직접 채팅을 시작할 수 있습니다.Through integrations with your default email and IM client, Active Directory (AD) users can send emails and start chats directly from the profile card. 또한 AD 사용자는 프로필 카드 내에서 조직 계층 구조도 볼 수 있습니다.AD users can also see the organizational hierarchy within the profile card. 연락처 카드 아이콘, 프로필 사진 또는 주석 내의 사용자 이름을 클릭하여 프로필 홈 페이지(팀 멤버 섹션, 버전 제어, 작업 항목 및 Wiki 섹션) 내에서 프로필 카드를 활성화할 수 있습니다.Profile cards can be activated within project home page - team members section, version control, work items and Wiki sections by clicking on the contact card icon, profile picture, or users name within comments.

프로필 카드profile cards

원형 아바타Circle avatars

이제 원형 아바타가 있습니다!Circle avatars are here! 서비스의 모든 프로필 사진이 정사각형 대신 원 모양으로 표시됩니다.All profile pictures in the service now displays in a circle shape, rather than a square. 예를 들어 이 변경에 대한 실제 끌어오기 요청이 있습니다(정사각형 아바타가 아니라 원형 아바타 참조).As an example, here is the actual pull request for this change (note the circular, non-square avatars).

원형 아바타Circle avatars

프로젝트 태그Project tags

이제 중요한 키워드(태그)로 프로젝트를 표시할 수 있습니다.You can now adorn projects with important keywords (tags). 관리자가 프로젝트 홈 페이지에서 직접 태그를 쉽게 추가하거나 삭제하므로 사용자는 프로젝트의 목적과 범위에 대한 자세한 정보를 더 빨리 파악할 수 있습니다.Tags are easily added and deleted directly from the project home page (by administrators) allowing users to quickly understand more about the purpose and scope of the project. 프로젝트 태그를 활용하는 방법에 대해 많은 계획이 준비되었으므로 더 많은 뉴스를 기대해 주세요.We have more planned for how project tags can be leveraged, so stay tuned for more news here.

프로젝트 태그Project tags

즐겨찾는 그룹 다시 정렬Re-order favorite groups

이제 각 그룹 머리글에 있는 위쪽 및 아래쪽 화살표를 사용하여 계정의 내 즐겨찾기 페이지에 있는 그룹을 다시 정렬할 수 있습니다.You can now re-order the groups on the account My favorites page using the up and down arrows in each group header.

즐겨찾는 그룹 다시 정렬


피드백 및 제안Feedback & Suggestions

Microsoft는 여러분의 의견을 기다리고 있습니다!We would love to hear from you! 개발자 커뮤니티를 통해 문제를 보고 및 추적하고 Stack Overflow에서 조언을 얻을 수 있습니다.You can report a problem and track it through Developer Community and get advice on Stack Overflow.


맨 위로 이동
Top of Page