Modern development teams frequently update their applications. They add features, fix bugs, improve performance, and release security patches. However, manually checking, testing, building, and deploying every change can take a lot of time.

Manual processes can also produce inconsistent results. For example, one developer may forget a test, use the wrong command, or upload an outdated build.

Jenkins helps solve these problems through automation.

With Jenkins CI/CD, a team can automatically download code, install dependencies, run tests, create builds, store artifacts, and deploy applications. Jenkins can perform this workflow whenever a developer pushes code to a Git repository.

This complete beginner’s guide explains what Jenkins is, how Jenkins CI/CD works, how to create a Jenkins Pipeline, and how to write your first Jenkinsfile.

---

What Is Jenkins?

Jenkins is a free and open-source automation server.

Development teams use Jenkins to automate repetitive tasks across the software development lifecycle. Although Jenkins can automate many processes, developers primarily use it for Continuous Integration and Continuous Delivery.

Jenkins can automate tasks such as:

• Downloading source code
• Installing dependencies
• Checking code quality
• Running automated tests
• Compiling source code
• Creating application builds
• Building Docker images
• Storing build artifacts
• Deploying applications
• Sending build notifications
• Running security scans
• Scheduling maintenance jobs

Jenkins supports projects built with Java, JavaScript, Python, PHP, C#, Go, Ruby, Kotlin, Dart, Flutter, and many other technologies.

Its large plugin ecosystem allows Jenkins to connect with GitHub, GitLab, Bitbucket, Docker, Kubernetes, AWS, Google Cloud, Microsoft Azure, Slack, email services, testing tools, and artifact repositories.

---

What Does CI/CD Mean?

CI/CD stands for:

• CI: Continuous Integration
• CD: Continuous Delivery or Continuous Deployment

These practices help teams deliver software through a fast, repeatable, and reliable process.

Continuous Integration

Continuous Integration is a development practice in which developers regularly add small code changes to a shared repository.

Whenever someone pushes code, Jenkins can:

1. Download the latest version
2. Install dependencies
3. Analyze the code
4. Run automated tests
5. Create a build
6. Report the result

If a test fails, Jenkins informs the team. As a result, developers can fix problems before those problems reach production.

Continuous Delivery

Continuous Delivery keeps the application ready for release.

After testing the code, Jenkins can create a deployment package and move it to a staging environment. However, a person normally approves the final production release.

This method combines automation with human control.

Continuous Deployment

Continuous Deployment automatically releases every successful change to production.

No manual approval is required once the code passes all configured checks. Therefore, this approach provides very fast releases.

However, Continuous Deployment needs:

• Reliable automated tests
• Secure deployment credentials
• Strong monitoring
• A rollback strategy
• Stable infrastructure

---

What Is Jenkins CI/CD?

Jenkins CI/CD is an automated process that uses Jenkins to integrate, test, build, and deliver software.

A typical Jenkins pipeline follows this sequence:

1. A developer changes the application code.
2. The developer pushes the code to a Git repository.
3. A webhook or scheduled check notifies Jenkins.
4. Jenkins starts a pipeline.
5. An available agent receives the job.
6. Jenkins downloads the source code.
7. The pipeline installs required dependencies.
8. Code analysis and automated tests run.
9. Jenkins creates a deployable build.
10. The pipeline stores the build as an artifact.
11. Jenkins deploys the application to staging.
12. An authorized person may approve production deployment.
13. Jenkins releases the approved version.
14. Monitoring tools check the application.

If an important step fails, Jenkins normally stops the remaining dependent stages.

---

Why Do Development Teams Use Jenkins?

Jenkins remains useful because it offers flexibility and extensive customization.

Open-Source Platform

Jenkins is open source. Organizations can install it on their own servers and control its configuration, data, plugins, agents, and security policies.

Large Plugin Ecosystem

Jenkins plugins connect the automation server with many development tools and external services.

Popular plugin categories include:

• Source control
• Build tools
• Testing
• Code quality
• Cloud platforms
• Containers
• Notifications
• Security
• Authentication
• Artifact management

Pipeline as Code

Jenkins allows developers to store the complete pipeline in a file named Jenkinsfile.

The team can commit this file to the same repository as the application. Therefore, developers can review, update, and track pipeline changes like normal source code.

The official Jenkins Pipeline documentation recommends storing a Jenkinsfile in source control because it creates an audit trail and a shared source of truth.

Platform Flexibility

Jenkins can run on supported environments across Linux, Windows, macOS, containers, and cloud infrastructure.

Distributed Builds

A Jenkins controller can distribute work across multiple agents. For example, Android builds may run on a Linux agent, while iOS builds run on a macOS agent.

