How are you doing it?
Do you have one big pipeline script with all sorts of logic that incorporate everything?
Or do you have a lean pipeline where a single stage does one and only one thing well?
I’ve seen many different ways in which companies organize their CI/CD pipelines. And it works for them. But there are a few designs that were really simple to understand and were highly flexible. Whenever I see a complex deployment pipeline that is hard to understand or have many components – I ask the same question – why didn’t they do it the other way – the simple way.
I feel that a new person should not take more than 15 minutes to understand your integration and deployment strategy after reading the Jenkins pipeline code. And if you have such a pipeline, then be proud of that.
Table of Contents
Things to consider
There are 3 main things that I would consider if I have to create the pipeline from scratch.
- Lean and Simple
- Easy to Debug
- Flexible
Lean And Simple
Typically in a project, we do the following,
- we write code
- we commit
- every commit should trigger a build on that branch
- and every build should be quick
- after successful build run integration tests
- deploy to stage (if required)
- deploy to prod (if required)
If we have to translate these into stages of a pipeline then it would look like this,
And the command that you write in every stage should be the same as what you will run in your local.
Sample commands for a typical java application for each stage would look something like this:
| Stage | Command |
|---|---|
| Checkout | git checkout <commit> (probably use a gitscm plugin) |
| Build | ./gradlew clean build -x test |
| Unit Tests | ./gradlew tests |
| Integration Tests | ./gradlew integrationTests -x build |
| Prepare Docker Image | ./gradlew prepareImage |
| Staging Deploy | ./gradlew deployStaging |
| Production Deploy | ./gradlew deployProduction |
One-liner.
This is the best. You wouldn’t want to increase any line of code there. No conditional nothing.
Your pipeline is to perform one task after another in the most reliable and efficient way. If you are writing logic into your stage then you are unnecessary increasing the complexity. Your pipeline is not built for handling logic it is built for managing different stages for your CI/CD workflows. So just use it for that.
You can optimize different stages to run in parallel as well which will save you a ton of time.
The fastest build-to-deploy time that I have seen for an enterprise application is close to 5 minutes. This is super awesome, given the fact that you built the artefact, published it, ran integration tests and then deployed the application. 5 minutes is super impressive. But a 10-minute pipeline wouldn’t be that bad depending on your architecture and code size.
The main time-consuming tasks are integration tests and deployments. Can’t do much about deployments but integration tests can be made super fast. Strive for that.
How much time does your pipeline take from build to deployment?
Easy To Debug
If you look at the pipeline then there are not many moving parts. So for any reason, if your pipeline doesn’t work, it is very simple to debug. Within 5 minutes you can pinpoint the problem.
First of all, a simple pipeline like the one I defined above wouldn’t face any problem in the first place. Even if it does, its super easy to debug.
So strive for that.
How quickly can you pinpoint problems in your pipeline?
Flexible
Flexibility comes when something changes in your system or practices. For example, your deployment strategy changed across the company for any reason. Then how quickly can you make those changes to be aligned with those changes?
Flexibility is very important. Usually, we don’t care for it while building something. And when something changes in the future, then the person responsible for it at that time will have to fix your doing. So, why not be sympathetic from the start and make everyone’s life easier.
How flexible is your pipeline to incorporate the change?
Let me know your views in the comments below.