CI/CD with Azure DevOps and templates

Did you know there are benefits to having repetitive tasks as a template in your pipeline?

It’s a given in these advanced times that workflow automation is a key component for the success of a business.

What is workflow automation?

Workflow automation is the process of identifying tasks performed by employees and automating them with tools, apps, and technology.
Workflow automation not only saves time and boosts efficiency but enhances operations by enabling effective collaboration. It’s a series of automated actions that improve everyday processes and bring collaboration to a whole new level especially when you use new technologies like infrastructure as a code.

What happens when CI/CD meets workflow automation?

Continuous integration (CI) and continuous delivery (CD) embody a culture, a set of operating principles and collection of practices that enable application development teams to deliver code changes more frequently and reliably. The implementation is also known as the CI/CD pipeline.

CI/CD is one of the best practices for DevOps teams to implement. It is also an agile methodology best practice, as it enables software development teams to focus on meeting business requirements, code quality, and security because deployment steps are automated. CI/CD practices enable development teams to do small code changes and deploy the changes more frequently.

Which part of the software can be automated?

When it comes to CI/CD and workflow automation any part of the software components can be automated: components, modules, dependencies, and any related steps from testing to generating reports.

What if you have more than one service that has the same pattern?

To answer this question, we need to look at the devops tool chains in the DevOps industry. From Jenkins to GCP cloud build and maybe Azure DevOps, all these tools and services provide different ways of creating pipelines and referencing other resources while executing the flow.

For example, Jenkins supports Jenkinsfile and Azure DevOps and GCP Cloud build support yaml file configuration that gives your ability to load configuration from source control.

In the simple pattern, you have to use a yaml configuration file and repeat this yaml file into multiple services that are have the same steps for build and deployment.

What will happen if you have 40 services and suddenly get to know that you have to fix 1 step within the pipeline?

This might become a veritable nightmare, especially if you have services with complex and long running pipelines. The resolution will require you to first start fixing the pipeline in one service and after you make sure it’s done and stable, then you need to spend some time (most of the time, quite a lot of time!) to repeat the same step for all other services. And since it’s a manual intervention where you have to copy paste or rewrite the process, there might be typo issues or other errors you might see during this process. In short, this means the consumption of a lot of time and energy.

So what best practice can you follow?

In this kind of scenario, where you have a service which follows the same patterns with very minor differences between, the best practice would be to create a reference template instead of a pipeline for a specific service itself.

For example, in Azure DevOps, you can create a template (Azure DevOps Yaml Template) and just reference your steps to an input from the user.

If we get back to those 40 services, this means that instead of editing 40 services, you just have to create a template once and use a reference to the template.

If, for any reason, you want to edit something in your pipeline, you will not have to spend much of your time working on 40 pipelines, but instead you have to only work on one reference template and when you are done, all 40 services will be updated all together.

Conclusion

When you are going to make a workflow and CI/CD automation for processes that are repeatable among more than one service, it is not only important to understand the whole process, but also to find out how creating release and deployment automation will save you and your team a lot of time and energy.

If you’d like to know more, please feel free to connect with me