Custom Workflows

Teams can create simple testing pipelines or complex delivery workflows involving parallel jobs, human approvals, multiple environments, and different deployment methods.

---

Important Jenkins Concepts

Understanding the main Jenkins components makes pipeline configuration much easier.

Jenkins Controller

The Jenkins controller is the central Jenkins service.

It manages:

• The Jenkins web interface
• User authentication
• Authorization
• Pipeline definitions
• Job scheduling
• Plugin configuration
• Agent coordination
• Credentials
• Build records
• System configuration

You can think of the controller as the brain of the Jenkins environment.

The controller decides which work needs to run and where Jenkins should run it. However, production teams should avoid running regular builds directly on the controller.

The official Jenkins node documentation discourages executing builds on the built-in controller node because it can create security, performance, and scalability problems.

Jenkins Agent

A Jenkins agent is a worker that executes pipeline tasks.

An agent may be:

• A physical computer
• A virtual machine
• A Docker container
• A Kubernetes pod
• A cloud instance
• A Windows server
• A Linux server
• A macOS machine

Each agent can contain different tools.

For example:

• A Flutter Android agent may contain Flutter, Java, Gradle, and the Android SDK.
• An iOS agent may contain macOS, Xcode, CocoaPods, and Flutter.
• A web agent may contain Node.js, npm, and browser-testing tools.

Node

In Jenkins, a node represents a machine that can run tasks. The built-in node belongs to the controller, while additional nodes normally act as agents.

In everyday Jenkins discussions, developers often use “node” and “agent” for nearly the same idea. However, they represent slightly different concepts internally.

Executor

An executor is a slot that allows an agent to run a task.

Suppose an agent has two executors. That agent may be able to run two tasks at the same time, depending on resource requirements.

Adding too many executors can reduce performance. Each task may compete for CPU, memory, storage, and network resources.

Job

A Jenkins job defines an automated task.

For example, a job can:

• Run unit tests
• Build an APK
• Publish a website
• Create a Docker image
• Deploy an API
• Scan dependencies

Jenkins supports different job types. However, modern CI/CD projects commonly use Pipeline or Multibranch Pipeline jobs.

Build

A build is one execution of a Jenkins job.

For example, Jenkins may display:

Build #101
Build #102
Build #103

Each build has its own status, logs, duration, parameters, and artifacts.

Pipeline

A Jenkins Pipeline defines the complete software delivery workflow.

A pipeline commonly contains stages such as:

• Checkout
• Install
• Analyze
• Test
• Build
• Deploy

Stage

A stage represents a major part of the pipeline.

Example stages include:

Build → Test → Package → Deploy

Stages help developers understand pipeline progress and quickly find failures.

Step

A step is an individual action inside a stage.

For example:

sh 'npm test'

This step tells Jenkins to execute npm test on a Unix-like agent.

Workspace

A workspace is the directory where Jenkins stores the checked-out source code and temporary files for a job.

Build commands normally run inside this directory.

Plugin

A plugin adds features or integrations to Jenkins.

For example, a plugin may provide Git integration, test reporting, credentials support, Docker features, or pipeline visualization.

Artifact

An artifact is a file produced during a build.

Examples include:

• Android APK or AAB
• iOS IPA
• ZIP archive
• Java JAR or WAR
• Test report
• Compiled website
• Log file
• Documentation package

Jenkins can archive these files so users can download or reuse them later.

---

How Does a Jenkins Pipeline Work?

A Jenkins pipeline connects several automated stages into one workflow.

Stage 1: Source Code Change

A developer creates a feature, fixes a bug, or updates a configuration file.

After testing the change locally, the developer commits it:

git add .
git commit -m "Fix login validation"
git push origin feature/login-fix

The code now exists in a remote Git repository.

Stage 2: Pipeline Trigger

Jenkins needs a trigger to start the pipeline.

Common triggers include:

• GitHub webhook
• GitLab webhook
• Bitbucket webhook
• Source-code polling
• Scheduled time
• Manual action
• Another Jenkins job
• Remote API request

A webhook normally provides faster and more efficient automation than frequent repository polling.

Stage 3: Job Scheduling

The Jenkins controller reads the pipeline requirements.

It then searches for a matching agent with an available executor. Labels can direct the job to an agent that has the required tools.

For example:

agent {
    label 'flutter-android'
}

This instruction asks Jenkins to use an agent labeled flutter-android.

Stage 4: Source Code Checkout

The agent creates a workspace and downloads the requested repository version.

Jenkins can work with branches, tags, pull requests, and merge requests.

Stage 5: Dependency Installation

Next, the pipeline installs project dependencies.

