Skip to content

CICD

  • Concept: Continuous Integration and Continuous Delivery (CI/CD) is a methodology that introduces automation into the software development lifecycle to frequently and reliably deliver applications to customers. It solves the integration problems that arise when development and operations teams merge new code.
  • The CI/CD Pipeline: The interrelated practices of CI, CD, and Continuous Deployment offer continuous automation and monitoring from integration and testing through to delivery and deployment. These pipelines are heavily utilized in Agile, DevOps, and Site Reliability Engineering (SRE) environments.
  • Continuous Integration (CI): The practice of automating the integration of code changes from multiple contributors into a single software project.
    • Example: Several developers are working on different features of a web app. Every time a developer commits their code to the shared repository (e.g., GitHub), an automated system immediately builds the application and runs unit tests to ensure the new code hasn’t broken anything.
  • Continuous Delivery (CD): An extension of CI where code changes are automatically prepared for a release to a production environment. The deployment process is fully automated, but the final trigger to push to production requires manual human approval.
    • Example: After the CI pipeline builds and tests the code, the application is automatically deployed to a “Staging” environment. A QA team reviews it, and once approved, a manager clicks a button to deploy the exact same build to the live production servers.
  • Continuous Deployment: The most advanced stage, where every change that passes all stages of your production pipeline is released to your customers automatically, with no human intervention.
    • Example: A developer merges a bug fix. The system builds it, tests it, deploys it to a staging environment for automated integration tests, and upon passing, immediately deploys it to the live servers without anyone clicking “approve.”

There is a vast ecosystem of tools designed to implement CI/CD pipelines.

  • Description: An open-source automation server where the central build and CI process take place. It is a self-contained, Java-based program.
  • Key Features:
    • Simple, user-friendly interface with easy configuration.
    • Massively extensible with hundreds of community-contributed plugins.
    • Supports distributed builds using a Master-Slave architecture.
    • Build schedules can be based on expressions.
    • Supports shell and Windows command execution in pre-build steps.
    • Status notifications.
  • License/Hosting: Free and open-source. Packages available for Windows, macOS, and Unix-like OSs.
  • Description: A tool deeply integrated into GitHub to automate developer workflows.
  • Key Features: Allows building, testing, and deploying code directly from GitHub repositories. It supports JavaScript and Container actions to build workflows, handles secrets securely, and integrates easily with cloud providers like Azure.
  • Description: Part of the broader GitLab suite, which includes a web-based Git repository manager, issue tracking, and analytics.
  • Key Features:
    • Triggers builds, tests, and deployments on every commit/push.
    • Executes jobs in VMs, Docker containers, or separate servers.
    • Provides a single source of truth for code and project data.
    • Includes built-in security features: container scanning, SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing), and dependency scanning.
  • License/Hosting: Commercial and free packages. Available as SaaS or self-hosted (on-premises/cloud).
  • Description: A CI/CD tool supporting rapid software development, automation, and publishing.
  • Key Features:
    • Integrates seamlessly with Bitbucket, GitHub, and GitHub Enterprise.
    • Runs builds in containers or VMs with automated parallelization.
    • Offers easy debugging, quick tests, and customized notifications.
    • Supports continuous and branch-specific deployments.
  • License/Hosting: Freemium model (Linux plans start with one free job without parallelism; open-source projects get additional containers). Hosted cloud-managed option or behind a firewall.
  • Description: A build management and CI server developed by JetBrains.
  • Key Features:
    • Runs in a Java environment and integrates deeply with Visual Studio and other IDEs.
    • Supports .NET and open-stack projects.
    • Runs parallel builds simultaneously across different environments.
    • Offers flexible user management, role assignments, and comprehensive activity logging.
    • Provides easy reuse of settings from parent projects to subprojects.
  • License/Hosting: Commercial tool with both free and proprietary licenses. Installable on Windows and Linux.
  • Description: A CI server by Atlassian that automates release management and creates continuous delivery pipelines.
  • Key Features:
    • Supports up to 100 remote build agents.
    • Runs batches of tests in parallel.
    • Automatically detects new branches in Git, Mercurial, or SVN and applies the main line’s CI scheme.
    • Offers per-environment permissions (e.g., developers can deploy to staging, but production remains locked down).
  • License/Hosting: Pricing is based on the number of agents (“build slaves”) rather than user count, determining how many concurrent processes can run.

  • Role in the SDLC: Jenkins automates and accelerates the software development process by integrating construction, documentation, testing, packaging, staging, and deployment.
  • The Problem it Solves: Before tools like Jenkins, developers would write code independently and submit it all at once. The massive resulting build was then tested and deployed, often leading to complex integration conflicts (“merge hell”).
  • The Jenkins Solution: With Jenkins, code is built and tested the moment a developer submits it. Jenkins can check the code multiple times a day, ensuring integration issues are caught immediately.
  • ADVANTAGES
    • user friendly
    • rich plugins
    • platform dependent
    • easy to configure
    • community support
  • Availability: Jenkins is highly versatile. It can be downloaded as a WAR archive, native installation packages, a Homebrew package, or a Docker image.
  • Under the Hood: The source code is Java, utilizing Groovy, Ruby, and Antlr files.
  • Execution: You can run the Jenkins WAR file standalone or deploy it as a servlet on a Java application server like Tomcat. Both methods provide a web UI and a REST API.
  • Plugins: To connect Jenkins to version control systems like Git, you must install the relevant plugins.

