Team Services | TFS 2017 | TFS 2015 | Previous versions (XAML builds)
New things you can do with Team Build and Release Management.
We release new features first on Visual Studio Team Services, rolling them out across the accounts throughout a period of about a week. We make most of these changes available eventually on-premises in a release or update to Team Foundation Server (TFS).
Build tool installers
To use this capability you must enable the Task tool installers preview feature for your account.
Have you been wishing you could install a tool or runtime on the fly (even on a hosted agent) just in time for your CI build? Do you need to validate your app or library against multiple versions of a dependency such as Node.js? Today we're announcing tool installers that enable you to install one or more versions of tools sets on the fly.
For example, you could set up your build process to run and validate your app for multiple versions of Node.js. First specify a comma-delimited list of versions in a variable that you can modify at queue time.
Next enable multi-configuration. If you've got enough agents and concurrent pipelines, you can even run the builds in parallel.
And last, add the Node.js tool installer task.
Save and queue the build, to see your app validated with multiple versions of Node.js.
At the moment we've got the Node Tool Installer task. We don't yet have runtime environments like Java, or tools like NuGet or cURL.
Want to try it? See Tool installers.
SSH deployment improvements
The Copy Files Over SSH build/release task now supports tildes(~) in the destination path to simplify copying files to a remote user's home directory. Also, a new option allows causing the build/release to fail when no files are found to copy.
The SSH build/release task now supports running scripts with Windows line endings on remote Linux or macOS machines.
Deploy to Azure Government Cloud
Customers with Azure subscriptions in Government clouds can now configure Azure Resource Manager service endpoint to target national clouds.
With this, you can now use Release Management to deploy any application to Azure resources hosted in government clouds, using the same deployment tasks.
Timeout enhancements for the Manual Intervention task
The Manual Intervention task can now be automatically rejected or resumed after it is pending for the specified timeout or 60 days, whichever is earlier. The timeout value can be specified in the control options section of the task.
Release Logs Page Improvements
In this deployment, we have improved the release logs page experience:
- You can directly click the URLs in the log viewer.
- You can search for keywords in the logs.
- You can view large log files without downloading them.
Azure App Service task enhancements and templates for Python and PHP applications
New Azure App Service release definition templates have been added for deploying Python (Bottle, Django, Flask) and PHP applications. The new template contains the updated App Service Deploy task.
When the Python release definition template is used, the App Service Deploy task gets prepopulated with an inline deployment script which makes pip (dependency manager) install the applications dependencies. The correct web.config gets generated based on the Python framework used.
When the PHP release definition template is used, the App Service Deploy task gets pre-populated with a deployment script which makes Composer (dependency manager) install the application's dependencies.
Deploy Java to Azure Web Apps
The Azure App Service Deploy build/release task now supports deployment of Java WAR files to an Azure Web App. When creating a new build definition, you can choose to begin with a new build template: Java Deploy to Azure Web App. This simplifies getting started by building your project with Ant, Gradle, or Maven, and deploying the results to Azure. An Azure Web App slot can be specified to allow uploading to a staging slot before swapping that deployment with a production slot.
By popular request, we've published these new build topics:
CI/CD for newbies What is continuous integration (CI)? What is continuous deployment (CD)? Why should I care? How do I get started?
Build artifacts Examples and tips on publishing and using build artifacts.
New Release Management topic:
- Azure Government Cloud Team Services is not available in Azure Government Clouds, so there are some special considerations when you want to deploy apps to Government Clouds.
Updated build content
Updated release content
New build editor
Our thanks to those of you who tried the early previews of our new build editor and gave us feedback. We're getting ready to retire the old build editor. So if you haven't yet gotten familiar with the new build editor, we encourage you to do so now. Learn more.
Conditional build tasks
Have you been looking for more control over your build tasks? For example, do you want to clean things up, send a message, or do some other kind of housekeeping when something goes wrong? We're now offering four built-in choices to control when a task is run:
This feature is available only in the new build editor.
But what if you need fine-grained control over when a task runs? For example, you want to run a task only when the build was triggered by a CI build. And it needs to run even if the build is failing. But only on feature branches.
Now we're giving you this kind of control. On your task, select custom conditions, and then enter:
and(failed(), in(variables['Build.Reason'], 'IndividualCI', 'BatchedCI'), startsWith(variables['Build.SourceBranch'], 'refs/heads/features/'))
In support of conditional tasks, we're offering a new build variable:
Build.Reason. You can use this variable to check for CI, scheduled, and other triggers. See variables.
New build editor will soon be the default
Earlier this year we announced a preview of the new build editor. Thank you to all who have been trying it and giving us feedback! If you haven't done so already, please try the new editor and let us know what you think. Soon we'll be switching your account to make it the default editor.
Override template parameters in Azure resource group deployments
Currently in Azure resource group deployment tasks, users select the template.json and the parameters.json and provide the override parameter values in a text box, following a specific syntax. This experience is now enhanced so the template parameters are rendered in a grid which allows them to be edited and overridden. Users can access this feature by clicking the ... next to the override parameters field, which opens a dialog with the template parameters along with their default values and allowed values (if defined in the template and parameter .json files). This feature requires that CORS rules are enabled at the source. If template and parameter json files are in Azure storage blob, refer to this documentation to enable CORS.
Continuous Delivery in the Azure portal supports any Git repo
You can now configure a continuous delivery (CD) workflow for the Azure App Service no matter which Git repository you use to manage your code. Until now, you could select an App Service in the Azure Portal and setup continuous delivery for that service in just a few clicks, but only if you managed your code either in a Visual Studio Team Services Git repository or in GitHub. You can now get the same simple experience for any public or private Git repository, provided that repository is accessible from the Internet. With a few clicks in the Azure portal, you can set up a build and release definition in Team Services that will periodically check your Git repository for any changes, sync those changes, run an automated build and test, followed by a deployment to Azure App Service. As your needs evolve, you can customize these definitions to support multiple environments, more complex testing, or deployment upon manual approval.
Separation of duties for deployment requester and approvers
Previously, environment owners could restrict release creators from approving deployments of the release to an environment. Users could, however, manually start deployment of a release created by another user, and approve it themselves.
We have now filled this gap by considering the deployment creator as a separate user role for deployments. Either the release creator or deployment creator can be restricted from approving the deployments.
Set maximum number of parallel deployments
This feature gives you control on how multiple pending releases are deployed into a given environment. For example, if your release pipeline performs validation of builds in a QA environment and the rate of generation of builds is faster than the rate of completion of the deployments, you may configure multiple agents and as many builds to get validated in parallel. That means each of the builds generated gets validated, and the wait time is dependent in the number of available agents.
With this feature, we let you optimize validations by enabling you to perform validation on the n most recent builds in parallel and cancel the older deployment requests.
Unified Build & Release docs
You might have noticed that the build and release docs have been coming closer together over the past couple of months. Today it's official. Just as Build & Release is joined in Team Services, and they're now also joined in our docs.
New topic on TFS authentication
Configure TFS authentication to enable your agents to use different authentication methods.
Other notable content updates
Visual Studio 2017 and Hosted Linux Preview hosted agents
Hosted agents You can now use our hosted agents to build your Visual Studio 2017 apps. We've also added information about the Hosted Linux Preview queue.
Build and deploy your ASP.NET Core app to Azure includes the ability to use hosted agents to build ASP.NET Core apps.
Keep track of your free hosted agent minutes
You can now see how many free hosted agent minutes you've used.
See when agents in your pool are upgrading
When an agent is being upgraded, it now indicates the status of the upgrade in the queue and on the agent pools tab.
Agent content (new and updated)
We've made several updates aimed at clarifying how to configure your private agents.
Guidance on file matching patterns
Other updated content
Node.js Moved deployment step out of CI build and into Release Management. Gave web deployment artifact a useful file name.
Pipelines in Team Services Added clarification to Q&A about control of pipeline allocation.
GitHub pull request builds
For a while we've provided CI builds from your GitHub repo. Now we're adding a new trigger so you can automatically build your GitHub pull requests. After the build is done, we report back with a comment in your GitHub pull request.
For security, we build only pull requests when both the source and target are within the same repo. We don't build pull requests from a forked repo.
To enable this capability, on the build editor Trigger tab, select Pull request.
Selection of private agents on machines not in use
The system now uses machine name as a factor when allocating a build or a release to a private agent. As a result, the system will prefer an agent on an idle machine over an agent on a busy machine when it allocates the job.
Run tests using Agent Phases
Using the Visual Studio Test task, you can now run automated tests using agent phases.
We now have a unified automation agent across build, release and test. This brings in the following benefits:
You can leverage an agent pool for your testing needs.
Run tests in different modes using the same Visual Studio Test task, based on your needs—single agent–based run, multi-agent–based distributed test run or a multi-configuration run to run tests on, say, different browsers.
For more information, see this post.
Private agent automatic workspace cleanup
You can now configure an agent pool to periodically clean up stale working directories and repositories. For example, the pool will delete workspaces left behind by deleted build and release definitions.
Using this option should reduce the potential for your private build and release agents to run out of disk space. The maintenance is done per agent (not per machine), so if you have multiple agents on a single machine you could still run into disk space issues.
Multiple versions of extension tasks
Extension authors can now create extensions with multiple versions of a given task which enables them to ship patches for each major version they have in production.
Changes to concurrent pipelines
Concurrent pipelines in Team Services We've begun charging for concurrent pipelines.
Concurrent pipelines in TFS Manual intervention does not consume a pipeline in TFS 2017 Update 1 and newer.
The Pipelines queue feature provides users with more visibility into where their builds or releases are.
On launching the Pipelines queue, you can see the following information:
Builds and releases waiting for a pipeline to execute and their position in the waiting queue.
Builds and releases currently running using available pipelines.
While your build/release is waiting for a pipeline, you can also directly launch this view from inside the build/release logs page and find its current position in the pipeline queue and other details.
Machine groups deprecated
We've deprecated Machine Groups. Instead of creating a machine group, use a comma-delimited list of machine names or a variable in the following tasks:
- Run Functional Tests task
- Visual Studio Test Agent Deployment task
- PowerShell on Target Machines task
For more details, see Set up environments to run continuous test tasks with your build tasks.
Merging and updating build & release content
As build & release are more integrated as a product, we've begun to also integrate the content. We've created, updated, and reorganized a lot of topics. Look for the content to continue merging in the coming weeks.
Updated get started CI/CD to Azure
Updated ASP.NET build (CI)
Updated ASP.NET deploy (CD)
Updated agent content
New concepts section with new and updated topics
Build and release agents and related topics
Build options and related topics
Release definitions and related topics
Build editor preview
Last year we introduced a more personalized user experience to help you easily monitor and manage the builds you own and care about.
This month we're offering a preview of a new design aimed at making it easier for your to create and edit build definitions. Click the switch to give it a try.
If you change your mind, you can toggle it off. However, eventually after we feel it's ready for prime time, the preview editor will replace the current editor. So please give it a try and give us feedback.
The new editor has all the capabilities of the old editor along with several new capabilities and enhancements to existing features.
Search for a template
Search for the template you want and then apply it, or start with an empty process.
Quickly find and add a task right where you want it
Search for the task you want to use, and then after you've found it, you can add it after the currently selected task on the left side, or drag and drop it where you want it to go.
You can also drag and drop a task to move it, or drag and drop while holding the Ctrl key to copy the task.
Use process parameters to pass key arguments to your tasks
You can now use process parameters to make it easier for users of your build definition or template to specify the most important bits of data without having to go deep into your tasks.
If you create a new build from some of the built-in templates (for example Visual Studio and Maven) you can see examples of how these work.
The new editor includes a few other enhancements, such as giving you quicker access to your sources settings. For more details, see Preview of our new build editor.
Release action in the build summary
We've added a Release action to the build summary to make it easy for you to create a release for your build.
Role-based security for variable groups
You now manage security for variable groups using roles.
You can modify roles for a specific variable group, or for all of them at once.
Web app deployment history in Azure portal
Release Management now updates the deployment logs of Azure App Service when a deployment is done by using the App Service deployment task. Users can view deployment history in the Azure portal by clicking on the Continuous delivery option in the App Service blade.
Hosted pool internal changes
We recently changed our hosted agents to sync sources on the D drive instead of the C drive. This might cause issues if you've defined a build that depends on hard coded paths to the sources directory.
We recommend that you avoid using hard coded paths to resources on the hosted agent. Instead, you should always use variables to construct any references that you need to make to resources used by your build.