Examples include:

npm ci

flutter pub get

mvn clean

pip install -r requirements.txt

Stage 6: Code Quality Checks

The pipeline can check formatting, linting, static analysis, and other quality rules.

For a Flutter project:

dart format --output=none --set-exit-if-changed .
flutter analyze

For a JavaScript project:

npm run lint

Stage 7: Automated Testing

Jenkins runs the project’s automated tests.

The tests may include:

• Unit tests
• Widget tests
• Component tests
• Integration tests
• API tests
• End-to-end tests
• Security tests
• Performance tests

If a required test fails, Jenkins marks the build as failed or unstable based on the configuration.

Stage 8: Application Build

After successful tests, Jenkins creates a deployable build.

Examples include:

flutter build apk --release

npm run build

mvn package

docker build -t my-application .

Stage 9: Artifact Storage

Jenkins can archive the resulting files.

Teams may also upload artifacts to:

• Nexus Repository
• JFrog Artifactory
• Docker Hub
• GitHub Container Registry
• Amazon Elastic Container Registry
• Google Artifact Registry
• Azure Container Registry

Stage 10: Deployment

Finally, Jenkins may deploy the build to:

• A development server
• A testing environment
• A staging server
• A production server
• Kubernetes
• A cloud platform
• Firebase App Distribution
• Google Play Console
• Apple App Store Connect

The pipeline may require manual approval before production deployment.

---

What Is a Jenkinsfile?

A Jenkinsfile is a text file that defines a Jenkins Pipeline as code.

The file normally uses Groovy-based Jenkins Pipeline syntax and usually has this exact name:

Jenkinsfile

Developers place it in the project’s root directory:

my-project/
├── src/
├── tests/
├── package.json
├── README.md
└── Jenkinsfile

A Jenkinsfile may define:

• Agents
• Pipeline stages
• Shell commands
• Environment variables
• Credentials
• Conditions
• Timeouts
• Build parameters
• Parallel tasks
• Post-build actions
• Deployment approvals

Storing the pipeline in the repository offers several advantages:

• Developers can track changes.
• Reviewers can inspect pipeline updates.
• Branches can use different pipeline versions.
• The team gains a clear audit history.
• Developers can restore an earlier configuration.

---

Declarative vs Scripted Jenkins Pipeline

Jenkins supports two main Pipeline styles:

• Declarative Pipeline
• Scripted Pipeline

Declarative Pipeline

Declarative Pipeline uses a structured and beginner-friendly format.

Example:

pipeline {
    agent any

    stages {
        stage('Build') {
            steps {
                echo 'Building application'
            }
        }

        stage('Test') {
            steps {
                echo 'Running tests'
            }
        }

        stage('Deploy') {
            steps {
                echo 'Deploying application'
            }
        }
    }
}

Declarative Pipeline provides a clear structure. Therefore, beginners should normally start with this style.

Scripted Pipeline

Scripted Pipeline offers more flexibility through Groovy-based programming logic.

Example:

node {
    stage('Build') {
        echo 'Building application'
    }

    stage('Test') {
        echo 'Running tests'
    }

    stage('Deploy') {
        echo 'Deploying application'
    }
}

Scripted Pipeline can handle highly customized workflows. However, it may become harder to read and maintain.

Declarative vs Scripted Pipeline Comparison

Feature	Declarative Pipeline	Scripted Pipeline
Structure	Clearly defined	Flexible
Learning difficulty	Easier	More advanced
Syntax control	Stricter	Less restrictive
Readability	Usually higher	Depends on implementation
Best for beginners	Yes	Not usually
Complex Groovy logic	Limited but possible	Strong support
Main top-level block	pipeline	node

Both approaches remain valid. Nevertheless, Declarative Pipeline works well for most beginner and standard CI/CD projects.

---

Your First Jenkins Pipeline

Here is a simple Declarative Pipeline:

pipeline {
    agent any

    stages {
        stage('Checkout') {
            steps {
                echo 'Downloading source code'
                checkout scm
            }
        }

        stage('Build') {
            steps {
                echo 'Building the application'
            }
        }

        stage('Test') {
            steps {
                echo 'Running automated tests'
            }
        }

        stage('Deploy') {
            steps {
                echo 'Deploying the application'
            }
        }
    }
}

Let us understand every section.

pipeline

The pipeline block contains the complete Declarative Pipeline configuration.

pipeline {
}

agent

The agent section tells Jenkins where to execute the pipeline.

agent any

Here, Jenkins can use any suitable available agent.

stages

The stages block contains all major pipeline stages.

stages {
}

stage

Each stage represents a logical part of the workflow.

