What is Jenkins?

You may have found in the internet that it's an automated server - its special purpose is to automate tasks. But nobody told you that JENKINS is a Java Application. Yes, it is!

Here’s what that means:

1. It's an Application, Not an OS: Jenkins is an application, and you run it on an operating system.

2. Platform Independent (Because of Java): Since Jenkins is written in Java, it can run on any operating system that has a Java Runtime Environment (JRE). This makes it incredibly flexible. You can install and run the Jenkins server on Windows, macOS, and many different versions of Linux (like Ubuntu, Red Hat, etc.).

3. Commonly Hosted on Linux: While it can run anywhere, Jenkins is very commonly installed on Linux servers in real-world production environments. Companies often choose Linux because it's stable, secure, and works very well with the command-line tools and scripts that Jenkins needs to orchestrate.

So, to summarize: Jenkins isn't a Linux server, but rather a cross-platform server application that is most frequently run on a Linux server.

How Jenkins works internally?

When you run sudo dnf install jenkins and sudo systemctl start jenkins, a few key things happen on your Linux machine.

1. The Installation The installer package (.rpm for RHEL/dnf) places files in a few standard Linux locations:

2. The Program File: The core Jenkins application itself is a single file called jenkins.war (a Web Application Archive, which is a standard way to package Java web apps). This usually gets placed in a directory like /usr/lib/jenkins/ or /usr/share/java/.

3. The Service File: A configuration file is created for systemd, which is the system manager for modern Linux. This file (e.g., /etc/systemd/system/jenkins.service) tells Linux how to run Jenkins—for example, to start it automatically on boot and to run it as a special jenkins user for security.

4. The "Jenkins Home" Directory (The Most Important Part)

5. The "Jenkins Home" Directory (The Most Important Part) When Jenkins runs for the first time, it creates a special directory that is the brain and memory of your entire setup. This is called the Jenkins Home Directory. On Linux, its default location is: /var/lib/jenkins/

Think of this directory as Jenkins's personal office. Everything that makes your Jenkins unique is stored here. If you were to back up this one folder, you would have backed up everything: your jobs, plugins, and configurations.

Here's what's inside /var/lib/jenkins/:

• config.xml: This is the main system configuration file. It stores global settings like security configurations and plugin settings. It's the master blueprint.
• jobs/: This is a directory that acts as a filing cabinet. Inside, there's a folder for every single job you create. So you would see a folder named jobs/Hello-World/. Inside that folder is another config.xml that contains the specific configuration for just that one job.
• plugins/: This is the toolbox. When you install plugins, their files (.hpi or .jpi) are downloaded and stored here.
• workspace/: This is the workbench. When Jenkins runs a job, it creates a temporary subdirectory here with the same name as the job (e.g., workspace/Hello-World/). This is where it checks out your source code from Git and actually executes the build commands (echo, mvn, docker, etc.). This folder is temporary and can be cleaned out between builds.
• users/: Stores information about user accounts.
• secrets/: Where Jenkins stores encrypted passwords, API keys, and other credentials you save. So, when you start the Jenkins service, it's essentially just launching that jenkins.war file. The first thing the application does is look for its home directory (/var/lib/jenkins/). It reads the config.xml files, loads all the plugins from the plugins/ folder, and gets ready to run jobs in the workspace/ folder.

Understanding Jenkins Pipelines

A Pipeline, however, is like writing down the entire, detailed recipe in a text file. Instead of clicking buttons, you describe your entire build, test, and deployment process in code. This approach is called "Pipeline as Code."

Why You Need a Jenkinsfile (The Big Advantages)

Imagine your company has 20 different software projects.

1. With Freestyle jobs: You would have to manually create and configure 20 different jobs in the Jenkins UI. If you need to update them all, you have to edit all 20 jobs by hand. It's slow and prone to errors.

2. With a Jenkinsfile, You can create one master Jenkinsfile template. All 20 projects can just use that same file. If you need to make an update, you change it in one place. Here are the key benefits of "Pipeline as Code":

