Microsoft’s recent renaming of Visual Studio Team Services as Azure DevOps came as a surprise, rebranding a familiar service and adding significant new features. One of those new features, Azure Pipelines, builds on Microsoft’s previous cloud-hosted build service to deliver a more powerful tool for building and delivering on-premises and cloud-hosted applications for Windows, MacOS, and Linux.
Azure Pipelines is a continuous delivery tool, competing with tools like the open source Jenkins. It’s designed to build code in popular languages, test them, and then deliver them to your choice of endpoint. Like other CI/CD systems, it’s also extensible, with a library of tasks and extensions to add support for test tool and for integration with your devops tool chain.
Azure Pipelines follows a devops workflow
Pipelines can be configured using YAML or through a visual designer. It’s clear that Microsoft expects you to use the YAML option, which makes sense, because your pipeline configuration becomes another file that lives alongside your code, where it can be managed by your choice of source-control system. You’re also going to need a source-control environment to use Azure Pipelines, because that way it can automate the test and build process. Triggering builds from commits can speed up the development cycle significantly.
Building a pipeline in YAML is easy enough, using an azure-pipelines.yml file. Start by connecting your repository to Azure Pipelines, using OAuth to give it access to your code. It then scans your code and builds a basic template that’s ready for use. That template is saved in the master branch for your code. Once you commit code to the branch, Azure Pipelines’s default trigger then runs your build.