stage('Test') {
}

steps

The steps block contains the commands Jenkins must perform.

steps {
    echo 'Running tests'
}

checkout scm

This step checks out the source code associated with the configured source control project.

---

How to Create Your First Jenkins Pipeline

The exact menus can vary slightly between Jenkins versions and installed plugins. However, the basic process remains similar.

Step 1: Install Jenkins

Jenkins supports installation through several methods, including:

• Docker
• Linux packages
• Windows packages
• macOS packages
• Kubernetes
• A Jenkins WAR file

Before installation, review the current Java and operating-system requirements in the official Jenkins installation guide.

For production use, choose a supported Jenkins Long-Term Support release and maintain regular backups.

Step 2: Complete Initial Setup

After starting Jenkins, open its web interface.

A local installation commonly uses an address similar to:

http://localhost:8080

Jenkins asks for the initial administrator password. Next, the setup wizard helps install plugins and create an administrator account.

Choose the recommended plugins while learning. Later, install only the additional plugins your project requires.

Step 3: Connect a Git Repository

Your source code may exist on:

• GitHub
• GitLab
• Bitbucket
• A private Git server

Jenkins may require repository credentials when the project is private.

Step 4: Add a Jenkinsfile

Create a file named Jenkinsfile in the repository root:

pipeline {
    agent any

    stages {
        stage('Test') {
            steps {
                echo 'My first Jenkins Pipeline is running'
            }
        }
    }
}

Commit and push it:

git add Jenkinsfile
git commit -m "Add Jenkins pipeline"
git push origin main

Step 5: Create a Pipeline Job

From the Jenkins dashboard:

1. Select New Item.
2. Enter a job name.
3. Choose Pipeline.
4. Select OK.
5. Find the Pipeline section.
6. Select Pipeline script from SCM.
7. Choose Git as the source control system.
8. Enter the repository URL.
9. Add credentials if required.
10. Set the branch.
11. Keep Jenkinsfile as the script path.
12. Save the job.

Step 6: Run the Pipeline

Select Build Now.

Jenkins creates a new build and runs the stages defined in the Jenkinsfile.

Step 7: Check the Result

Open the build number and select Console Output.

The console shows:

• Repository checkout details
• Commands
• Test output
• Errors
• Warnings
• Final build status

A successful build normally appears green or blue, depending on the interface or theme. A failed build appears red.

---

Jenkins Pipeline Example for Node.js

The following Jenkinsfile installs dependencies, runs linting and tests, creates a build, and archives the output:

pipeline {
    agent any

    tools {
        nodejs 'NodeJS'
    }

    options {
        timestamps()
        timeout(time: 20, unit: 'MINUTES')
    }

    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }

        stage('Install Dependencies') {
            steps {
                sh 'npm ci'
            }
        }

        stage('Code Quality') {
            steps {
                sh 'npm run lint'
            }
        }

        stage('Test') {
            steps {
                sh 'npm test'
            }
        }

        stage('Build') {
            steps {
                sh 'npm run build'
            }
        }

        stage('Archive') {
            steps {
                archiveArtifacts artifacts: 'dist/**/*',
                    fingerprint: true
            }
        }
    }

    post {
        success {
            echo 'Pipeline completed successfully'
        }

        failure {
            echo 'Pipeline failed'
        }

        always {
            cleanWs()
        }
    }
}

The exact commands depend on the project’s package.json scripts and installed Jenkins plugins.

---

Jenkins Pipeline Example for Flutter

Flutter developers can use Jenkins to analyze, test, and build their applications.

pipeline {
    agent {
        label 'flutter-android'
    }

    options {
        timestamps()
        timeout(time: 45, unit: 'MINUTES')
        disableConcurrentBuilds()
    }

    environment {
        PUB_CACHE = "${WORKSPACE}/.pub-cache"
    }

    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }

        stage('Flutter Information') {
            steps {
                sh 'flutter --version'
                sh 'flutter doctor -v'
            }
        }

        stage('Install Dependencies') {
            steps {
                sh 'flutter pub get'
            }
        }

        stage('Check Formatting') {
            steps {
                sh 'dart format --output=none --set-exit-if-changed .'
            }
        }

        stage('Analyze') {
            steps {
                sh 'flutter analyze'
            }
        }

        stage('Test') {
            steps {
                sh 'flutter test'
            }
        }

        stage('Build APK') {
            when {
                branch 'main'
            }

            steps {
                sh 'flutter build apk --release'
            }
        }

        stage('Archive APK') {
            when {
                branch 'main'
            }

            steps {
                archiveArtifacts(
                    artifacts: 'build/app/outputs/flutter-apk/app-release.apk',
                    fingerprint: true
                )
            }
        }
    }

    post {
        success {
            echo 'Flutter pipeline completed successfully'
        }

        failure {
            echo 'Flutter pipeline failed. Review the console output.'
        }

        always {
            cleanWs()
        }
    }
}

