What is Jenkins?

Jenkins is an open-source automation server primarily used to automate parts of software development like
building, testing, and deploying applications. It supports Continuous Integration (CI) and Continuous
Delivery (CD), helping teams deliver software faster and more reliably.

Key Features of Jenkins

1. Easy Installation & Configuration

Jenkins can be installed easily on various operating systems (Windows, macOS, Linux) and
configured through a web interface.
2. Extensible with Plugins
Over 1,500 plugins available to integrate with almost any tool in the software development lifecycle
(e.g., Git, Maven, Docker, Kubernetes).
3. Distributed Builds
Supports running builds and tests across multiple machines (agents/slaves) to speed up the process.
4. Pipeline as Code
Allows defining build and deployment pipelines in code using Jenkinsfile, enabling version control
and easier management.
5. Easy Integration
Works with many version control systems like Git, SVN, Mercurial, and supports integration with
tools for testing, static analysis, deployment, notifications, etc.
6. Extensive Community Support
Large community provides regular updates, plugins, and support.
7. Customizable Build Triggers
Jobs can be triggered automatically on events such as code commits, scheduled times, or manual
triggers.
8. Rich User Interface
Web UI to configure jobs, view build results, logs, and trends easily.
9. Security Features
Role-based access control, authentication, and authorization support.

Common Use Cases of Jenkins

1. Continuous Integration (CI)

Automatically build and test code when developers push changes to a repository to detect integration
errors early.
2. Continuous Delivery / Deployment (CD)
Automate the deployment of applications to staging or production environments after successful
builds/tests.
3. Automated Testing
Run unit tests, integration tests, UI tests as part of the pipeline to ensure quality.
4. Build Automation
Automate compiling code, packaging binaries, creating Docker images, etc.
5. Monitoring Execution
Track and visualize build and deployment pipelines, including notifications on success or failure.
6. Infrastructure Automation
Integrate with tools like Ansible, Terraform for infrastructure provisioning and management.
7. Multi-branch Pipeline Support
Automatically create CI/CD pipelines for multiple branches in a repo.
Declarative Pipeline

 Uses a structured, predefined syntax with specific blocks (like pipeline, stage, steps).
 Easier to read and write, especially for beginners.
 Enforces better syntax rules and pipeline structure.
 Supports built-in error handling and post actions (post block).
 Designed for simple to moderately complex pipelines.
 Pipelines are usually stored in a Jenkinsfile in the repo.
 Easier to maintain and standardize across teams.
 Limited flexibility compared to scripted pipelines but safer.
 Uses Groovy-based DSL, but mostly declarative keywords.

Sripted Pipeline

 Written in pure Groovy code, giving full programming flexibility.

 More powerful and flexible for complex workflows.
 Requires stronger Groovy scripting knowledge.
 Allows use of loops, conditions, functions, and custom logic easily.
 Less structured — no enforced pipeline blocks; more prone to errors.
 Good for advanced/customized CI/CD pipelines.
 Also stored in Jenkinsfile, but looks more like traditional code.
 Harder to read and maintain for teams unfamiliar with Groovy.
 Gives full control over the pipeline execution flow.

Feature Declarative Pipeline Scripted Pipeline

Predefined, structured (pipeline, stage,
Syntax Pure Groovy scripting
steps)
Ease of Use Easier for beginners Requires Groovy knowledge
Flexibility Less flexible, more standardized Highly flexible for complex logic
Readability More readable and maintainable Harder to read, like traditional code
Error Handling Built-in (post, try-catch limited) Full control via try-catch-finally blocks
Validation Syntax checked at startup Syntax errors may appear at runtime
Advanced/custom workflows with complex
Best For Simple to medium CI/CD pipelines
logic
Structure
Yes (must use pipeline, stage, etc.) No enforced structure
Enforced?
Supported but less encouraged for new
Support Actively promoted by Jenkins project
pipelines

TYPES OF TRIGGERS

1. Pollscm (polling the source code repository)

 Jenkins checks the version control system (like Git) at fixed intervals for changes.
 If changes are found, it triggers a build.
 Use case: When webhooks are not possible or unreliable.

2. cron (Scheduled Builds)

 Run builds on a specific schedule using cron syntax.

 Independent of source code changes.
 Use case: Nightly builds, regular test runs, or cleanup tasks.
3. Webhook Trigger

 Triggered instantly when a push or pull request is made to a repository (e.g., GitHub, GitLab).
 Requires webhook setup in the repository settings.
 Use case: Immediate feedback after code changes.