Jenkins Execution Environments & Prerequisites

Section titled “Jenkins Execution Environments & Prerequisites”
  • Concept: Jenkins is highly flexible in how it runs. It comes packaged with its own built-in Java servlet container (Jetty), allowing it to run standalone. Alternatively, it can be dropped into an existing Java application server (like Apache Tomcat or GlassFish) as a servlet.
  • Minimum Hardware Requirements:
    • RAM: 256 MB
    • Storage: 1 GB of drive space (Requires 10 GB if running Jenkins as a Docker container).

Jenkins installation varies strictly based on the host operating system or containerization strategy chosen.

1. Docker Installation

  • Logic: Pulls the Long-Term Support (LTS) image, maps the web UI port (8080) and the agent port (50000), and binds a local volume to persist data so your pipelines aren’t lost if the container stops.
  • Command:
Terminal window
docker run -p 8080:8080 -p 50000:50000 -v [yourjenkinshome]:/var/jenkins_home jenkins/jenkins:lts

2. Red Hat / CentOS Installation

  • Logic: Downloads the official Jenkins repository and security key, installs Jenkins alongside the required Java Development Kit and Git, and enables the service to start automatically on system boot.
  • Commands:
Terminal window
# Download tools and fetch the Jenkins repository
sudo yum install -y wget
wget -O /etc/yum.repos.d/jenkins.repo <https://pkg.jenkins.io/redhat/jenkins.repo>
# Import the secure package key
sudo rpm --import <https://pkg.jenkins.io/redhat/jenkins.io.key>
# Install Jenkins, Java 8, and Git
sudo yum install jenkins java-1.8.0-openjdk-devel git -y
# Start and enable the service
sudo systemctl enable jenkins
sudo systemctl restart jenkins

  • Concept: For security purposes, a fresh Jenkins installation is locked. You must prove you have administrative access to the host server by retrieving an automatically generated password.