The flutter-android agent must already contain the required Flutter, Java, Gradle, and Android SDK tools.

A production Flutter pipeline may also require:

• Android signing configuration
• Keystore credentials
• Environment files
• Firebase configuration
• Version management
• App distribution
• Google Play deployment

For iOS builds, Jenkins needs a properly configured macOS agent with Xcode, CocoaPods, Apple certificates, and provisioning profiles.

---

Using Environment Variables

Environment variables store reusable configuration values.

Example:

pipeline {
    agent any

    environment {
        APP_ENV = 'staging'
        API_BASE_URL = 'https://staging-api.example.com'
    }

    stages {
        stage('Show Environment') {
            steps {
                echo "Environment: ${APP_ENV}"
                echo "API URL: ${API_BASE_URL}"
            }
        }
    }
}

Non-sensitive configuration may appear directly in the Jenkinsfile.

However, passwords, tokens, certificates, and private keys should use Jenkins Credentials.

---

How Jenkins Credentials Work

Jenkins provides a credentials system for storing sensitive information.

Common credential types include:

• Username and password
• Secret text
• Secret file
• SSH username with a private key
• Certificate

Credentials may contain:

• Git access tokens
• Deployment passwords
• Cloud credentials
• API keys
• Android keystores
• SSH keys
• Signing certificates
• Container-registry passwords

A Jenkins administrator or authorized user can add credentials through the Jenkins interface.

Each credential receives an ID. The pipeline uses that ID instead of writing the secret value directly.

The official Jenkins credentials guide explains how Jenkins stores and supplies credentials to jobs.

Using Username and Password Credentials

pipeline {
    agent any

    stages {
        stage('Authenticate') {
            steps {
                withCredentials([
                    usernamePassword(
                        credentialsId: 'deployment-account',
                        usernameVariable: 'DEPLOY_USER',
                        passwordVariable: 'DEPLOY_PASSWORD'
                    )
                ]) {
                    sh '''
                        ./deploy.sh "$DEPLOY_USER" "$DEPLOY_PASSWORD"
                    '''
                }
            }
        }
    }
}

Jenkins provides the values only inside the withCredentials block.

Using Secret Text

withCredentials([
    string(
        credentialsId: 'api-token',
        variable: 'API_TOKEN'
    )
]) {
    sh './publish.sh'
}

The script can access API_TOKEN as an environment variable.

Never print secrets in the console. In addition, avoid enabling shell tracing around sensitive commands.

---

Jenkins Build Triggers

Jenkins offers several ways to start a pipeline.

Manual Trigger

A user selects Build Now from the Jenkins dashboard.

This method is useful while testing a new pipeline.

Webhook Trigger

A Git provider sends a request to Jenkins after a repository event.

Events may include:

• Code push
• Pull request
• Merge request
• Tag creation

Webhooks allow Jenkins to start quickly without continuously checking the repository.

Polling Source Control

Jenkins checks the repository on a schedule and starts a build when it detects changes.

Example:

triggers {
    pollSCM('H/5 * * * *')
}

This example asks Jenkins to check periodically. It does not necessarily force a build every five minutes; Jenkins starts one when it detects a relevant change.

Scheduled Trigger

A scheduled trigger starts the pipeline at configured times.

triggers {
    cron('H 2 * * *')
}

This pattern is useful for nightly tests, maintenance, dependency checks, or backup jobs.

Jenkins uses a cron-like syntax. The H character distributes workload more evenly than hard-coding the same minute for every job.

Upstream Trigger

One Jenkins job can start after another job finishes.

This approach can connect related workflows. However, Pipeline and multi-project designs often provide clearer alternatives for complex delivery systems.

---

Using Build Parameters

Parameters let users provide values before starting a pipeline.

pipeline {
    agent any

    parameters {
        choice(
            name: 'ENVIRONMENT',
            choices: ['development', 'staging', 'production'],
            description: 'Select deployment environment'
        )

        booleanParam(
            name: 'RUN_SECURITY_SCAN',
            defaultValue: true,
            description: 'Run the security scan'
        )

        string(
            name: 'VERSION_NAME',
            defaultValue: '1.0.0',
            description: 'Application version'
        )
    }

    stages {
        stage('Display Settings') {
            steps {
                echo "Environment: ${params.ENVIRONMENT}"
                echo "Version: ${params.VERSION_NAME}"
            }
        }
    }
}

