Why Jenkins is Used

Manual deployments don't fail occasionally — they fail predictably, at the worst possible times, by the most tired possible person. This lesson is about why that pattern exists and exactly how Jenkins breaks it.

Let's paint the picture that most engineering teams know intimately. It's 5:45 PM on a Thursday. The sprint ends tomorrow. Three features need to go to production tonight. The senior dev who "knows how the deploy works" is on a call. Someone else tries to do it from memory. They forget to set an environment variable. The app boots, connects to the wrong database, and starts silently writing bad data. Nobody notices until 2 AM.

That story is not a horror story. That story is a Tuesday at thousands of software companies. And it is almost entirely preventable.

The Checklist That Lives in One Person's Head

Here's the core problem with manual processes: the procedure only exists in someone's head — or at best, a Confluence page that's six months out of date. Every manual deploy is an act of trust that the right person remembers all the steps, in the right order, on a day when they might be distracted, rushed, or just plain tired.

Think about the pre-flight checklist used by airline pilots. A 747 captain with 20,000 hours of flight time still reads through the checklist before every single takeoff. Not because they're forgetful — because checklists remove human error from high-stakes repetitive processes. Jenkins is that checklist for your software delivery, except it runs itself.

Before Jenkins vs. After Jenkins

The difference isn't subtle. Here's what the same deploy workflow looks like on both sides of the line:

The Five Real Reasons Teams Choose Jenkins

When engineering leaders at larger organisations make the decision to run Jenkins, it usually comes down to one or more of these five reasons:

1. Speed of delivery. A team doing manual deploys might ship once a week because deployments are painful and risky. With Jenkins automating the pipeline, that same team can safely ship multiple times a day. The automation is the safety net that makes frequent releases possible.

2. Consistency. Humans make different decisions under pressure. Jenkins doesn't. The pipeline runs the same steps whether it's triggered at 9 AM on a Monday by the CTO or at 11 PM on a Friday by a junior developer. Same tests. Same checks. Same deploy procedure.

3. Fast feedback loops. Without CI, a developer might write broken code on Monday and not find out until code review on Wednesday. With Jenkins running tests automatically on every push, they find out in four minutes. The earlier you catch a bug, the cheaper it is to fix.

4. Audit trail. Jenkins keeps a record of every build: who triggered it, what commit it ran against, how long it took, whether it passed or failed. When a compliance team asks "what was deployed to production on March 14th and who approved it?" — Jenkins has the answer.

5. Flexibility and control. Unlike hosted CI/CD services, Jenkins runs on your infrastructure. You control where the builds happen, what tools are installed, what data leaves your network. For regulated industries — finance, healthcare, defence — this isn't optional. It's a requirement.

What a Jenkins-Powered Workflow Actually Looks Like

Here's the typical automated workflow Jenkins enables for a backend service. Every step happens without a human touching anything after the initial code push:

That entire flow — from push to Slack notification — typically takes two to five minutes for a medium-sized service. Compare that to a manual deploy that blocks a senior engineer for thirty minutes and carries a real risk of human error.

Now let's see what the beginning of that pipeline looks like in a real Jenkinsfile — the file that defines the automated workflow as code.

The scenario:

You're a DevOps engineer at a 40-person e-commerce company. The checkout service currently gets deployed manually — one specific developer does it every time, and when they're on holiday, releases pile up for a week. You've been asked to automate it. This is the Jenkinsfile you'd start with: a simple pipeline that checks out the code and runs the test suite automatically on every push to the main branch.

// Declarative pipeline — the recommended modern syntax for Jenkins
pipeline {

    // 'any' means Jenkins can run this on whatever agent is available
    // In production you'd pin this to a specific label like agent { label 'linux' }
    agent any

    // Triggers: run this pipeline automatically whenever code is pushed to main
    triggers {
        pollSCM('H/5 * * * *') // check the repo every 5 minutes for new commits
    }

    // Define pipeline-wide environment variables
    environment {
        APP_NAME = 'checkout-service'           // used in log messages and artifact names
        DEPLOY_ENV = 'staging'                  // target environment for this pipeline
        SLACK_CHANNEL = '#deployments'          // where build notifications will be sent
    }

    stages {

        // Stage 1: pull the latest code from the repository
        stage('Checkout') {
            steps {
                // checkout scm pulls the branch that triggered this build
                checkout scm
                echo "Checked out ${APP_NAME} — building for ${DEPLOY_ENV}"
            }
        }

        // Stage 2: run the full test suite — no manual skipping allowed
        stage('Test') {
            steps {
                // ./gradlew test runs unit tests via the Gradle build tool
                sh './gradlew test'
            }
        }

    }

    // Post block: actions that run after all stages complete
    post {
        // 'failure' runs only if one of the stages above failed
        failure {
            echo "Pipeline failed — ${APP_NAME} build did not pass tests"
        }
        // 'success' runs only if every stage passed
        success {
            echo "All tests passed for ${APP_NAME} — ready to build artifact"
        }
    }
}

Started by SCM change
[Pipeline] Start of Pipeline
[Pipeline] node
Running on agent-linux-01 in /var/jenkins_home/workspace/checkout-service
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Checkout)
[Pipeline] checkout
Cloning repository https://github.com/acmecorp/checkout-service.git
 > git fetch origin main
 > git checkout main
[Pipeline] echo
Checked out checkout-service — building for staging
[Pipeline] }
[Pipeline] stage
[Pipeline] { (Test)
[Pipeline] sh
+ ./gradlew test
Starting a Gradle Daemon...
> Task :test
BUILD SUCCESSFUL in 38s
23 tests completed, 0 failed
[Pipeline] }
[Pipeline] End of Pipeline
[post] success
All tests passed for checkout-service — ready to build artifact
Finished: SUCCESS

The scenario:

It's two weeks later. The automated pipeline is running, but your manager wants to know: how often is the pipeline actually passing? Are we catching failures early or are broken builds sitting unnoticed? You need to pull a quick build history report from the Jenkins CLI to answer that question.

# Pull the last 10 build results for the checkout-service job
# This gives you an instant health snapshot without opening the browser
java -jar jenkins-cli.jar \
  -s http://jenkins-master-01:8080 \
  -auth admin:your-api-token \
  list-builds checkout-service \
  --format json | python3 -m json.tool

[
  { "number": 42, "result": "SUCCESS", "duration": 38420, "timestamp": 1710758400000 },
  { "number": 41, "result": "SUCCESS", "duration": 41100, "timestamp": 1710672000000 },
  { "number": 40, "result": "FAILURE", "duration": 12300, "timestamp": 1710585600000 },
  { "number": 39, "result": "SUCCESS", "duration": 39800, "timestamp": 1710499200000 },
  { "number": 38, "result": "SUCCESS", "duration": 37650, "timestamp": 1710412800000 }
]

Practice Questions

Quiz