Team Foundation Server Rapidshare
NoteThis is not the latest version of Team Foundation Server. To download the latest release, please visit the for Team Foundation Server 2018 Update 3. You can change the language of this page by clicking the globe icon in the and selecting your desired language.In this article, you will find information regarding Team Foundation Server 2017. Click the button to download.To learn more about Team Foundation Server 2017, see the page.Please see the for more information.Release Date: February 28, 2018This update fixes potential cross site scripting (XSS) and other security vulnerabilities. See the for more information. It is a full upgrade, so you can upgrade directly to TFS 2017.0.1.
Release Date: November 16, 2016 Summary of What's New in Team Foundation Server 2017.Known Issues.Details of What's New in Team Foundation Server 2017 Code SearchCode Search provides fast, flexible, and accurate search across all your code. As your codebase expands and is divided across multiple projects and repositories, finding what you need becomes increasingly difficult. To maximize cross-team collaboration and code sharing, Code Search quickly and efficiently locates relevant information across all your projects.From discovering examples of an API's implementation, browsing its definition, to searching for error text, Code Search delivers a one-stop solution for all your code exploration and troubleshooting needs (Figure 1).Code Search offers:. Search across one or more projects. Semantic Ranking.
Rich filtering. Code collaboration(Figure 1) Code SearchFor details, see. Package ManagementPackages enable you to share code across your organization: you can compose a large product, develop multiple products based on a common shared framework, or create and share reusable components and libraries. Package Management (Figure 2) facilitates code sharing by hosting your packages, sharing them with the people you select, and making them easily accessible to Team Build and Release Management.Package Management eliminates the need to host a separate NuGet server or file share by hosting NuGet packages directly in your Team Foundation Server. It has best-in-class support for NuGet 3.x as well as support for NuGet 2.x legacy clients.
It works seamlessly with your existing TFS infrastructure, teams, and permissions, so there is no need to deal with synchronizing identities, managing groups in multiple places, etc. It also integrates easily with Team Build so you can create and use packages in continuous integration workflows.For more details, see the. (Figure 2) Package Management Agile ImprovementsIn Team Foundation Server 2017, we have added new features and functionality to work items and Kanban boards. New work item formThe new work item (Figure 3) form has a new look and feel.
It also adds some great new features:. A rich work item discussion experience. Drag and drop support for attachments.
Improved history experience. Improved code and build integration. State coloring.
Responsive design. NoteThe new work item form is the default for new collections only. If you're migrating an existing collection you will have to enable the new work item form from the admin settings.
For more information, see. (Figure 3) New WIT Form Follow a work itemYou can now setup an alert for tracking changes to a single work item just by clicking on the new 'Follow' button (Figure 4) in the form. When you follow a work item, you will be notified any time the work item changes – including field updates, links, attachments, and comments. (Figure 4) New WIT FormFor details, see. Kanban board live updatesYour Kanban board is now live!Have you been hitting F5 to figure out what is going on throughout the day with your Kanban board?
Try the icon in the screenshot below (Figure 5). (Figure 5) Kanban live updatesWhen anyone in your team creates, updates, or deletes a work item on the board, you will receive live updates on your board immediately. Also, if the administrator makes board or team level updates such as adding a new column or enabling bugs on backlog, you are notified to refresh the board to update your board layout.All you need to do is enable the tower icon on your Kanban board and start collaborating with your team.For more information, see. Checklist improvementsWe have made several improvements to how Checklists work.Checklists titles now appear as hyperlinks (Figure 6).
You can click on the title to open the work item form. (Figure 6) Checklist hyperlinksChecklists now also support context menus that allow you to open, edit, or delete checklist items (Figure 7). (Figure 7) Checklist context menuFor details, see. Epic and Feature Board Drill-downYou now have the ability to drill down on your Epic and Feature boards (Figure 8). The checklist format lets you easily mark work as completed, and provides a handy bird's eye view of the completed versus outstanding work. (Figure 8) Epic Feature drilldownFor more information, see. Turning board annotations on/offWe are giving you more control of the additional information that shows on the cards on your boards.
You can now select annotations that you want to view on your Kanban cards (Figure 9). Simply unselect an annotation and it disappears from the cards on your Kanban board. The first two annotations to show up here are child work items (tasks in this example) and the Test annotation. (Figure 9) Turn on/off board annotationsFor more information, see.
Clear formatting commandWe have added a new command to all rich text controls on work items that lets you clear all formatting from selected text. If you're like most users, you've probably been burned in the past by copying and pasting formatted text into this field that you cannot undo (or clear).
Now you can simply highlight any text, select the Clear Formatting toolbar button (or press CTRL+Spacebar), and you will see the text return to its default format. Filtering in Kanban boardPersonalize your Kanban boards by setting filters on users, iterations, work item types, and tags (Figure 10). These filters persist so that you can view your personalized board, even when you connect from multiple devices. (Figure 10) Filtering in KanbanTeam members can also filter their boards to view progress accruing to a specific parent work item. For example, a user can view user stories that are linked to a feature, or view work across two or more features that roll up to an epic. This feature, much like Checklists, is one more step in our effort to bring visibility through to the different backlog levels.For details, see.
Default iteration path for new work itemsWhen you create a new work item from the Queries tab or from the New Work Item dashboard widget, the iteration path of that work item is always set to the current iteration. This is not what all teams want, because it means that bugs could show up on the task board immediately. With this improvement, teams can choose the default iteration path (a specific one or the current iteration) that should be used for new work items. Navigate to the administration area for your team to choose a default iteration.For more information, see the page. Checkbox controlYou can now add a checkbox control to your work items (Figure 11). This new field type (Boolean) has all the properties of normal fields and can be added to any type in your process.
When displayed on cards or in a query result, the value is shown as True/False. (Figure 11) Checkbox controlFor details, see. Tags bulk editingYou can now add and remove tags from multiple work items using the bulk edit dialog (Figure 12). (Figure 12) Bulk edit dialogFor details, see. New extension pointsWe have added a new contribution point on the board and backlog pages to allow you to write extensions as a pivot tab next to Board/Backlog/Capacity tabs.We have exposed a new extension point on the backlog.
Extensions can target the pane on the right side, where mapping and work details are today (Figure 13). (Figure 13) Backlog extension pointsFor more information on extensions, see. Email improvementsWe have significantly improved the formatting and usability of work item alerts, follows, and @mention emails sent by TFS (Figure 14). Emails now include a consistent header, a clear call to action, and improved formatting to make sure the information in the mail is easier to consume and understand.
Using Team Foundation Server
Additionally, all these emails are being designed to ensure they render well on mobile devices. (Figure 14) Email improvementsFor more information, see. Work item templatesWe added the ability to create rich work item templates directly into the native web experience (Figure 15). This capability was previously very limited in the web, and only available in this new form through a Visual Studio power tool. Teams can now create and manage a set of templates for quickly modifying common fields. (Figure 15) Work item templatesFor details, see.
Project server integration no longer supportedTeam Foundation Server 2017 and later versions no longer support Project Server integration. As of RC2, if you upgrade a TFS database that has Project Server integration configured, you will receive the following warning:We have detected that you have Project Server integration configured for this database. Team Foundation Server 2017 and later versions no longer support Project Server integration.After upgrade, the Project Server integration no longer operates.Going forward, we will be relying on Partners to provide integration solutions.For more information on this change, please read the following topic:. Dashboards and Widgets ImprovementsTeam Foundation Server 2017 has made improvements on multiple widgets, such as the Query Tile and Pull Request widgets. Redesigned widget catalogWe have redesigned our widget catalog to accommodate the growing set of widgets and deliver a better overall experience (Figure 16). The new design includes an improved search experience and has been restyled to match the design of our widget configuration panels. (Figure 16) Widget catalogFor more details, see.
Widget updatesThe Query Tile widget now supports up to 10 conditional rules and has selectable colors (Figure 17). This is extremely handy when you want to use these tiles as key performance indicators (KPI) to identify health and/or action that may be needed. (Figure 17) Dashboard updatesThe Pull Request widget now supports multiple sizes, allowing users to control the height of the widget. We're working on making most of the widgets we ship resizable, so look for more here.The New Work Item widget now allows you to select the default work item type, instead of forcing you to select the most common type you're creating over and over from the drop-down list.We have made the WIT chart widgets resizable.
This allows users to see an expanded view of any WIT chart on the dashboard regardless of its original size.We have updated the Team Members widget to make it easier to add somebody to your team (Figure 18). (Figure 18) Widget UpdateTeams can now configure the size of the dashboard's Query Results widget, allowing it to display more results.The Sprint Overview widget has been redesigned making it easier for teams to see if they are on track.The Assigned to Me widget helps users manage the work assigned to them without leaving the dashboard context (Figure 19). By providing a widget dedicated to this purpose, team admins can add this functionality to their dashboards with 16 fewer clicks, no context switches and no typing required. Users can now view, sort, filter, and manage the work assigned to them within the widget context. (Figure 19) Assigned to me Dashboards REST APIsYou can now use REST APIs to programmatically add, delete, and get information on a dashboard. The APIs also let you add, remove, update, replace, and get information on a widget or a list of widgets on a dashboard.
The documentation is available on. Permissible dashboardsNon-admin users can now create and manage team dashboards. Team admins can restrict non-admin permissions through the dashboard manager.For more information, see. Git ImprovementsSome major changes have been made in Git for Team Foundation Server 2017. Included are a redesign of the Branches page and a new option to 'squash merge'. Redesigned Branches pageThe Branches page has been completely redesigned. Install task scheduler windows xp embedded sp3.
It has a 'mine' pivot that shows the branches you created, pushed to, or favorited (Figure 20). Each branch shows its build and pull requests status, as well as other commands like Delete. If there is a slash in a branch name, like 'features/jeremy/fix-bug', it's shown as a tree, so it's easy to browse through a large list of branches. If you know the name of your branch, you can search to find the one you want quickly.
(Figure 20) Redesigned branches pageFor more details on branches, see. New pull request experienceThe pull request experience has some major updates this release, bringing some really powerful diff capabilities, a new commenting experience, and an entirely refreshed UI.For more details, see. Redesigned UIWhen opening a pull request, the new look and feel is evident immediately (Figure 21). We have reorganized the header to summarize all the critical state and actions, making them accessible from every view in the experience. (Figure 21) Pull request header OverviewThe Overview now highlights the PR Description and makes it easier than ever to give feedback (Figure 22).
Events and comments are shown with the newest items on top to help reviewers see the latest changes and comments front and center. Policies, work items, and reviewers are all provided in detail and reorganized to be more clear and concise. (Figure 22) Pull request overview FilesThe biggest new feature in this release is the ability to see past updates made to a pull request (Figure 23). In previous previews, we released the ability to properly track comments as a PR is updated with changes. However, it's not always easy to see what's between updates. In the Files view, you can now see exactly what changed each time new code is pushed to your PR.
This is very useful if you've given feedback on some code and want to see exactly how it changed, isolated from all the other changes in the review. (Figure 23) Pull request files UpdatesThe new Updates view shows how the PR is changing over time (Figure 24). Where the Files view shows how the files have changed over time, the Updates view shows the commits added in each update. If a force push ever happens, the Updates view will continue to show the past updates as they occurred in history. (Figure 24) Pull request updates Comments, now with markdown and emojiUse the full power of markdown in all your discussions, including formatting, code with syntax highlighting, links, images, and emoji (Figure 25).
The commenting controls also have a more user friendly editing experience allowing multiple comments to be edited (and then saved) at one time. (Figure 25) Pull request comments Add and remove reviewers in pull requestsIt is now easier to add and remove reviewers from your pull requests. To add a reviewer or group to your pull request, simply enter their name into the search box in the Reviewers section. To remove a reviewer, hover over their tile in the Reviewers section and click the X to remove them (Figure 26).
(Figure 26) Add reviewers in pull requests Improved build and pull request traceabilityThe traceability between builds and pull requests has improved, making it easy to navigate from a PR to a build and back. In the build details view for a build triggered by a pull request, the source will now show a link to the pull request that queued the build. In the Build Definitions view, any build triggered by a pull request will provide a link to the pull request in the 'Triggered By' column. Finally, the Build Explorer view will list pull requests in the source column. Comment tracking for pull requestsPull requests in VSTS have been improved to show comments left in files on the proper line, even if those files have been changed since the comments were added. Previously, comments were always shown on the line of the file where they were originally added, even if the file contents changed—in other words, a comment on line 10 would always be shown on line 10.
With the latest improvements, the comments follow the code to show what the user expects—if a comment is added on line 10, and two new lines were subsequently added to the beginning of the file, the comment is shown on line 12.Here is an example change with a comment on line 13 (Figure 27): (Figure 27) Comment trackingEven after the code has changed to shift the line with the original comment from 13 to 14, the comment is appearing in the expected place on line 14 (Figure 28). (Figure 28) Comment tracking with change Auto-complete pull requests waiting on policiesTeams that are using branch policies to protect their branches will want to check out the auto-complete action. Many times, the author of a pull request is ready to merge their PR, but they are waiting on a build to finish before they can click Complete. Other times, the build is passing, but there is one reviewer that has not given the final approval. In these cases, the auto-complete action lets the author set the PR to automatically complete as soon as the policies are all approved (Figure 29).
(Figure 29) Auto-completeJust like the manual complete action, the author has a chance to customize the message of the merge commit and select the appropriate merge options (Figure 30). (Figure 30) AutodialogOnce auto-complete has been set, the PR will display a banner that confirms that the auto-complete is set and waiting for policies to complete (Figure 31). (Figure 31) Auto-complete confirmationWhen all the policies are met (e.g., the build completes, or that final approval is granted), the PR is merged using the options and comments specified. As expected, if there is a build failure or the reviewer does not approve, the PR remains active until the policies are passing. Squash merge pull requestsWhen completing a pull request, you now have the option to squash merge (Figure 32).
This new option produces a single commit containing the changes from the topic branch that is applied to the target branch. The most notable difference between a regular merge and a squash merge is that the squash merge commit will only have one parent commit. This will mean a simpler history graph, as any intermediate commits made to the topic branch will not be reachable in the resulting commit graph. (Figure 32) Squash merge pull requestYou can find more information at. Commit traceabilityBuild status (success or failure) is now clearly visible in the Code Explorer and Commit Details views (Figure 33). More details are just a click away, so you will always know if the changes in the commit passed the build or not.
You can also customize which builds post status in the repository options for the build definition.Additionally, the latest changes to the Commit Details view provide deeper insights about your changes. If you're using pull requests to merge your changes, you will see the link to the pull request that introduced the changes into the master branch (or in the case of a merge commit, the PR that created it). When your changes have reached master, the branch link will appear to confirm that the changes have been included. (Figure 33) Commit Traceability View Git LFS files in the WebIf you're already working with large files in Git (audio, video, datasets, etc.), then you know that Git Large File Storage (LFS) replaces these files with pointers inside Git, while storing the file contents in a remote server. This makes it possible to view the full contents of these large files by simply clicking the file in your repo.For more information, see. Create and send links to specific sections of codeShare code references easily with code links (Figure 34).
Just select text in a file and click the Link icon. It will copy a link to the selected code.
When someone views that link, the code you highlighted will have a gold background. It even works for partial line selections. (Figure 34) Send links to code Status APISuccess or failure of the build is now clearly visible in the code explorer and commit details views (Figure 35).
More details are just a click away, so you always know if the changes in the commit passed the build or not. You can also customize which builds post build status in the repository options for the build definition. (Figure 35) Status API File type iconsYou will see new file icons matching the extension of the file in the explorer, pull requests, commit details, shelveset, changeset or any other view that shows a list of files (Figure 36). (Figure 36) File type examples Add a ReadMe during repo creationThe new Git repository creation has been improved by providing users the ability to add a ReadMe file (Figure 37).
Visual Studio 2015 Professional Download
Adding a ReadMe to the repository not only helps others understand the purpose of the codebase, but also allows you to immediately clone the repository. (Figure 37) Add a ReadMe file Build ImprovementsIn this release, we have increased the size of the logs, added Java build templates, and improvements to our Xamarin support to name a few changes. Redesigned build queue tabWe have implemented a new design for the Queued builds page that shows a longer list of queued and running builds, and in a more intuitive fashion (Figure 38). (Figure 38) Build queue tabFor more information, see. Enable build result extensions to specify order and columnBuild result section extensions can now specify which column and the order in which they appear (Figure 39). The result view has two columns, and all extensions are in the first column by default.
Team Foundation Server
Note: All third-party extensions will appear after the build result sections we include. (Figure 39) Build order and column Build to line numberNow you can jump from a build error to the line of code that caused it.
Looking at the latest error on the primary build we use as a pull request policy internally, you see this (Figure 40): (Figure 40) Build to line number Build log view supports much larger logsThe previous log view only supported logs up to 10,000 lines. The new viewer is based on the Monaco editor used in VS Code and will support logs up to 150,000 lines. Java build templatesWe have made it even easier for Java developers to get started with build by adding build templates for Ant, Maven, and Gradle (Figure 41). (Figure 41) Java build templatesFor more information on templates, see.
Xamarin build tasksWe made some significant improvements to our Xamarin support:. The step now supports Mac and Linux.
The step now supports signing and packaging. results can be displayed on the build summary page. A new step. The step now supports Mac OS.The Xamarin License step is no longer necessary and has been removed from the build templates.
As part of this effort we are deprecating the task. All build definitions that use this task should be updated to remove it in order to prevent any disruption when the task is finally removed.Finally, we have enhanced the Xamarin build definition templates to use these new tasks.
Docker integration for build and release managementTake advantage of the build capabilities to build your Docker images and upload them to the Docker Hub as part of your continuous integration flow (Figure 42). Then, deploy those images to a number of Docker hosts as part of Release Management.
The adds all the service endpoint types and tasks necessary for you to work with Docker. (Figure 42) Docker images SonarQube results in pull request viewIf the build run to merge a pull request contains SonarQube MSBuild tasks, you will now see new code analysis issues as discussion comments in the pull request (Figure 43).
This experience works for any language for which a plug-in is installed on the SonarQube server. For more information, see the blog post. (Figure 43) SonarQube pull requests Configure status API reporting for a build definitionYou can now choose which build definitions report their status back to the Git status API.
This is particularly useful if you have many definitions that build a given repository or branch, but only have one that represents the real health.For more information, see the. Build vNext support in team roomsIt has been always possible to add notifications of XAML builds in the team room. With this sprint, users can also receive notifications from Build vNext completions. Enable path filters for Git CI triggersCI triggers for hosted Git repositories can include or exclude certain paths.
This enables you to configure a build definition to run only when files in specific paths have changed (Figure 44). (Figure 44) Git CI Triggers Release Management ImprovementsSince the introduction of integrated web-based Release management in Team Foundation Server 2015, we have made several enhancements in this version. Clone, export, and import release definitionsWe have incorporated the ability to clone, export, and import release definitions within Release hub, without requiring installation of an extension (Figure 45). (Figure 45) Clone and export commands on release summary pageFor more details, see documentation.
Test results displayed in the release summaryIn the release summary page, we have enabled a contribution point for an external service to show environment-specific information.In Team Services, this functionality is used to display a summary of test results when tests are run as part of a release environment (Figure 46). (Figure 46) Test results displayed in the release summaryFor more details, see documentation. Pass OAuth tokens to scriptsIf you need to run a custom PowerShell script that invokes the REST APIs on Team Services, perhaps to create a work item or query a build for information, you need to pass the OAuth token in the script.A new option when you configure an environment allows scripts to run as tasks in the environment to access the current OAuth token (Figure 47). (Figure 47) Pass OAuth tokens to scriptsFor more details, see documentation.This is a simple example showing how to get a build definition (Figure 48): (Figure 48) Example script using passed oAuth token Trigger on partially successful deploymentsBuild and release tasks have an option to Continue on error in the Control Options parameters for each task.In a build definition, this results in a Build partially succeeded result if a task with this option set should fail.The same behavior is now available in release definitions. If a task fails, the overall release result will show as 'Release partially succeeded' (Figure 49).
(Figure 49) Release summary shows partially successful releases in orange colorBy default, a partially successful release will not automatically trigger a release to a subsequent environment, even if this behavior is specified in the environment deployment options.However, a new option can be set in each release environment that instructs Release Management to trigger a release to a subsequent environment when the previous release is partially successful (Figure 50). (Figure 50) Setting the option to trigger from a partially successful releaseFor more details, see documentation.
Consume artifacts stored in GitHub directlySometimes you may want to consume artifacts stored in a version control system directly, without passing them through a build process, as described in.You can now do the same if your code is stored in a GitHub repository (Figure 51). (Figure 51) Linking code in a GutHub repository to a release definitionFor more details, see documentation. Web App Deployment using ARMA new version of the Azure Web App Deployment task is available, called.It uses MSDeploy and an Azure Resource Manager service endpoint connection. Use this task to deploy Azure Web Jobs and Azure API apps, in addition to ASP.NET 4, Node, and Python based web apps.The task also supports common publishing options such as the ability to retain app data, take an app off-line, and remove additional files at the destination.More features, such as configuration transformations, may appear in forthcoming versions (Figure 52).
(Figure 52) Web app deployment using ARM Task groupsA task group lets you encapsulate a sequence of tasks already defined in a build or a release definition into a single reusable task that can be added to a build or release definition just like any other task (Figure 53).You can choose to extract the parameters from the encapsulated tasks as configuration variables, and abstract the rest of the task information.The new task group is automatically added to the task catalogue, ready to add to other release and build definitions. (Figure 53) Linking code in a GutHub repository to a release definitionFor more details, see documentation. Soft delete of releasesWhen you delete a release, or it is automatically deleted by a retention policy, the release is removed from the overview and details lists.However, it is retained with the release definition for a period (typically 14 days) before it is permanently deleted.During this period, it is shown in the Deleted tab of the overview and details lists.You can restore any of these releases by opening the shortcut menu and choosing Undelete (Figure 54). (Figure 54) Undelete releasesFor more details, see documentation. Retain releases and builds for each environmentThe release retention policy for a release definition determines retention duration for a release and linked build.By default, a release is retained for 60 days. Releases that have not been deployed or modified during that time are automatically deleted.However, you may want to retain more releases that have been deployed to specific environments, such as your production environment, or retain them longer than those that were just deployed to other environments such as test, staging, and QA.You can also retain the build linked to a release for the same period as the release to ensure that the artifacts are available if you need to redeploy that release (Figure 55). (Figure 55) Retain releasesFor more details, see documentation.
Linked artifact improvementsTwo new features make it easier to work with artifacts and artifact sources:. You can link multiple artifact sources to a release definition (Figure 56). Each artifact is downloaded into a folder on the agent called the source alias. You can now edit the source alias of a linked artifact. For example, when you change the name of the build definition, you can edit the source alias to reflect the name of the build definition.(Figure 56) Linked artifact improvements For more details, see Artifact source alias(documentation. A number of variables of the format Build.
(such as Build.BuildId and Build.BuildNumber) are exposed for use in task parameters. When multiple sources are associated with a release, these variables now populate with values from the artifact source you specify as the primary source.For more details, see documentation.Deployment - Manual Intervention taskYou can now pause execution during deployment to an environment.Including a Manual Intervention task in an environment enables you to temporarily halt a deployment, perform manual steps, and then resume further automated steps.You can also reject the deployment and prevent further steps from executing after a manual intervention (Figure 57). (Figure 57) Manual intervention taskFor more details, see documentation. SQL Database deployment task scriptsThe Azure SQL Database Deployment (Figure 58) task has been enhanced to run SQL scripts against an Azure SQL Database. The scripts can be provided as a file, or inline within the task. (Figure 58) SQL database deployment task scripts Release definition summary - dashboard widgetPin a release definition to the dashboard - an easy way to make a summary of releases for that definition visible to all your team.For more details, see documentation. Promote releases to an environment at a specific timeWant all your production deployments to happen at midnight?
You can configure a condition on an environment that selects a successful deployment (or just the latest one) from another environment, and deploys it at the specified time (Figure 59). (Figure 59) Schedule release to an environment Deploy based on conditions in multiple environmentsUntil the previous version, you could do parallel deployments ( forkdeployments), but you could not start a deployment to an environment based on the status of multiple environments ( join deployments).
Now you can.For more details, see documentation. REST APIs for release managementYou can use the REST APIs for the Release Management service to create release definitions and releases, and manage many aspects of deploying a release.For more information, see the.You will find some basic examples that use the APIs in this blog post,. Service hooks integrationSend release notifications when new releases are created, deployments are started or completed, or when approvals are pending or completed. Integrate with third party tools such as Slack to receive such notifications. Deployment to national Azure cloudsUse the new Environment setting in an Azure Classic service endpoint to target a specific Azure cloud, including pre-defined national clouds such as Azure China cloud, Azure US Government cloud, and Azure German cloud (Figure 60). (Figure 60) Deployment to national Azure cloudsFor more details, see documentation.
Test ImprovementsKey test improvements have been added in Team Foundation Server 2017. Updated test result storage schemaIn this release, we are migrating the test result artifacts to a new compact and efficient storage schema. Since test results are one of the top consumers of storage space in TFS databases, we expect this feature to translate into reduced storage footprint for TFS databases. For customers who are upgrading from earlier versions of TFS, test results will be migrated to the new schema during TFS upgrade.
This upgrade may result in long upgrade times depending on how much test result data exists in your databases. It is advisable to configure the and wait for the policy to kick in and reduce the storage used by test results so that the TFS upgrade is faster. After installing TFS, but before upgrading the TFS instance, you can use the to clean up test results. See TFSConfig.exe help for more details.
If you do not have the flexibility to configure test retention or clean up test results before upgrade, make sure you plan accordingly for the upgrade window. See for more examples about configuring test retention policy. Test Hub improvements Test configuration management in Test HubWe have brought test configuration management to the web UI by adding a new Configurations tab within the Test Hub (Figure 61).
Now you can create and manage test configurations and test configuration variables from within the Test hub. (Figure 61) Configurations hubFor more information, see.
Assigning configurations to test plans, test suites, and test casesAssigning configurations just got easier. You can assign test configurations to a test plan, test suite, or test case(s) directly from within the Test hub (Figure 62). Right-click an item, select Assign configurations to, and you're off and running. You can also filter by Configurations in the Test hub (Figure 63). (Figure 62) Assign Configurations (Figure 63) Configurations FilterFor more information, see. View test plan/test suite columns in test results paneWe have added new columns to the Test results pane that show you the test plan and test suite under which the test results were executed in.
These columns provide much-needed context when drilling into results for your tests (Figure 64). (Figure 64) Test results pane Ordering of tests in Test Hub & on cardsYou can now order manual tests from within the Test Hub (Figure 65), irrespective of the type of suite in which they are included: static, requirement-based, or query-based suites. You can simply drag and drop one or more tests or use the context menu to reorder tests. Once the ordering is completed, you can sort your tests by the Order field and then run them in that order from the Web runner. You can also order the tests directly on a user story card on the Kanban board (Figure 66). This completes one of the long-pending (with 495 votes) under manual testing.
(Figure 65) Order tests (Figure 66) Order tests on card Order test suites in Test HubTest teams can now order the test suites as per their needs. Prior to this capability, the suites were only ordered alphabetically. Now, using the drag/drop capability in Test hub, suites can be re-ordered among the peer suites or moved to another suite in the hierarchy (Figure 67). This addresses the following item under manual testing/test case management. (Figure 67) Order Test suites Search for users as part of assigning testersAs part of the rollout of new identity picker controls across the different hubs, in Test hub, we have also enabled the option to search for users when assigning testers to one or more tests (Figure 68). This is extremely useful in scenarios where the number of team members is large, but the context menu only shows a limited set of entries.(Figure 69). (Figure 68) Search users (Figure 69) Assign Users Pick a build to test withYou can now pick the 'build' you want to test with and then launch the Web runner, using 'Run with options' in Test hub (Figure 70).
Any bug filed during the run is automatically associated with the build selected. In addition, the test outcome is published against that specific build. (Figure 70) Pick a build Launch Microsoft Test Runner client from Test Hub with data collectorsYou can now choose your data collectors & build to associate with the test run (Figure 71), and launch the Microsoft Test Runner 2017 (client) in a performant way from Test hub, without having to configure them in Microsoft Test Manager client. The Microsoft Test Runner launches without opening the entire Microsoft Test Manager shell and will shut-down on completion of the test execution.
(Figure 71) Run with optionsFor more information, see. Choose data collectors and launch Exploratory Runner client from Test hubYou can now choose your data collectors and launch the Exploratory Runner 2017 (client) in a performant way from Test hub, without having to configure them in Microsoft Test Manager client. Invoke 'Run with options' from the context menu (Figure 72) for a Requirement based suite and choose Exploratory runner and the data collectors you need. The Exploratory runner launches similar to Microsoft Test Runner as described above. (Figure 72) Run with Options - XT Configure test outcomes for tests across different test suitesWe have now added the ability to configure the behavior of test outcomes for tests shared across different test suites under the same test plan (Figure 73).
If this option is selected, and you set the outcome for a test (mark it as Pass/Fail/Blocked either from the Test hub, Web runner, Microsoft Test Runner, or from cards on Kanban board), that outcome will propagate to all the other tests present across different test suites under the same test plan, with the same configuration. Users can set the 'Configure test outcomes' option for a particular test plan either from the Test hub test plan context menu or from the Kanban board test page in the common settings configuration dialog.
This option is turned off by default and you will have to explicitly enable it to take effect. (Figure 73) Configure test outcomes Verify bugs from work itemYou can now verify a bug by re-running the tests which identified the bug (Figure 74). You can invoke the Verify option from the bug work item form context menu to launch the relevant test case in the web runner. Perform your validation using the web runner and update the bug work item directly within the web runner. (Figure 74) Verify bugs REST APIs for test plan / test suite cloneWe have added REST APIs for cloning of test plans and test suites. You can find them under the Test Management section on our.
Test progress from your Kanban cardsYou can now add, view, and interact with test cases directly from your stories on the Kanban board. Use the new Add Test menu option to create a linked Test case, and then monitor status directly from the card as things progress (Figure 75).