Jenkins Installation and Setup: Zero-to-Production CI/CD in 30 Minutes

I've seen a single misconfigured Jenkins job take down an entire production deployment pipeline. Not because the code was bad—because the build server ran out of disk space mid-deploy and left a half-baked artifact in production. That's the kind of pain Jenkins is supposed to prevent, but only if you set it up right. This guide walks you through installation and setup from zero, assuming you've never touched a CI/CD tool. By the end, you'll have a running Jenkins instance with a job that builds, tests, and deploys a sample app—and you'll know the gotchas that separate a reliable pipeline from a ticking time bomb.

Why Jenkins? The Problem It Solves

Before Jenkins, teams built and deployed manually. Someone would SSH into a server, pull the latest code, compile, and restart the service. Every time. At 3 AM. And when they forgot a step—like running database migrations—the site went down. Jenkins automates that checklist. It watches your repository and runs your pipeline on every commit. The alternative is a fragile, human-dependent process that breaks under pressure.

Prerequisites: What You Need Before Installing

Jenkins is a Java application. You need a Java Runtime Environment (JRE) version 11 or 17—OpenJDK is fine. Don't use Java 8; it's end-of-life and Jenkins 2.4xx dropped support. You also need a machine with at least 2GB RAM and 10GB free disk. For production, double that. I've seen Jenkins eat 4GB RAM under load with 10 concurrent builds. Also, ensure port 8080 is open—that's the default web UI port. If you're behind a corporate proxy, grab the proxy URL and credentials now; you'll need them for plugin installation.

// io.thecodeforge — DevOps tutorial

# Check Java version
java -version 2>&1 | grep -i version
# Should output something like: openjdk version "11.0.18" 2023-01-17

# Check available disk
df -h / | tail -1
# Look for at least 10GB available

# Check RAM
free -h | grep Mem
# At least 2GB total

Installation: Three Ways to Get Jenkins Running

You have three options: native package, Docker, or WAR file. For beginners, I recommend the native package (apt/yum) because it sets up systemd service and default paths. Docker is great for ephemeral environments but adds complexity with volumes and networking. The WAR file is for advanced users who want to run Jenkins embedded in another app server. We'll cover native package on Ubuntu—the most common setup. On Ubuntu 20.04+, run the commands below. On CentOS/RHEL, use yum with the official Jenkins repo.

// io.thecodeforge — DevOps tutorial

# Add Jenkins repository key and source
wget -q -O - https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key | sudo apt-key add -
sudo sh -c 'echo deb https://pkg.jenkins.io/debian-stable binary/ > /etc/apt/sources.list.d/jenkins.list'

# Update and install
sudo apt-get update
sudo apt-get install -y jenkins

# Start and enable on boot
sudo systemctl start jenkins
sudo systemctl enable jenkins

# Check status
sudo systemctl status jenkins

Initial Setup: Unlock and Configure

After installation, Jenkins is locked down. You need the initial admin password, stored in /var/lib/jenkins/secrets/initialAdminPassword. Copy it, then open http://your-server:8080 in a browser. Paste the password. Next, you'll see the 'Customize Jenkins' screen. Choose 'Install suggested plugins'—it installs the most common ones (Git, Pipeline, Blue Ocean). This takes 2-5 minutes depending on internet speed. After plugins install, create your first admin user. Don't skip this; the default admin user is insecure. Set a strong password and store it in a password manager.

// io.thecodeforge — DevOps tutorial

# Display the initial admin password
sudo cat /var/lib/jenkins/secrets/initialAdminPassword
# Output example: a1b2c3d4e5f6g7h8i9j0

Creating Your First Job: The Hello World of CI/CD

