Understanding Jenkins CI/CD Pipeline (original) (raw)

Last Updated : 25 Aug, 2025

Jenkins is an open-source automation server that enables developers to reliably build, test, and deploy applications. It supports continuous integration and continuous delivery (CI/CD) workflows that allow teams to frequently deliver high-quality software. Jenkins provides an automation engine with an extensive plugin ecosystem that offers integrations for practically any DevOps toolchain. Its capabilities include:

manual_approval_optional

First, an automated build compiles the code and runs tests immediately. If the tests fail, the changes are rejected. This catches errors early. Next is continuous integration. Developers frequently merge their code changes into the main branch. With each merge, builds and tests are run to ensure nothing breaks.

Then comes continuous delivery. The changes are deployed to testing/staging servers. This is like a dress rehearsal before the actual release. Finally, in continuous deployment, the changes are deployed directly to production with little manual intervention. This enables quick delivery of features to users.

Key components and concepts

Understanding Jenkins Pipelines

Jenkins Pipelines bring all these stages together, creating an automated workflow that delivers software quickly, securely, and reliably.

Demonstrate pipeline examples for web apps, mobile apps, and API testing

Jenkins pipelines automate continuously releasing high-quality app updates by coordinating infrastructure. They enable engineer teams to deliver frequently.

delivering_mobile_apps_from_developer_devices_to_users

  1. First, deploying web apps to Kubernetes. When developers push code, Jenkins starts the pipeline. It builds a Docker container image with the code and sends it to a registry. Jenkins then updates Kubernetes config files with the new image details and tells Kubernetes to deploy the web app using this image.
  2. Now delivering mobile apps from developer devices to users. The pipeline starts after code is added to the main codebase. It compiles Android and iOS app versions. Then it runs UI and performance tests on these builds in emulators. If tests pass, Jenkins submits the build for publishing in the Play Store or App Store and tells the mobile team.
  3. Finally, API testing. Jenkins kicks off this pipeline when developers merge code. It runs unit tests on individual modules. Integration tests check modules work together correctly. Load tests hit the API server to measure performance. Jenkins shows reports on test results, code coverage, and issues. Based on results, it promotes the API to higher environments or warns developers of broken builds.

Creating Jenkins Jobs

First, you'll want to log into your Jenkins dashboard. This is like entering a workshop full of tools to help build your software. Once inside, click "New Item" to start a new project. Give your job a nice name - maybe after your favorite movie character or snack food.

**Than picking your job type. There are a few options here that do different things:

There are a few more types too, but these cover most use cases. Next, configure your job's settings. Here you can pick and choose what you want it to do - things like:

The options are endless. Set up your job just as you need it. Finally, save your job and click "Build Now" to test it out. Watch your job execute each step and voila - you've successfully automated the build process!

Now whenever new code lands, your job will wake up and do its work automatically. No more manual building or testing. With Jenkins, you can set up an assembly line for your software projects!

Jenkins Pipeline

Stages in Jenkins pipelines

pipeline {
agent any
stages {
stage('Checkout') {
steps {
git 'https://github.com/org/repo'
}
}
stage('Build') {
steps {
// compile code
// save build artifacts to S3 bucket
}
}
stage('Test') {
steps {
// download artifacts from S3
// load test data into Postgres DB
// run integration tests
// continue only if all tests pass
}
}
stage('Deploy') {
steps {
// download artifacts from S3
// deploy to Kubernetes cluster
}
}
}
}

Here is a more detailed explanation of each of the 4 stages in the pipeline:

Declarative Pipeline Vs Scripted Pipeline

When I first started using Jenkins for continuous integration and delivery, the concept of pipelines seemed confusing and complex. There were two primary approaches for defining and creating pipelines in Jenkins - declarative pipelines and scripted pipelines. Both approaches could accomplish the core goal of automating software workflows, but in markedly different ways.

declarative_pipeline

Declarative pipelines take a more structured, easy-to-visualize approach. The Jenkinsfile format allows you to lay out pipeline stages, such as build, test, and deploy, in a linear, sequential order. Each stage has a clean block defining what steps should occur within that stage. To me, this maps very cleanly to the progression of taking code from version control, through build, validation, and release processes. I can look at the Jenkinsfile like a flowchart and understand the logical order of events.

Scripted pipelines offer much more flexibility and customization capability, at the cost of increased complexity. Steps are defined procedurally using Groovy code encapsulated within methods like build(), test(), etc. The logic flow is harder for me to follow, as I have to trace through the method calls to see the overall sequence. The highly customizable nature of scripted pipelines enables much more sophisticated orchestration, but requires more Groovy programming expertise.

Declarative pipelines are best for simple, linear CI/CD workflows, while scripted pipelines offer greater flexibility and customization for complex scenarios.

Declarative Pipeline Code Syntax

pipeline {
agent any
stages {
stage('Build') {
steps {
// build steps
}
}
stage('Test') {
steps {
// test steps
}
}
stage('Deploy') {
steps {
// deploy steps
}
}
}
}

Scripted Pipeline Code Syntax

node {

stage('Build') {
// build steps
}

stage('Test') {
// test steps
}

stage('Deploy') {
// deploy steps
}
}

Key best practices of Jenkins

I have been writing about DevOps tools like Jenkins for a while. I have seen how using Jenkins pipelines can really help software teams work better. Jenkins lets you automate a lot of manual work. But many teams just starting with Jenkins struggle. They don't always use best practices. Then their pipelines become messy, break often, and have security holes. Teams end up wasting time babysitting jobs or fixing issues.

Based on my research and talks with engineers, I want to share tips on how to use Jenkins right. I'll talk about ways to structure code for reliability and security. I'll discuss how to define infrastructure as code so it's reproducible. I'll cover good plugins to use, scaling your setup, and baking security in from the start. I'll use real examples from companies like Square, Twilio, and Adobe. These teams use Jenkins well to improve their development.

Jenkins is powerful but you need to be careful. Governance is important - you need a balance between giving developers freedom while maintaining control centrally. I'll examine how mature teams strike this balance. The goal is to help teams use Jenkins to enhance their workflows, not hinder them. With the right practices, Jenkins can help deliver software faster and more reliably.