Pipeline as code

During the past few years there has been a rise of interest in infrastructure-as-a-code. In my opinion, the rise of cloud computing was one of the biggest motivations and enablers behind infrastructure-as-a-code. Cloud computing was also an enabler for microservices. A typical microservice architecture requires many deployment pipelines which are for the most part identical. And this is a new challenge for many teams to deal with. Other emerging challenges are around version controlling and backing up build and deployment pipelines. From my experience and observation, cloning a build or deployment pipeline through CI/CD tool (if supported at all), and backing up the build machine are the most common answers to address above challenges. While these techniques may help to address some of the concerns, but they are not perfect and scalable. You might be able to clone pipelines as many times as you want manually through your CI/CD tools, but can you apply a change across all the pipelines in one go? If you need to manually change each pipeline to accommodate new changes, then you are in trouble. If you have no history or version control around pipeline changes then you better to pay your DevOps engineer well and make sure he is not leaving your company! Do you backup your build machine after any change into the pipeline? Do you health check your backups? What do you do if you don’t have access to a build machine? These should be enough to prove you need a better and easier way to maintain your pipeline specially when it comes to microservices, enterprise application and scalability. The answer is simple – Pipeline as Code; Similar to Infrastructure-as-a-Code concept. Pipelines as code is defining the build and deployment pipelines through code instead of configuring a running CI/CD tool. So now, if someone forks or clone your repo, they can get your pipeline definition as well as your code. Jenkins, Azure DevOps,  LambdaCD, GoCD and Drone are some of the major players when it comes to pipeline as code. Microsoft introduced build pipeline as code for Azure DevOps in Nov 2017; However, release pipeline still in progress and not fully supported at this stage. If you are not doing pipeline as code, I believe you need to start doing it from today and version control all the changes.

If you want to know A – Z about Jenkins pipeline, I recommend you to watch this training.

CI/CD/CT at Enterprise Scale – Enable Test Impact Analysis

As part of your CI/CD/CT pipeline you want to integrate, deploy and tests your application couple of times a day. When it comes to enterprise level application, we usually have a huge set of tests which makes it very hard and time consuming (if not impossible) to run every time as part of our continuous testing.

Test Impact Analysis (TIA) is a technique to determine the impacted tests for a given set of changes. Therefore,  you don’t need to run all of the tests every time you want to build and deploy a new version.

TIA is just a click away in VSTS – you can easily enable TIA as part of your CI/CD/CT pipeline to dramatically reduce the time needed to run the tests.

You just need to enable “Run only impacted tests” in your version 2.* and above build’s test step.