Parameters work well for:

• Environment selection
• Version numbers
• Feature flags
• Optional testing
• Deployment regions
• Release types

Do not use plain text parameters for secrets.

---

Conditional Jenkins Stages

A pipeline may run a stage only under selected conditions.

Run on the Main Branch

stage('Deploy Production') {
    when {
        branch 'main'
    }

    steps {
        sh './deploy-production.sh'
    }
}

Run for a Tag

stage('Create Release') {
    when {
        buildingTag()
    }

    steps {
        sh './create-release.sh'
    }
}

Run with a Parameter

stage('Security Scan') {
    when {
        expression {
            return params.RUN_SECURITY_SCAN
        }
    }

    steps {
        sh './security-scan.sh'
    }
}

Conditions prevent unnecessary or unsafe pipeline work.

---

Manual Approval Before Deployment

Production deployment often requires approval.

Jenkins provides the input step:

stage('Production Approval') {
    steps {
        input message: 'Deploy this build to production?',
              ok: 'Deploy'
    }
}

After reaching this stage, the pipeline pauses.

An authorized user can review the staging build and approve or reject the release.

A safer setup should also:

• Restrict who can approve
• Add a timeout
• Protect production credentials
• Record the deployed artifact
• Maintain a rollback plan

Example with a timeout:

stage('Production Approval') {
    steps {
        timeout(time: 30, unit: 'MINUTES') {
            input message: 'Deploy to production?',
                  ok: 'Deploy'
        }
    }
}

---

Running Jenkins Stages in Parallel

Independent tests can run at the same time.

stage('Parallel Tests') {
    parallel {
        stage('Unit Tests') {
            steps {
                sh 'npm run test:unit'
            }
        }

        stage('Integration Tests') {
            steps {
                sh 'npm run test:integration'
            }
        }

        stage('Security Check') {
            steps {
                sh 'npm audit'
            }
        }
    }
}

Parallel execution can reduce total pipeline time. However, the agents must have enough resources and available executors.

---

Using the post Section

The post section defines actions that run after the pipeline or stage finishes.

post {
    success {
        echo 'Build passed'
    }

    failure {
        echo 'Build failed'
    }

    unstable {
        echo 'Build is unstable'
    }

    aborted {
        echo 'Build was canceled'
    }

    always {
        echo 'Pipeline finished'
    }
}

Common post-build actions include:

• Sending notifications
• Publishing test results
• Archiving logs
• Cleaning the workspace
• Recording metrics
• Uploading artifacts

The always block runs regardless of the final status.

---

Archiving Build Artifacts

The archiveArtifacts step stores files from the workspace.

stage('Archive') {
    steps {
        archiveArtifacts(
            artifacts: 'build/**/*',
            fingerprint: true,
            onlyIfSuccessful: true
        )
    }
}

A fingerprint helps Jenkins track where an artifact came from and where pipelines use it.

For large production artifacts, an external repository often provides better storage, access control, retention, and scalability.

---

Publishing Test Results

Jenkins can display structured test results when the pipeline provides supported report files.

Example with JUnit:

post {
    always {
        junit allowEmptyResults: true,
              testResults: 'reports/**/*.xml'
    }
}

Jenkins can then show:

• Total tests
• Passed tests
• Failed tests
• Skipped tests
• Test history
• Failure details

The project’s testing framework must generate a compatible report.

---

Jenkins Freestyle Job vs Pipeline

Jenkins supports both Freestyle jobs and Pipeline jobs.

Feature	Freestyle Job	Pipeline
Configuration	Mainly web interface	Jenkinsfile
Version control	Limited	Strong
Code review	Difficult	Easy
Complex stages	Less suitable	Well supported
Parallel execution	Plugin-dependent	Built-in Pipeline support
Reusability	Limited	Stronger
Best for modern CI/CD	Not usually	Yes
Beginner setup	Simple	Requires Jenkinsfile basics

Freestyle jobs work for small, isolated tasks. However, Pipeline jobs provide better visibility, version control, and maintainability for modern CI/CD.

---

What Is a Multibranch Pipeline?

A Multibranch Pipeline automatically discovers branches that contain a Jenkinsfile.

Suppose a repository contains:

main
develop
feature/login
feature/payment

Jenkins can create and run a separate pipeline for each eligible branch.

Multibranch Pipelines are useful because they:

• Automatically detect branches
• Test feature branches
• Support pull requests
• Support merge requests
• Use the Jenkinsfile from each branch
• Remove some manual job configuration

This approach works well for teams that use feature branches and code review.

---

Using Docker in Jenkins Pipelines

Docker can create consistent pipeline environments.