Now you have a running Jenkins. Let's create a freestyle job that pulls code from a Git repo and runs a simple build. This is the 'Hello World' of CI/CD. Later you'll graduate to pipelines. Click 'New Item', name it 'MyFirstJob', select 'Freestyle project'. Under 'Source Code Management', choose Git and enter a repo URL (use a public one like https://github.com/jenkins-docs/simple-java-maven-app). Under 'Build', click 'Add build step' > 'Invoke top-level Maven targets' and enter clean package. Save and click 'Build Now'. Watch the console output. If it's green, you've got a working CI pipeline.

// io.thecodeforge — DevOps tutorial

<!-- This is the config.xml for a freestyle job. You can create it via UI or copy to jobs/MyFirstJob/config.xml -->
<project>
  <actions/>
  <description>My first Jenkins job</description>
  <keepDependencies>false</keepDependencies>
  <properties/>
  <scm class="hudson.plugins.git.GitSCM">
    <userRemoteConfigs>
      <hudson.plugins.git.UserRemoteConfig>
        <url>https://github.com/jenkins-docs/simple-java-maven-app</url>
      </hudson.plugins.git.UserRemoteConfig>
    </userRemoteConfigs>
    <branches>
      <hudson.plugins.git.BranchSpec>
        <name>*/main</name>
      </hudson.plugins.git.BranchSpec>
    </branches>
  </scm>
  <builders>
    <hudson.tasks.Maven>
      <targets>clean package</targets>
      <usePrivateRepository>false</usePrivateRepository>
    </hudson.tasks.Maven>
  </builders>
  <publishers/>
</project>

Securing Jenkins: Don't Skip This

Out of the box, Jenkins has no authentication for anonymous users. Anyone on your network can access the UI, see job configurations, and trigger builds. That's a security nightmare. Go to Manage Jenkins > Configure Global Security. Under 'Access Control', select 'Jenkins’ own user database' and check 'Allow users to sign up' (disable after initial setup). Under 'Authorization', choose 'Logged-in users can do anything' for small teams, or 'Matrix-based security' for fine-grained control. Also, enable CSRF protection and set the agent TCP port to random or fixed. I've seen a disgruntled intern delete all jobs because security was off.

Pipeline as Code: Moving Beyond Freestyle Jobs

Freestyle jobs are fine for simple tasks, but they don't scale. For real projects, use Jenkins Pipeline—a DSL defined in a Jenkinsfile stored in your repo. This treats your CI/CD as code: versioned, reviewable, testable. A pipeline can have stages (Build, Test, Deploy) with parallel steps and conditional logic. Create a new Pipeline job and point it to your repo's Jenkinsfile. Here's a minimal example that builds and tests a Java app.

// io.thecodeforge — DevOps tutorial

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                echo 'Building...'
                sh 'mvn clean compile'
            }
        }
        stage('Test') {
            steps {
                echo 'Testing...'
                sh 'mvn test'
            }
        }
        stage('Package') {
            steps {
                echo 'Packaging...'
                sh 'mvn package'
            }
        }
    }
    post {
        success {
            echo 'Pipeline succeeded!'
        }
        failure {
            echo 'Pipeline failed!'
        }
    }
}

Managing Plugins: The Good, the Bad, the Ugly

Plugins extend Jenkins. There are over 1,800. Most are community-maintained and some are abandoned. The classic mistake: install every plugin that looks useful. This bloats the UI, slows startup, and introduces conflicts. Stick to essentials: Git, Pipeline, Blue Ocean (for a modern UI), Credentials Binding, and Docker Pipeline. Avoid plugins that overlap with core functionality (e.g., 'Build Pipeline Plugin' is obsolete now that Pipeline exists). To install, go to Manage Jenkins > Manage Plugins > Available. Search and install. Restart Jenkins after installation—some plugins require it.

Setting Up Build Agents: Scaling Beyond One Machine

A single Jenkins master can only run so many builds. For production, you need build agents (formerly slaves) to distribute load. Agents can be permanent VMs, Docker containers, or ephemeral cloud instances. To add a permanent agent: Manage Jenkins > Manage Nodes > New Node. Give it a name, set 'Number of executors' (usually 1-2 per CPU core), and provide the agent's connection details (SSH or JNLP). The agent needs Java installed and a user with SSH access. For Docker agents, use the Docker plugin to spin up containers on demand—perfect for isolated builds.

// io.thecodeforge — DevOps tutorial

# On the agent machine, install Java and create a jenkins user
sudo apt update
sudo apt install -y openjdk-11-jre
sudo useradd -m -s /bin/bash jenkins
sudo passwd jenkins  # set a strong password

# On the master, add the agent via UI or CLI
# Then on agent, run the agent command from Jenkins UI:
# java -jar agent.jar -jnlpUrl http://master:8080/computer/agent-name/slave-agent.jnlp -secret <secret> -workDir "/home/jenkins"

Backup and Disaster Recovery: Because It Will Fail

Jenkins stores everything in $JENKINS_HOME (default /var/lib/jenkins). That includes jobs, configs, build logs, and credentials. Lose that directory, lose everything. Back it up regularly. Use a cron job to tar the directory and copy it to S3 or another server. For credentials, use the Credentials Binding plugin and store secrets in a vault (like HashiCorp Vault) rather than in Jenkins. Also, snapshot the entire server before major upgrades. I've seen a failed plugin upgrade corrupt the config.xml and require a restore from backup.

// io.thecodeforge — DevOps tutorial

#!/bin/bash
# Backup Jenkins home directory
BACKUP_DIR="/backup/jenkins"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
mkdir -p $BACKUP_DIR

# Stop Jenkins to ensure consistent backup
sudo systemctl stop jenkins

# Create tar archive
tar -czf $BACKUP_DIR/jenkins_backup_$TIMESTAMP.tar.gz -C /var/lib jenkins

# Start Jenkins
sudo systemctl start jenkins

# Optional: upload to S3
# aws s3 cp $BACKUP_DIR/jenkins_backup_$TIMESTAMP.tar.gz s3://my-jenkins-backups/

echo "Backup completed: $BACKUP_DIR/jenkins_backup_$TIMESTAMP.tar.gz"