Jenkins pipelines are the heart of automating your continuous integration (CI) and continuous delivery (CD) workflows. In Jenkins, pipelines are defined in a file called Jenkinsfile. A Jenkinsfile can either be written in Declarative syntax or Scripted syntax, depending on the use case and flexibility requirements. This post will guide you through the differences between these two styles and show you the basic syntax for each.
1. What Is a Jenkins Pipeline?
A Jenkins Pipeline is a suite of plugins that supports implementing and integrating continuous delivery pipelines into Jenkins. A pipeline defines the stages of a build process, from the initial source code checkout to the final deployment or packaging of the application.
Pipelines offer the following key benefits:
- Version control: Jenkins pipelines are typically defined in a
Jenkinsfile, which is stored in the project’s source control repository. This allows the pipeline configuration to be versioned and reviewed along with the application code. - Automation: Pipelines automate repetitive tasks such as compiling, testing, and deploying code, making them a critical tool in CI/CD workflows.
- Flexibility: You can write pipelines using either Declarative or Scripted syntax, depending on your use case.
2. Declarative vs Scripted Pipelines
Jenkins offers two types of pipelines:
- Declarative Pipelines: This is a newer, simpler, and more structured way of writing pipelines. It provides a well-defined structure and makes pipeline creation easier for most users.
- Scripted Pipelines: This is the original pipeline style based on Groovy scripting. It is more flexible and offers greater control, but it can also be more complex to work with.
The key difference is that Declarative pipelines have a predefined structure and a clear, readable syntax, while Scripted pipelines give you more power to customize and manipulate the flow of the build process with Groovy code.
3. Basic Syntax of a Declarative Pipeline
3.1 Stages and Steps
In a Declarative pipeline, the build process is defined using stages and steps. A stage is a logical segment of the pipeline, such as "Build" or "Test". Inside each stage, you define the steps that should be executed.
3.2 Pipeline Block
A Declarative pipeline starts with the pipeline {} block. Inside this block, you define the structure of the pipeline, including the agent, stages, and post-build actions.
Here is a simple example of a Declarative Jenkinsfile:
pipeline {
agent any
stages {
stage('Build') {
steps {
echo 'Building...'
// Add your build steps here
}
}
stage('Test') {
steps {
echo 'Testing...'
// Add your test steps here
}
}
stage('Deploy') {
steps {
echo 'Deploying...'
// Add your deploy steps here
}
}
}
post {
always {
echo 'This always runs, regardless of the build result'
}
success {
echo 'This runs only if the build succeeds'
}
failure {
echo 'This runs only if the build fails'
}
}
}
3.3 Agent
The agent block specifies where the pipeline or stage will execute. Some options include:
agent any: Runs the pipeline on any available Jenkins agent.agent none: Used when agents are defined at the stage level.
Example of defining agents at the stage level:
pipeline {
agent none
stages {
stage('Build') {
agent {
label 'linux'
}
steps {
echo 'Running on a Linux agent'
}
}
}
}
3.4 Post Actions
The post block defines actions that run at the end of the pipeline or stage. You can specify actions that run when the build is successful, fails, or runs regardless of the result.
post {
always {
echo 'This always runs'
}
success {
echo 'This runs on success'
}
failure {
echo 'This runs on failure'
}
}
4. Basic Syntax of a Scripted Pipeline
Scripted pipelines are based on Groovy and allow for greater flexibility by using custom Groovy code. The structure is more freeform compared to Declarative pipelines.
4.1 Node Block
Scripted pipelines require you to define a node {} block, which indicates where the code should run (on which Jenkins node/agent).
Here is a simple example of a Scripted pipeline:
node {
stage('Build') {
echo 'Building...'
// Add your build steps here
}
stage('Test') {
echo 'Testing...'
// Add your test steps here
}
stage('Deploy') {
echo 'Deploying...'
// Add your deploy steps here
}
}
4.2 Stage and Step Blocks
In Scripted pipelines, stages and steps are not predefined blocks like in Declarative pipelines. Instead, they are custom blocks of code.
node {
stage('Build') {
echo 'Building...'
}
stage('Test') {
echo 'Testing...'
}
stage('Deploy') {
echo 'Deploying...'
}
}
You can also use complex Groovy code structures for better control. For example:
node {
try {
stage('Build') {
// Code for building
}
stage('Test') {
// Code for testing
}
stage('Deploy') {
// Code for deployment
}
} catch (Exception e) {
// Handle errors here
echo 'Build failed: ' + e.toString()
} finally {
// Cleanup actions
}
}
5. When to Use Declarative vs Scripted
Choosing between Declarative and Scripted pipelines depends on the complexity and requirements of your project.
- Use Declarative pipelines when you want:
- A clear and predefined structure.
- Simpler and more readable pipeline code.
- Easier maintenance and management.
- Use Scripted pipelines when you need:
- More flexibility and control over the pipeline's flow.
- The ability to write custom Groovy code.
- Complex logic or dynamic decision-making in the pipeline.
Conclusion
In this post, we explored the basic syntax of both Declarative and Scripted Jenkins pipelines. Declarative pipelines offer a more structured and easy-to-understand approach to defining your CI/CD processes, while Scripted pipelines provide greater flexibility for more complex requirements. Depending on your project's needs, you can choose the best approach for defining your Jenkins pipelines and automating your development workflow.
Stay tuned for more detailed posts as we continue to dive deeper into Jenkins pipelines and advanced topics!