Example:

pipeline {
    agent {
        docker {
            image 'node:22'
        }
    }

    stages {
        stage('Install') {
            steps {
                sh 'npm ci'
            }
        }

        stage('Test') {
            steps {
                sh 'npm test'
            }
        }
    }
}

Jenkins starts a container from the selected image and runs the pipeline commands inside it.

Docker-based agents can provide:

• Consistent tool versions
• Isolated builds
• Easier cleanup
• Repeatable environments
• Reduced permanent agent configuration

The Jenkins environment still needs the correct Docker integration and permissions.

---

Common Jenkins Build Statuses

Jenkins uses several statuses to describe a build.

Success

All required stages completed successfully.

Failure

A required step or stage failed.

Unstable

The build completed, but Jenkins detected problems such as failed tests or quality warnings.

Aborted

A user, timeout, or system action stopped the build.

Not Built

Jenkins skipped a stage or build because an earlier condition prevented it from running.

Understanding these statuses helps teams respond correctly.

---

How to Debug a Failed Jenkins Pipeline

A failed pipeline is a normal part of development.

Follow these steps:

1. Open the failed build.
2. View the Console Output.
3. Find the failed stage.
4. Locate the first meaningful error.
5. Identify the exact command that failed.
6. Run the same command locally.
7. Check tool versions and file paths.
8. Verify agent labels and availability.
9. Review credentials and permissions.
10. Fix the problem and push another commit.

Common pipeline failures include:

• Incorrect Jenkinsfile syntax
• Missing plugins
• Missing dependencies
• Failed tests
• Incorrect environment variables
• Wrong file paths
• Unavailable agents
• Missing agent tools
• Invalid credentials
• Network failures
• Deployment permissions
• Insufficient disk space
• Command timeout

The final error line may describe only the result. Therefore, check earlier log lines to find the original cause.

---

Common Jenkins CI/CD Mistakes

Beginners often make several avoidable mistakes.

Running Builds on the Controller

Application builds can consume resources and increase risk. Use dedicated agents whenever possible.

Installing Too Many Plugins

Every plugin adds maintenance and security responsibilities. Install only trusted plugins that the project needs.

Storing Secrets in the Jenkinsfile

Repository users may see committed credentials. Use Jenkins Credentials instead.

Creating One Large Stage

A large stage makes failures harder to identify. Divide the pipeline into clear units such as analysis, test, build, and deployment.

Ignoring Timeouts

A stuck command may occupy an executor indefinitely. Add appropriate pipeline or stage timeouts.

Keeping Unlimited Build History

Old logs and artifacts consume storage. Configure reasonable retention rules.

Using One Agent for Every Workload

Different projects may need different tools and security levels. Use labels and dedicated agents where appropriate.

Deploying Unverified Builds

Deploy the same tested artifact rather than rebuilding the application differently during production release.

Ignoring Backups

Jenkins contains job history, credentials, configuration, and plugin data. Regular backups are essential.

Allowing Unrestricted Access

A publicly exposed or poorly protected Jenkins server creates a serious security risk.

---

Jenkins Security Best Practices

Jenkins often has access to source code, secrets, build machines, and production servers. Therefore, security must be part of the setup.

Follow these recommendations:

• Enable authentication
• Apply role-based authorization
• Disable anonymous administrative access
• Keep Jenkins updated
• Update plugins regularly
• Remove unused plugins
• Use HTTPS
• Protect credentials
• Restrict production secrets
• Use separate service accounts
• Limit token permissions
• Run builds on agents
• Isolate untrusted builds
• Back up Jenkins data
• Protect webhook endpoints
• Review access logs
• Avoid exposing Jenkins directly to the public internet
• Restrict the Script Console
• Test upgrades before production
• Rotate credentials regularly

Never allow untrusted pull requests to access production secrets.

---

Jenkins Pipeline Best Practices

A good Jenkins Pipeline should be clear, fast, secure, and repeatable.

Store the Jenkinsfile in Git

Version control provides history, review, and rollback.

Keep Stages Focused

Each stage should have one clear purpose.

Run Fast Checks Early

Formatting and linting can fail quickly. Run them before slow builds.

Use Small Commits

Small changes make failures easier to investigate.

Reuse Tested Scripts

Complex build logic often belongs in scripts or build tools that developers can also run locally.

Pin Important Tool Versions

Stable versions improve reproducibility.

Use Credentials Securely

Never hard-code passwords, tokens, or private keys.

Add Timeouts

Timeouts prevent stalled processes from using agents indefinitely.

Clean Workspaces Carefully

Old files may affect later builds. Use clean environments while preserving required caches.

Archive Important Output

