What’s brewing in Visual Studio Team Services: April 2018 Digest
This post series provides the latest updates and news for Visual Studio Team Services and is a great way for Azure users to keep up-to-date with new features being released every three weeks. Visual Studio Team Services offers the best DevOps tooling to create an efficient continuous integration and release pipeline to Azure. With the rapidly expanding list of features in Team Services, teams can start to leverage it more efficiently for all areas of their Azure workflow, for apps written in any language and deployed to any OS.
Chain related builds together using build completion triggers
Large products have several components that are dependent on each other. These components are often independently built. When an upstream component (a library, for example) changes, the downstream dependencies have to be rebuilt and revalidated. Teams typically manage these dependencies manually.
Now you can trigger a build upon the successful completion of another build. Artifacts produced by an upstream build can be downloaded and used in the later build, and you can also get data from these variables: Build.TriggeredBy.BuildId, Build.TriggeredBy.BuildDefinitionId, Build.TriggeredBy.BuildDefinitionName. See the build triggers documentation for more information.
This feature was prioritized based on what is currently the second-highest voted suggestion with 1,129 votes.
Keep in mind that in some cases, a single multi-phase build could meet your needs. However, a build completion trigger is useful if your requirements include different configuration settings, options, or a different team to own the dependent process.
Trigger CI builds from YAML
You can now define your continuous integration (CI) trigger settings as part of your YAML build definition file. By default, when you push a new .vsts-ci.yml file to your Git repository, CI will be configured automatically for all branches.
To limit the branches that you want triggered, simply add the following to your file to trigger builds on pushes to master or any branch matching the releases/* pattern.
YAMLCopy
trigger:
- master
- releases/*
If you want to disable the trigger or override the trigger settings in the YAML files you can do so on the definition.
See the YAML build triggers documentation for more information.
Streamline deployment to Kubernetes using Helm
Helm is a tool that streamlines installing and managing Kubernetes applications. It has also gained a lot of popularity and community support in the last year. A Helm task in Release is now available for packaging and deploying Helm charts to Azure Container Service (AKS) or any other Kubernetes cluster.
VSTS already has support for Kubernetes and Docker containers. With the addition of this Helm task, now you can set up a Helm based CI/CD pipeline for delivering containers into a Kubernetes cluster. See the Deploy using Kubernetes to Azure Container Service documentation for more information.
Continuously deploy to Azure Database for MySQL
You can now continuously deploy to Azure Database for MySQL – Azure’s MySQL database as a service. Manage your MySQL script files in version control and continuously deploy as part of a release pipeline using a native task rather than PowerShell scripts.
Configure Go and Ruby applications using Azure DevOps Projects
Azure DevOps Projects makes it easy to get started on Azure. It helps you launch an application on the Azure service of your choice in just a few steps. DevOps Projects sets up everything you need for developing, deploying, and monitoring your app. Now you can setup an entire DevOps pipeline for Go and Ruby applications too. See the Deploy to Azure documentation for more information.
Deploy Ruby on Rails applications
A new Azure App Service release definition template now includes the tasks needed for deploying Ruby on Rails applications to Azure WebApp on Linux. When this release definition template is used, the App Service Deploy task gets pre-populated with an inline deployment script that makes bundler (dependency manager) install the applications dependencies.
Build applications written in Go
Now you can build your Go applications in VSTS. Use the Go Tool Installer task to install one or more versions of Go Tool on the fly. This task acquires a specific version of Go Tool needed by your project and adds it to the PATH of the build agent. If the targeted Go Tool version is already installed on the agent, this task will skip the process of downloading and installing it again. The Go task helps you download dependencies, build, or test your application. You can also use this task to run a custom Go command of your choice.
Deployment Groups are generally available
We are excited to announce that Deployment Groups is out of preview and is now generally available. Deployment Groups is a robust out-of-the-box multi-machine deployment feature of Release Management in VSTS/TFS.
With Deployment Groups, you can orchestrate deployments across multiple servers and perform rolling updates, while ensuring high availability of your application throughout. You can also deploy to servers on-premises or virtual machines on Azure or any cloud, plus have end-to-end traceability of deployed artifact versions down to the server level.
Agent-based deployment relies on the same agents your builds and releases use, which means you can use the full task catalog on your target machines. From an extensibility perspective, you can also use the REST APIs for deployment groups and targets for programmatic access.
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. From an extensibility perspective, you can also use the REST APIs for deployment groups and targets for programmatic access.
Read more in the announcement of GA.
Improve code quality with the latest extensions from SonarSource
SonarSource recently released an updated SonarQube extension and a new SonarCloud extension, which enable static code analysis for numerous languages. The VSTS Gradle and Maven tasks take advantage of these extensions for Java builds in particular. Just enable Run SonarQube or SonarCloud Analysis on version 2.* of the Gradle or Maven task, then add the Prepare and Publish SonarQube/SonarCloud tasks as shown below. See the Analyzing with SonarQube documentation for more information.
Publish markdown files from a Git repository as a Wiki
Developers create documentation for “APIs”, “SDKs”, and “help docs explaining code” in code repositories. Readers then need to sift through code to find the right documentation. Now you can simply publish markdown files from code repositories and host them in Wiki.
From within Wiki, start by clicking Publish code as wiki. Next, you can specify a folder in a Git repository that should be promoted.
Once you click on Publish, all the markdown files under the selected folder will be published as a wiki. This will also map the head of the branch to the wiki so that any changes you make to the Git repo will be reflected immediately.
You can learn more in the announcement. Also, the wiki REST APIs are now public. See the Wiki functions and Wiki search documentation for more information.
Integrate Power BI with VSTS Analytics using views
We are excited to announce an easy-to-use solution for integrating Power BI with the VSTS Analytics extension. You don’t have to know how to write OData queries anymore! Our new feature Analytics views makes getting VSTS work tracking data into Power BI simple, and it works for the largest accounts. Similar to a work items query, an Analytics View specifies filters that scope the result of work items data and the columns. Additionally, views allow you to report on past revisions of work items and easily create trend reports.
We provide a set of Default Analytics views that work well for customers with smaller accounts and basic scenarios. Larger accounts might need to scope down the data they are pulling into Power BI. Analytics views let you do just that. Scope your data and history to exactly what you want to report on in Power BI. Analytics views you create in the Analytics hub in VSTS are immediately available to select from the VSTS Power BI Data Connector. Now you can edit your default views and create new views to fine-tune the records, fields, and history returned to Power BI.
Wrapping Up
As always, you can find the full list of features in our release notes. Be sure to subscribe to the DevOps blog to keep up with the latest plans and developments for VSTS.
Happy coding!
Source: Azure Blog Feed