Azure Pipelines—a gentle introduction

Fig 4. Azure Pipelines—supported repositories

Building a pipeline in Azure Pipelines

Azure Pipelines gives us two ways to build and deploy.

• We can use a visual editor. Individual tasks are dragged to the pipeline and then configured. This is a standard method that is available for all types of projects.
• For Azure Git, GitHub, and Bitbucket projects, we can use a pipe definition in a YAML file. We can edit it in Azure DevOps, or we can use any text editor. Then we commit this file to a repository such as a Git repository.

In much the same way as any physical production pipeline, a CI/CD pipeline such as Azure Pipelines has stages. Typically, these are:

1. Build (compiling the code)
2. Test (usually automated checking of the code for typos and bad syntax)
3. Release (not to the public, but to a repository)
4. Deploy (the code goes to production environments)
5. Validate (checking that all of the graphics and text are correct and meet company or client standards)

It’s really only after the validation stage that the CI/CD magic happens.

So, first we need to select which environment we are building in and targeting our deployment. That’s how the pipeline will know how to test the build as you go. The deployment targets are those listed above.

Next, we define the triggers. What action will cause the Azure Pipelines to run a test? When, and how often should it run? The following are the available choices:

• CI-triggers will run the pipeline as soon as the code on the connected branch is updated.
• PR-triggers will run the pipeline when a pull request is created on an attached branch or when new changes are posted.
• Scheduled triggers.
• Pipeline triggers will run when another pipeline finishes.
• Comment triggers, available only for GitHub, will run when a specific comment is entered in a pull request.

Then comes the simple step of specifying which version of the software Azure Pipelines will be used via the version control system.

The task list

Now that the specifications are made, we can choose the tasks. There’s plenty to choose from, and yet, if there’s a tool elsewhere that you find useful, you can install it too. There’s even an option of whether to use Azure DevOps to build and deploy or the older but still useful Jenkins.

If your project is intended for multiple targets (platforms), you’ll want to use cross-platform scripts. Even though each script may do certain things differently (such as handling variables), Azure Pipelines has an option to write your way around these obstacles, with a syntax that is essentially unwrapped uniquely, specific to each platform.

The available tasks are categorized as follows:

• Build
• Utility—these are a variety of tasks, from archiving to decrypting to copying or deleting, and more.
• Test
• Package—these tasks involve authenticating, opening build environments, and publishing.
• Deploy—define your deployment targets with these tasks.
• Tool—mostly installers, and some tasks for choosing the proper version of coding language.

As you can see, some of these tool categories match the pipeline stages listed above.

When you use Azure Pipelines, you are given various options in terms of controlling the tasks you set. You may decide to set the condition that a task should only run if previous agent runs (sets of tasks) have succeeded, or only if a previous run failed, or it should simply run regardless of the result of previous runs.

You may also decide to let the task run again if the previous run failed and define how many times it tries again.

Finally, there is the option of defining or adding in custom tasks from outside the Azure Pipelines provided list and Marketplace.

Another feature of the pipeline is branching, for adding new features. When compiled, the pipeline will test the code for that feature against the rest of the code to identify any compliance problems.

Will it work?

Speaking of testing, there are some interesting options to consider; the pipeline can run tests that you’ve added to the repository, and it can run user interface tests. It can run tests on multiple agents simultaneously—up to 99 at a time. Each separate branch is known as a job.

Furthermore, Azure Pipelines lets you choose either agents which are hosted—and maintained—by Microsoft or agents installed on your own system. (These of course will require your own time and effort to maintain, but it does make for a faster testing process.)

The test results are saved in the build summary as a simple report. A team member can then analyze any errors that may have turned up.

Once the code passes all of the tests, the pipeline builds what’s called an artifact. This artifact is what will be pushed out for implementation in the app as an update. We could choose to make Azure Pipelines handle implementation automatically, make it wait for approval, or make implementation manual.

No need to reinvent the wheel

As you’ll have noticed, Azure DevOps services is full of provided tools, some from within Microsoft and some from without. Once you’ve created anything with your pipeline, whether a task, a job, or indeed the entire pipeline, you can save your work as a template for others to use in the future. Your colleagues and your future self will thank you!

Wrapping up

It would be somewhat trite to describe the process of building an Azure pipeline as easy, but Microsoft has put a great amount of effort into making CI/CD accessible for more developers while also reducing the risk of errors and project delays. By enabling the five typical stages, and more, and by providing their own tools while leaving the door open to outside tools, they’ve given Azure DevOps as a whole a really strong use case.

We wish you luck with your next pipeline project!