adaptive.run TECH BLOG

I’m sure that you too have seen some repetition over time when working on Azure DevOps Pipelines. This may be caused regardless if you change some value when copying the same stage or task multiple times. How can you avoid this?

If you find yourself on the developers’ side, you might have already heard of DRY (Don’t Repeat Yourself), considering that is known as a common principle. But if you are more an infrastructure engineer to all DevOps things, let’s go through this concept together and understand it better. 

What does DRY (Don’t Repeat Yourself) mean?

According to the Wikipedia definition, the DRY principle means that “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system”.

https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

I will mention below a list of what DRY represents to me/a list of what makes me think of DRY:

- Avoid duplication when possible, but not always;

- Do not copy and paste in pipelines;

- Parametrize;

- Use variables;

- Achieving a stage or doing a task with fewer lines;

- Increasing the logic of the pipeline;

- Saving some things for other pipelines;

- Structuring everything that is possible.

Let me tell you more about DRY’s method benefits :

- Use of fewer lines of code;

- Saving time, both for reading or writing;

- Eliminating the copy-paste process, facility in maintenance on the long run, great parameters and very good variables;

- Eliminating the repeating process by not copy-pasting, which will also reduce the appearance of bugs or other issues in your pipelines;

- When trying to keep the code unique, see what you have created before, try to keep a pattern and reuse what you have created before for your pipelines. 

I encourage you to create a set of pipeline templates for reusing and refactor purposes for the future pipelines that you will create. Personally, I use this method quite often, so a major part of my work is being done from a set of templates that I have created before and which I use and refactor in order to personalize the current pipeline to the requirements and environments that I work on at that moment.

Also, try to plan ahead the specifics of your pipeline before you start writing it. Think about what you would like your pipeline to do and set the context accordingly. When planning, start noting the stages and tasks of the pipeline, decide where you can parametrize, note the variable usage and remove any potential duplication. 

Use of DRY for every pipeline

While I recommend using the DRY method as often as possible, there may be situations where this could not be possible due to multiple reasons, such as the need to rewrite an existing pipeline or, sometimes, the lower cost of testing and creating something from scratch. Even so, try to work on any additional pipeline or to rewrite by taking into account the DRY method and for sure you will notice the beneficial difference this can make.

What questions should you have in mind when reconfiguring a pipeline

Here is a list of questions you should ask yourself when you want to apply DRY to an existing pipeline:

- How often has this configuration been repeated?

- Would it be possible to write fewer lines for this configuration?

- In case of duplications, would it be possible to rewrite and avoid new duplications? 

- Could I facilitate the future maintenance process by refactoring the pipeline?

- Are there copy/paste sections that could be changed and removed?

Conclusions:

- Less code means easier code maintenance;

- Avoid duplication where possible to facilitate the updating process, by updating in just one place, instead of several;

- Write code that is reusable;

- Create a set of templates or principals to use for every pipeline;

- Acknowledge that sometimes you may need to repeat the code.