4.Upstream Trigger

 A downstream job is triggered after an upstream job completes.

 Use case: Chain jobs together (e.g., Build → Test → Deploy).

5. Manual Trigger

 A developer or user manually starts the job from the Jenkins dashboard or CLI.
 Use case: One-time or on-demand builds and deployments.

6. SCM Commit Hook

 A webhook in the source code repository sends a signal to Jenkins when a commit happens.
 Faster and more efficient than polling.
 Use case: Trigger builds instantly on code push (preferred over pollSCM).

WEBHOOK

A webhook is a way for one system (like GitHub or GitLab) to send real-time data to another system (like
Jenkins) when a specific event happens — such as a code push, pull request, or tag creation.

In Jenkins, a webhook triggers a job automatically when an event occurs in the source code repository,
without polling.

How It Works:

1. You configure a webhook in the source control tool (e.g., GitHub).

2. On a specific event (e.g., git push), GitHub sends an HTTP POST request to Jenkins.
3. Jenkins receives it and triggers the configured job or pipeline.

Common Use Case:

Automatic CI/CD Pipeline Trigger

 When a developer pushes code to a GitHub repository, the webhook notifies Jenkins.
 Jenkins automatically runs the pipeline to build, test, and deploy the code.

Other Use Cases:

 Triggering builds on Pull Requests.

 Updating job statuses or badges on commit.
 Sending alerts or notifications to Slack or email.
 Integrating with third-party systems (e.g., issue trackers, chat tools).

PARAMETERS
Parameters in Jenkins allow you to pass inputs to a job or pipeline at runtime. They make your pipeline
dynamic and reusable by letting you customize behavior without modifying the Jenkinsfile

Type Description Example Use Case

String Single line text input Branch name, version tag
Boolean Checkbox for true/false input Enable debug mode
Choice Dropdown with predefined options Choose environment: dev/stage/prod
Password Hidden input for sensitive data API tokens, database passwords
File Upload a file to use in the build Configuration file, test data
Text Multi-line text input JSON, XML input, or long messages
Git Dynamically fetch branches/tags from a Git repo
Select git branch at build time
Parameter (plugin)
Active Dynamic dropdowns or checkboxes using Groovy Show options based on logic or
Choices scripts (plugin) external input

Use Cases

1. Environment Selection
o Use Choice Parameter to deploy to dev, QA, or prod.
2. Branch/Tag Input
o Use String or Git Parameter to build a specific branch.
3. Toggle Features
o Use Boolean Parameter to turn on/off debug mode or optional steps.
4. Secure Inputs
o Use Password Parameter for credentials without exposing them in logs.
5. Dynamic Logic
o Use Active Choices to build dynamic UI based on job data or user role.
6. Reusable Jobs
o Use parameters to reuse the same pipeline for multiple services or modules.

JENKINSFILE

A Jenkinsfile is a text file that contains the definition of a Jenkins pipeline, written in either Declarative
or Scripted syntax. It is typically stored in the root of your source code repository

Purpose of a Jenkinsfile:

 Automates build, test, and deployment steps (CI/CD pipeline).

 Keeps pipeline logic under version control.
 Makes your Jenkins pipeline reproducible, auditable, and collaborative.

PLUGINS are modular extensions that add new features or integrations to Jenkins. Jenkins has a plugin-
based architecture, meaning most of its core functionality and external tool support comes from plugins.

Purpose of Plugins:

 Extend Jenkins capabilities.

 Integrate with tools like Git, Docker, Kubernetes, Slack, Maven, etc.
 Add UI elements, pipeline steps, and build tools.
 Customize Jenkins to fit your CI/CD workflow.
Plugin Purpose
Git Plugin Integrates Git version control
Pipeline Plugin Enables pipeline jobs and Jenkinsfile support
Docker Plugin Manages Docker containers and images in pipelines
GitHub Plugin Connects Jenkins with GitHub for webhooks and triggers
Credentials Plugin Stores and manages secure credentials
Blue Ocean Provides modern UI for pipelines
Slack Notification Sends build notifications to Slack channels
JUnit Plugin Displays test results in Jenkins UI
Email Extension Sends advanced email notifications

Use Cases:

 Clone code from a Git repository (Git Plugin).

 Build a Maven/Gradle project (Maven Plugin).
 Run a job in a

LABEL

A label in Jenkins is a tag assigned to nodes (agents/slaves) to identify their capabilities or environment
type. It allows Jenkins to select specific agents to run certain jobs based on their requirements.