Step-by-Step Unlock Sequence:

  1. Access the Web UI: Open a web browser and navigate to the port you configured during installation (e.g., http://localhost:8080). Wait for the “Unlock Jenkins” screen to appear.
  2. Retrieve the Password: Locate the automatically generated alphanumeric password. It is stored between two sets of asterisks in the system’s console log. You can extract it using the terminal:
    • Linux Native: sudo cat /var/lib/jenkins/secrets/initialAdminPassword
    • Docker Native: sudo docker exec ${CONTAINER_ID_OR_NAME} cat /var/jenkins_home/secrets/initialAdminPassword
    • (Note: If you ran Docker in detached mode, you can find the password by simply viewing the docker logs for that container).
  3. Unlock: Paste the exact password string into the “Administrator password” field on the web page and click Continue.
  • Crucial Security Note: This initial alphanumeric string serves as your default administrator account password. If you choose to skip creating a custom admin user in the following setup stages, you will need this exact string to log in again.

  • Concept: Out of the box, Jenkins provides basic automation, but Plugins are what truly enhance its functionality to serve specific organizational needs. They allow Jenkins to integrate with cloud providers, version control systems, build tools, and analysis frameworks.
  • The Update Center: A dedicated Jenkins service that keeps track of all open-source plugins created and maintained by the Jenkins community.
  • Package Format: Plugins are packaged as .hpi files. These files contain the underlying code, images, and other resources required for the plugin to operate successfully.

To install plugins, the Jenkins master node must be able to download metadata from the primary Update Center (or a custom configured Update Center). There are two primary ways to manage plugins:

  • Access: Navigating to Manage Jenkins > Manage Plugins.
  • Usage: Administrators can browse the Available tab, which lists all plugins from the Update Center.
  • Execution: You can tick the box next to the desired plugin and select Install without restart to begin using most plugins immediately.

Method 2: The Jenkins Command-Line Interface (CLI)

Section titled “Method 2: The Jenkins Command-Line Interface (CLI)”
  • Access: Using the jenkins-cli.jar file.
  • Usage: Allows a user or an automated script to download a plugin and its dependencies entirely headlessly (without web UI interaction).

Below are the exact commands and flags used to manage plugins via the Jenkins CLI.

Installs a plugin from a local file, a direct URL, or the Update Center.

  • Syntax: java -jar jenkins-cli.jar -s <http://localhost:8080/> install-plugin SOURCE ... [-deploy] [-name VAL] [-restart]
  • Parameters & Flags:
    • SOURCE: The target plugin. If it points to a local file, that file is installed. If it’s a URL, Jenkins downloads and installs it. Otherwise, Jenkins assumes it is a short name (e.g., “findbugs”) and fetches it from the Update Center.
    • deploy: Deploys the plugin right away without postponing the installation until the next reboot.
    • name VAL: Installs the plugin under a custom short name (normally, the name is inferred automatically from the source).
    • restart: Automatically restarts Jenkins upon a successful installation.

Enables one or more installed plugins transitively (meaning any dependencies required by the selected plugin will also be automatically enabled).

  • Syntax: java -jar jenkins-cli.jar -s <http://localhost:8080/> enable-plugin PLUGIN ... [-restart]
  • Parameters & Flags:
    • PLUGIN: The short name(s) of the plugin(s) to enable.
    • restart: Automatically restarts Jenkins after enabling.

Disables installed plugins. By default, it displays messages for both successful and failed operations.

  • Syntax: java -jar jenkins-cli.jar -s <http://localhost:8080/> disable-plugin PLUGIN ... [-quiet (-q)] [-restart (-r)] [-strategy (-s) strategy]
  • Parameters & Flags:
    • PLUGIN: The short name(s) of the plugin(s) to disable.
    • quiet (or q): Suppresses standard console info and only prints error messages.
    • restart (or r): Automatically restarts Jenkins after disabling.
    • strategy (or s): Controls exactly how Jenkins should handle dependant plugins. Accepts three values:
      • none (Default): If a mandatory dependant plugin is currently enabled, the target plugin cannot be disabled.
      • mandatory: All mandatory dependant plugins are disabled alongside the target. Optional dependant plugins remain enabled.
      • all: Completely disables all dependant plugins, regardless of whether they are optional or mandatory.

Jenkins

CI & CD

Build Phase

Testing!

Code Quality : SonarQube

Github Actions

CI/CD Pipeline Artifacts

Continuous Deployment