Sign in

Azure Pipelines— or how I learned to read documentation better

Some random pipelines from the Internet

Okay, first things first — in my, not so long, career I’ve used several CI/CD tools — Jenkins, Bamboo, GitLab CI and Azure DevOps. Most troubles I had with Bamboo, but that was maybe because I was just a beginner at the time and didn’t get the hang of its UI thing. The whole CI/CD concept of Bamboo was a bit complex to me at that time. Truth to be told, I didn’t check them lately, maybe they changed for the better. But I don’t want to critique them, at least not now, mainly because I forgot what I didn’t like then.

Second on that list of most troublesome to me was, and still is, yeah, you might’ve guessed it — Azure DevOps. The tool itself is quite good, don’t get me wrong, everything is in one place, DevOps in one, something similar to the thing GitLab had (more majestically) done. And that is okay to me. The main challenge I encounter when using Azure DevOps is their Pipelines.

For those who are not well versed in the Azure DevOps — you have two types of pipelines there: Classic (in the UI) and YAML pipelines (in the code). The classic one was preferred at some point (maybe a year ago, I cannot remember the exact time), but due to its downside of not keeping the pipeline in the code easily, they moved to Pipelines, or more specifically pipelines defined in YAML. There is an option to export the whole Classic pipeline in json, which you can keep in the source, but it is a bit troublesome, and not so readable, because, well — json. They called it Build Pipelines at first and now they are just Pipelines. I’m curious — is it just the thing with Microsoft or not, but it seems to me that they like to change the names of their tools quite often? Not sure, but their approach reminds me of me, if I’d be responsible for naming stuff.

Okay, now, what could I possibly not like about the Azure Pipelines — they are good. Yes, they are generally good — they do the job at the end, which is how I define good. But there are some minor perks which make your life more miserable at times and even make you doubt in your skills. Maybe I’m just bad, I don’t know. The thing I’m certain is that I’ll find more of those perks which I don’t like, or don’t understand to begin with, in future as well.

There are many challenges I’ve encountered in the last months playing with Pipelines (and yes, I’m aware that this sounded a bit wrong), but the most recent ones are:

  • They have a concept of a deployment job, which is by definition good — you separate normal (build) jobs from deployment jobs, that is okay. But, why, just why would they not include checkout of the source code in those jobs as well as in “normal” ones? [reference-document] You can do the checkout of the source code in those jobs, but you need to explicitly write it. It is not done by default. Okay, maybe I understand the reasoning behind this — deployment is not meant to do any tinkering with the source code. But what happens when you need to configure the application for some specific environment before building it and later deploying? And if you don’t specify the code to checkout, how is your pipeline processed in the agent if you only have deployment jobs in your YAML pipeline? When I was troubleshooting the issue of failing pipelines I couldn’t find the source code in the working directory which was quite confusing.
  • Another thing I am a bit troubled with — they have good IDE on the Azure DevOps, you can edit the code, easily commit changes, etc, but — why the YAML validator wouldn’t validate YAML pipelines correctly? Again, maybe I’m doing something wrong, but I’ve configured templates (the feature I like) within the pipeline, and I’ve set both variables and steps to be read from templates. I had wrongly configured pipeline. I had two jobs with declared variable templates, one job was successful, the other one was not. Main reason — variables were not properly listed in the YAML for the second job. Here is just a snippet of what I had:
jobs:
— job: jobA
description: This is a job A
variables:
— vars/template1.yaml
steps:
— templates/steps1.yaml
— templates/steps2.yaml
— job: jobB
description: This is a job B
variables:
vars/template2.yaml
steps:
— templates/steps3.yaml
— templates/steps4.yaml

Job A would succeed, job B fails because it doesn’t know about the variables. After some thorough analysis through a big YAML file, I’ve found that I missed putting ‘-’ before declaring variables for the second job. It was an aha! (or better described as facepalm) moment to me — don’t get your hopes into YAML validator, sometimes it will lie to you.

There were for sure some other perks, but as I mentioned before, I cannot remember them at this point. These two are the most fresh to me. If I encounter some more, I’ll gladly share in some other post.

At the end, I can summarize my “not-so-ranting rant” about Azure DevOps in these things:

  • When trying/configuring something in Azure DevOps — always read the documentation before thinking something acts as it normally should, or read it always, in the first place.
  • Don’t trust technology (or at least YAML validator on Azure DevOps).
  • And as a personal note to me — learn YAML for crying out loud!

Thanks for keeping up with me until the end!

Best described as a rock climber who works in IT and a software engineer who climbs rocks. I also enjoy learning and I’m currently training my own curiosity.