Purpose of Labels:

 Direct jobs to specific agents (e.g., Linux, Windows, Docker-enabled).

 Organize build nodes based on software, hardware, or location.
 Enable resource targeting in pipelines and freestyle jobs.

Label Use Case

linux Run jobs on Linux agents only
docker Run builds that require Docker installed
java11 Run jobs that require Java 11
gpu Assign machine learning jobs to GPU nodes

 Ensures jobs run in the right environment.

 Improves resource management and job reliability.
 Simplifies agent selection in complex CI/CD setups.

MASTER SLAVE ARCHITECTURE

Jenkins Master-Slave Architecture (now called Controller-Agent)

This architecture helps Jenkins scale by distributing build tasks across multiple machines (agents/slaves).

1. Master (Controller)

 Central Jenkins server.

 Responsible for:
 o Scheduling jobs.
o Dispatching builds to agents.
o Monitoring agents.
o Providing the web UI and managing job configs.
 Can also run builds, but it's better to delegate to agents for performance and isolation.

2. Slave (Agent)

 Remote machine connected to the master.

 Executes build jobs as instructed by the master.
 Can be configured with labels to specify capabilities (e.g., docker, windows, java11).
 Communicates with the master over SSH, JNLP, or other protocols.

How It Works:

1. Master receives a job request.

2. It chooses an appropriate agent based on labels or availability.
3. The agent runs the job and reports the result back to the master.

Benefits:

 Scalability: Add more agents to handle load.

 Isolation: Run jobs on different OSes or environments.
 Efficiency: Distribute builds across multiple nodes to save time.
 Flexibility: Use specific agents for specific tasks (e.g., iOS builds on Mac agents).

Example Use Case:

 Master runs on a small Linux server.

 One agent runs on a Windows machine for .NET builds.
 Another agent runs on a high-performance server with Docker and GPU for ML jobs.

JENKINS HIGHLY AVAILABLE

Making Jenkins highly available (HA) means ensuring it keeps running with minimal downtime, even if
some components fail. Here’s how you can achieve Jenkins HA with real-time examples:

1. Run Jenkins in a Distributed Setup

 Use Multiple Agents: Offload builds to multiple agents so the master isn’t overloaded.
 Example: Use Jenkins master on a stable server, with many build agents on separate machines to
distribute workload.

2. Jenkins Master High Availability

Jenkins by itself doesn’t support active-active master clustering natively, but you can:

 Use External Tools for HA Master:

o Option A: Run Jenkins on Kubernetes
Deploy Jenkins in a Kubernetes cluster with Persistent Volumes (PV) for Jenkins home
directory and set up readiness and liveness probes. Kubernetes will restart Jenkins if it fails,
and you can use multiple replicas with an external load balancer.
Example: Use Jenkins Helm Chart on AWS EKS or GKE with PV backed by AWS EBS or
Google Persistent Disk.
 o Option B: Use Jenkins in a Failover Setup
Run two Jenkins masters with a shared storage (NFS or cloud file storage) for Jenkins home,
but only one active at a time with a Virtual IP (VIP) managed by tools like Keepalived or
Pacemaker. If the active master fails, the VIP moves to the standby master.
Example: Setup two Jenkins servers on separate EC2 instances sharing an EFS file system,
with Keepalived managing the failover.

3. Backup and Restore

 Regularly back up Jenkins home directory (configurations, plugins, job data).

 Use plugins like ThinBackup or automate backups via scripts.
 Store backups offsite or in cloud storage.

4. Use a Load Balancer for User Access

 Place a load balancer (NGINX, HAProxy, AWS ALB) in front of Jenkins.

 This can route traffic to active Jenkins instance or manage SSL termination.

5. Use External Database for Metadata (Optional)

 Jenkins stores data mainly in the file system, but for large setups, consider using external databases
for specific plugins or metadata (some plugins support it).

6. Real-time Examples

 Netflix runs Jenkins with many build agents distributed globally, using Kubernetes for easy scaling
and reliability.
 CloudBees Jenkins Enterprise offers official HA solutions with multi-master active-active
architecture.
 Open-source setups often use Jenkins on Kubernetes or active-passive failover with shared storage.

Summary Table:

Strategy How It Helps Real Example

Distributed Agents Load distribution Multiple build nodes on different OS
Kubernetes Deployment Auto-recovery and scaling Jenkins on AWS EKS with persistent storage
Active-Passive Failover Master redundancy Two EC2 instances with shared EFS and Keepalived
Backup & Restore Data protection ThinBackup plugin scheduled backups
Load Balancer Seamless user access NGINX or AWS ALB in front of Jenkins