Self-Service CI/CD Pipelines

I recently had to spend time educating new teammates on the evolution of CI/CD. I figured I would spend sometime here sharing what that looked like.

CI/CD Platforms (Crawl)

The first thing I had to teach them was that a CI/CD platform is NOT a CI/CD pipeline. However this is generally where companies start when they think about “how” to implement CI/CD inside of the organization. What do I mean when I say CI/CD platform:

Jenkins – Yes this is our favorite well know CI/CD platform. Even if you have never had the chance to use it you still know it’s “lovely” interface and if you are lucky you have had the chance to read the massive shell scripts people have pasted inside of the “script” text boxes.

ConcourseCI – What an amazing platform, I mean who does not want to write 1000s of line of yaml “code” to get CI/CD to actually work. Not to mention the “amazing” array of community supported “resources”. Who would have ever thought that building a stateless CI/CD platform was a good idea? Well here you go with ConcourseCI. Just wait until you try and use terraform inside of the beast.

CircleCI – This is the goto platform when you want to avoid “Jenkins” because you have lived the horror story. Let’s be real Jenkins is still the best CI/CD platform out there BUT only for the few ninjas who know how to actually use it for most companies it’s a horrendous disaster. Wait till you try CircleCI and the docs tell you this pattern is a best practice:

curl https://sometool.com/totallytrustworthyscript.sh | bash

GoCD – From the team at Thoughworks GoCD is actually an amazing platform and a great alternative to Jenkins. It has the same ability to create reusable pipelines which help companies standardize on CI/CD standards and best practices.

But at the end of the day these are just platforms. They more or less execute a script on a primary or secondary node preferably inside of a docker container based upon some event. The logic for how the pipelines work inside of these platforms must still be written and defined.

CI/CD Templates & Standards (Walk)

What I see most companies do as the next step is they publish “documents” which outline the standards and best practices for CI/CD. For instance they instruct teams on how to implement unit testing in their pipelines or define the company standard for static code analysis (which we all know is CheckMarx). Once I meet with a VP of a large ticket selling company, a VP who spoke at re:Invent multiple times about how they would be out of the “datacenter business in 3 years”. Part of our discussion was how the company failed so bad at public cloud because they just gave the dev teams “example terraform code”. This is a great start but we all know the goal of DevOps at the end of the day is to “automate all the things”.

Documentation and standards are a great thing, but until we codify them organizations will struggle to streamline them across the organization.

CI/CD Self-Service Pipelines (Run)

Tools like Jenkins offer the ability for teams and organizations to create “shared libraries” these shared libraries are pre-defined pipelines which abstract all of the complexity from the developers and give them a pre-defined pipeline model they simply have to define the meta data for.

For instance if the team or organization decides only trunk can go to production and not feature branches this can be defined in the “shared library” or if all pipelines need static code analysis the shared library can be updated to include this feature and all pipelines using that library get that functionality for “free”. Below is an example of how to implement this using Jenkins declarative pipeline shared libraries. Now all a team has to do is drop in a Jenkinsfile with the below metadata inside.

@Library("PipelineLambda@1.5.0") _ 
PipelineLambda(appName: 'ApplicationName', filename: 'FileOrArtifactName',
        functionalTestImage: 'ImageThatHasToolsToRunFunctionalTest',
        funtionalTestCommand: 'CommandToExecuteFunctionalTest', 
        smokeTestImage : 'ImageThatHasToolsToRunSmokeTest',
        smokeTestCommand: 'CommandToExecuteSmokeTest', rollback : true)

Conclusion

Anyway hopefully this helps you better understand what the evolution of CI/CD is for most businesses. Hopefully you are well into having picked your CI/CD platform of choice, have defined a set of standards for CI/CD across the organization and are starting to codify those standards into a set of pre-defined pipelines so teams can focus on business logic not how to deploy an API Gateway for their lambda functions inside of terraform.