I’ve been using Jenkins for many years now and since Jenkins Pipelines came out i’ve been using Jenkins Pipelines ever since. I am a massive fan of Jenkins Pipelines.
However, i am even a bigger fan for Jenkins Declarative Syntax Pipelines since it came out a few years back.
In the first iteration of Jenkins Pipelines you had to write your pipelines using code. The coding language of choice was Groovy. It is still is by the way. You don’t use pure Groovy but what is known as Groovy DSL. This first iteration of Jenkins Pipelines is what it is now known as the Scripted Pipelines. I am not going to go in-depth about the scripted syntax version of Jenkins Pipelines in this article as that warrants a dedicated article in itself.
Using this scripted syntax was fine. However, for a CI/CD Engineer who doesn’t have much knowledge of the Groovy language itself, there was a steep learning curve involved for one engineer to get up to speed with Jenkins Pipelines.
Groovy is a type of JVM language such that it runs on the Java Virtual Machine. Since it runs on JVM, it is very similar to Java in terms of syntax. In fact, its existence was to provide an alternative Java like programming language that is easy to the eye and easy for Java Developers (or other Developers) to pick up the language easily and to provide a better coding experience than Java since Java can be a bit verbose at times. Groovy certainly does have a lot of ‘syntactic sugar’ meaning it is not just pleasant on the eye but pleasant for a developer to code in.
So you can imagine, for someone who is not from a Java like background it can be hard for that person to pick up the language.
Enter Declarative Syntax
Jenkins have now release what is called Declarative Syntax to write Jenkins Pipelines.
As the name suggests, declarative syntax provides a ‘declarative’ way to define your pipelines. It is based on a Groovy like syntax called the Groovy DSL. (Domain Specification Language).
The purpose of this introduction is exactly to enable developers/engineers who are coming from a non Java like background to pick up the Jenkins Pipelines easily.
How i model my CI/CD Pipeline
The way i like to structure my pipeline is to first visualize it as a continuous flow of actions from one side to another (usually left to right or start to finish). Pretty much like a production line.
For example, my Java maven based project i have a Jenkins Pipeline to build and release my Java application.
In my pipeline i would perform the following steps:
- Checkout my code
- Compile code
- Runs Unit tests
- Runs Integration tests (if any)
- Runs Systems/Acceptance/End 2 End tests (if any)
- Static Code Analysis (usually using a tool like SonarQube).
- Package my Java artifact (.jar)
- Publish it onto a centralized artifact repository (like SonaType Nexus or JFrog’s Artifactory)
And if i were bundling my application inside a Docker container image for deploying it for running in production as a container then i would additionally do the following steps in my pipeline:
- Build a Docker Container Image (baking in my Java
.jarartifact along with the OS and Runtime (Java/JVM) required for running it)
- Publish the built Docker Container Image to a centralized Docker Container Registry (like Docker Hub or AWS ECR for example)
My Example Jenkins Declarative Pipeline
In Jenkins, to model a pipeline, you would code your pipeline code in a file named
This file would typically be checked into your version source control system along with your project code.
This is an example of practicing Pipeline as Code.
As you can see, each of my pipeline step action in my model is represented in each Jenkins Pipeline Stage. This allows me easily visualize what is going on in my Jenkins Pipeline.
Jenkins Stage View
The Jenkins Stage View is shown below graphically.
As you can see from above screenshot, in Jenkins you can easily visualize the ‘stages’ of your pipelines and to see status of each step (if it failed, where it failed, how long a particular step took etc).
As a user of this pipeline it is perfect as it enables the developer to see where in the pipeline their feature got to.
It has to be said, Scripted Syntax pipelines offer the same above in terms of Jenkins Stage View visualization. However, what i wanted to emphasize was how easy it is that you can see the Declarative Syntax maps directly to the Jenkins Stage View.
Avoiding Complex Logic
One of the side effects of using the declarative approach is that the Declarative Syntax way sort of forces you towards a certain structure. The structure of your pipelines in declarative format all pretty much follow the same format. They are quite rigid. Of course, using advanced declarative syntax features such as Matrix building you can construct really advanced and complicated logic in your pipelines.
One of the things with Scripted Syntax is that it encourages you to write not just a lot of code but also code that does a lot of conditional or perhaps even complex logic in your pipelines.
I am a firm believer of simple/minimal logic (or not logic at all) in your pipelines so that not just you can easily debug your pipelines but also that it produces good clean code. After all, adopting Jenkins Pipelines you are practising Pipeline As Code.
Therefore, you should also follow best software development coding practices when building your pipelines.
So, i would advocate for keeping complex logic out of your pipeline code. This is to ensure your pipelines are robust and error-free as possible. After all, your pipelines are designed for building your software application code.
If you really require logic then i would recommend abstracting out the logic into custom shell scripts.
Hopefully i have shown how easy it is to develop a very simple SDLC pipeline for an application in Jenkins using Jenkins Declarative Syntax.