Last week I started at a new customer and they’re fully committed to the Azure DevOps environment. They use their Git repositories, their project boards and also their pipelines. Since the project I’m working is currently their only PHP project, they did not yet have any experience with setting up pipelines for a PHP project. So I set out to do just that, and found it surprisingly easy.

Just like many other Git hosting sites, you can configure the pipelines using a YAML file, in this case azure-pipelines.yml, in the root of your project. They do also offer an online editor, but I haven’t actually tried that, preferring the YAML format for configuring pipelines.

If you have experience with Bitbucket pipelines or Gitlab pipelines, then configuring Azure pipelines will be a breeze. Most things make a lot of sense. There’s a few things that I did need to take into account while setting up, and in this article I want to share these things.

Tasks

The first thing I found out: The predefined tasks beat having to create your custom scripts any day. Azure Pipelines have a huge list of predefined tasks that can make your life with pipelines a lot easier. For instance, this project uses private composer packages that are located inside Git repositories. So I have to insert an SSH key into the runner to make sure that when running composer install it can fetch those packages. A pretty common situation. Before I knew about the tasks I tried to manually do this myself. But I have very little knowledge of the insides of the runner, so it’s pretty hard to figure out exactly how to do that. Luckily, there is a task for that. This will save you a lot of time.

Secure files

Speaking about SSH keys (or other things that need to be injected that need to be securely stored) the Secure files feature is the answer. It’s really easy to insert those secure files into your runner context, and tasks such as the earlier mentioned InstallSSHKey@0 task allows you to simply reference the secure file to use. Again, this will save you a lot of time and frustration.

Similar to secure files, there’s also variables that you can configure, that are stored securely and can then be used in the azure-pipelines.yml file.

Conditions

By default the whole pipeline is triggered on each push of each branch. You can limit when things are run by using the triggers. But there is another way of limited when things are run: by using conditions. Triggers are configured on the top level and so apply to your whole pipeline configuration. But sometimes you want certain stages, jobs or steps to run only in specific situations. For instance, you only want to build and push the image when all previous steps have succeeded and only for your main branch.

This is where conditions come in. Let’s take the above example of wanting to run a stage only when all previous stages have succeeded and only when the branch is main. You can add a relatively simple condition to do that:

condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))

By adding the above to a stage, job or step, that item will in this case only be run when previous items have succeeded (succeeded()), and when the branch this runs on (Build.SourceBranch) is main (refs/heads/main).

And you can start doing pretty fancy stuff with this. There’s a lot of logic you can add, based on variables, attributes of the current build, success or failure of previous steps, etc.

This is pretty cool

My experience with Microsoft stuff has always been a bit hit or miss, but so far I must say I’m actually quite impressed by the Azure Pipelines and the ease and speed with which it works. And not just that: Their git repository hosting in general works pretty well (except that pipelines work on branches and are not directly linked to pull requests, which is unfortunate). Their Jira replacement also seems to work pretty well. So yes, I quite like how this works.