Store deployable builds and test reports with clear version information.

Add Notifications

Inform the right people when important pipelines fail or deployments finish.

Create a Rollback Process

Production deployment should include a tested recovery plan.

Monitor Jenkins

Track controller health, agent availability, disk space, queue size, and build duration.

---

Jenkins Advantages

Jenkins provides several major benefits:

• Free and open source
• Extensive plugin ecosystem
• Highly customizable
• Supports many languages
• Works with different Git providers
• Supports distributed agents
• Supports Pipeline as Code
• Can run on private infrastructure
• Integrates with containers and cloud platforms
• Handles simple and complex workflows

---

Jenkins Limitations

Jenkins also creates responsibilities.

• Initial setup can take time.
• The interface may feel complex to beginners.
• Plugins require regular maintenance.
• Self-hosted infrastructure needs monitoring.
• Security configuration requires care.
• Pipeline code can become difficult to maintain.
• Controller backups and upgrades need planning.
• Plugin compatibility can cause issues.
• Scaling requires infrastructure knowledge.

Jenkins offers extensive control, but teams must manage that control responsibly.

---

Jenkins vs GitHub Actions vs GitLab CI/CD

Feature	Jenkins	GitHub Actions	GitLab CI/CD
Hosting	Usually self-managed	GitHub-managed or self-hosted	GitLab-managed or self-managed
Configuration	Jenkinsfile	YAML workflow	.gitlab-ci.yml
Repository integration	Multiple providers	Best with GitHub	Best with GitLab
Plugin ecosystem	Very large	Marketplace actions	Templates and integrations
Maintenance	Usually higher	Usually lower	Depends on hosting
Customization	Very high	High	High
Beginner setup	Moderate	Often easier	Often easier
Infrastructure control	Very high	Depends on runner	Depends on runner
Best use case	Custom or existing automation environments	GitHub projects	GitLab projects

No single platform is always best.

Jenkins works well when an organization needs strong infrastructure control, custom workflows, multiple source-control systems, or existing Jenkins integrations.

---

Frequently Asked Questions

Is Jenkins free?

Yes. Jenkins is free and open-source software. However, organizations still pay for the servers, cloud resources, maintenance, security, backups, and staff required to operate it.

Is Jenkins a CI or CD tool?

Jenkins supports both Continuous Integration and Continuous Delivery or Deployment. Its actual role depends on the pipeline configuration.

Does Jenkins require coding?

Basic jobs may use the web interface. However, modern Jenkins Pipelines normally use a Jenkinsfile. Developers should understand basic Groovy-style Pipeline syntax and command-line tools.

What language does a Jenkinsfile use?

A Jenkinsfile uses Jenkins Pipeline syntax, which builds on Groovy.

Where should I store the Jenkinsfile?

Store it in the root of the source-code repository unless the job uses a different configured script path.

Can Jenkins build Flutter applications?

Yes. An agent with Flutter and the required Android or iOS tools can analyze, test, build, sign, and distribute Flutter applications.

Can Jenkins deploy websites?

Yes. Jenkins can deploy websites to cloud platforms, hosting services, containers, Kubernetes, and private servers.

Does Jenkins need Docker?

No. Jenkins can run without Docker. However, Docker can provide isolated and consistent build environments.

What is the difference between a controller and an agent?

The controller manages Jenkins, schedules jobs, and coordinates the system. Agents execute build and pipeline tasks.

What is the difference between a job and a build?

A job defines what Jenkins should do. A build represents one execution of that job.

What is the difference between a stage and a step?

A stage represents a major pipeline phase. A step represents an individual action inside that phase.

Can Jenkins run jobs automatically?

Yes. Webhooks, repository polling, schedules, upstream jobs, and API requests can start Jenkins jobs automatically.

Should beginners learn Jenkins?

Yes, especially if they want to learn DevOps, build automation, testing, deployment, or enterprise CI/CD workflows.

---

Conclusion

Jenkins is a powerful open-source automation server that helps teams build complete CI/CD workflows.

A developer pushes code to a repository, and Jenkins starts the configured pipeline. An agent then downloads the code, installs dependencies, runs quality checks, executes tests, creates a build, archives artifacts, and deploys the application.

The Jenkinsfile stores this process as code. As a result, teams can review, track, and improve the pipeline with the application.

Beginners should start with a small Declarative Pipeline. First, create a checkout and test stage. Next, add code analysis and build creation. After that, introduce artifacts, credentials, staging deployment, manual approval, production deployment, monitoring, and rollback support.

A well-designed Jenkins CI/CD pipeline reduces manual work, detects problems earlier, and creates a reliable software delivery process.