3. It's Version Controlled: The Jenkinsfile is saved in GitHub with your code. You can see who changed the build process and when. You can revert to an old version if a change breaks things. With Freestyle, the configuration is just "somewhere" in Jenkins, and it's hard to track changes.

4. It's More Durable: If your Jenkins server completely crashes and you lose everything, your Freestyle job configurations are gone forever. But with a Jenkinsfile, the "recipe" for your build is safely stored in GitHub. You can set up a new Jenkins server and point it to your code, and you're back in business instantly.
5. It's Sharable and Reusable: As in the example above, you can share and reuse pipelines across many projects, which is much more efficient.
6. It Allows for Code Review: A change to the build process can be reviewed by your teammates in a Pull Request, just like any other code. This prevents one person from making a change in the UI that could accidentally break the entire project.

How a Jenkinsfile Works (The Mechanics)

So how does Jenkins actually use this file? It's a two-part process:

1. In your Code Repository (like GitHub): You create a file named Jenkinsfile. You write the steps for your build inside this text file.

2. In Jenkins: You create a new type of job. Instead of "Freestyle project," you choose "Pipeline". The configuration for this job is incredibly simple. Instead of adding lots of build steps, you just do one thing: you go to the "Pipeline" section and tell it, "get your instructions from a Jenkinsfile in my Git repository."

Here is what a very simple Jenkinsfile looks like:

pipeline {
    agent any

    stages {
        stage('Build') {
            steps {
                echo 'Hello from a Jenkins Pipeline!'
            }
        }
    }
}

• pipeline { ... }: This is the main block that wraps the entire script. Everything must be inside this.

• agent any: This tells Jenkins where to run the job. The agent is the machine or environment that will execute the steps. agent any is the simplest option—it just tells Jenkins to run this on any available machine.

• stages { ... }: This block contains all the different phases of our process. A typical pipeline is broken down into multiple stages.

• stage('...') { ... }: This defines a specific phase of your pipeline. You give it a name, like 'Build', 'Test', or 'Deploy'. These stages show up as separate columns in the Jenkins UI, so you can see where your process succeeded or failed.

• steps { ... }: Inside each stage, the steps block contains the actual commands you want to run.

• echo '...': This is one of those steps! It's the same echo command we used in our Freestyle job.

When Jenkins runs this, it will:

Execute everything inside the stage('Build'). If that succeeds, it will move on and execute everything inside the stage('Test').

pipeline {
    agent any

    stages {
        // Stage 1
        stage('Build') {
            steps {
                echo 'Building the application...'
            }
        }

        // --- THIS IS THE NEW PART WE ADDED ---
        // Stage 2
        stage('Test') {
            steps {
                echo 'Running tests...'
            }
        }
        // ------------------------------------

    }
}

The Power of Plugins

Think of a brand new smartphone. Out of the box, it can make calls, send texts, and browse the internet. It has the basic functions. But its real power comes from the App Store. When you want to navigate somewhere, you install Google Maps. When you want to listen to music, you install Spotify.

Jenkins works exactly the same way:

• Base Jenkins is the smartphone. It knows how to run jobs and orchestrate pipelines.
• Plugins are the apps you install to give Jenkins new powers.
• When you first set up Jenkins, you already did this when you chose "Install suggested plugins". You were installing the "apps" needed for common tasks!
• When you install a plugin, it gives you new commands (or steps) that you can use in your Jenkinsfile.

For example:

• To get code from GitHub, you need the Git Plugin, which gives you a git step.
• To build a Java project with Maven, you need the Maven Plugin, which gives you tools for running Maven commands.
• To send a notification to a Slack channel, you need the Slack Plugin, which gives you a slackSend step.
• So, the steps block in your Jenkinsfile might look like this with plugins:

steps {
    // This 'git' step comes from the Git Plugin
    git 'https://github.com/your-repo/your-project.git'

    // This 'sh' step is a basic command to run a Maven build
    sh './mvnw clean install'
}