My goal was simple: automate everything from code commit to deployment.

I wanted a system where every time I pushed code, the application would automatically build, run tests, create a Docker image, deploy to a server, and notify the team.

After putting all the pieces together, I finally had a pipeline that handled the entire workflow without any manual steps.

How the Pipeline Works

I designed this pipeline to follow a simple workflow.

First, a developer pushes code to GitHub. Jenkins server then detects the change and starts the pipeline automatically. The application is built using Maven, tests are executed, and a Docker image is created.

Once the image is built, Jenkins pushes it to Docker Hub private repository. After that, the new image is deployed to a remote production server on Digital Ocean.

Then automatically increment the application version and commits it to the code repository. Finally, Slack notifications are sent to report whether the build succeeded or failed.

Github Repository

See this Pipeline in Action

https://youtu.be/1jv38kaBVOQ

Jenkins Setup

Setting Up Jenkins

Before creating the pipeline, I first needed to prepare my infrastructure so Jenkins could communicate with all the required services.

For this project, I used two droplets from DigitalOcean. One droplet was used to run Jenkins, and the other droplet acted as the production server where the application would be deployed.

I decided to run Jenkins inside a Docker container instead of installing it directly on the server. This made the setup easier to manage and allowed me to quickly start Jenkins without worrying about system dependencies.

On the Jenkins droplet, I installed Docker and then started Jenkins using the official Jenkins Docker image. I also mounted a Docker volume (jenkins_home) so that Jenkins data would persist even if the container restarted. After starting the container, Jenkins became accessible through the server’s public IP on port 8080.

Once Jenkins was running, I logged into the Jenkins dashboard and installed the plugins needed for the pipeline.

Jenkins Plugins

I installed the Git plugin, which allows Jenkins to pull code from GitHub repositories. Then I installed the Publish over SSH plugin, which enables Jenkins to connect to the remote server and execute deployment commands through SSH.

And also the SCM Skip plugin for avoid triggering builds from commits containing [ci-skip] message.

I also installed the Slack Notification plugin so Jenkins could send build status updates directly to a Slack channel (#ci-cd).

After installing the plugins, the next step was configuring credentials in Jenkins so it could securely interact with external systems.

Jenkins Credentials

First, I added Docker Hub credentials. These credentials allow Jenkins to log in to Docker Hub and push the Docker images built during the pipeline into the private repository.

Next, I configured GitHub credentials, which Jenkins uses to commit version updates back to the repository as Jenkins user after automatically bumping the application version in pom.xml

Finally, I set up SSH credentials for the production server. I generated an SSH key pair on the Jenkins server and added the public key to the authorized_keys file on the production droplet. This allowed Jenkins to securely connect to the server without needing a password.

With this setup in place, Jenkins was able to communicate with GitHub, push images to Docker Hub, and deploy the application to the remote production server.

Once everything was configured, I was ready to start building the CI/CD pipeline itself.

Jenkins Pipeline

I implemented the pipeline using a Jenkins Declarative Pipeline defined in a Jenkinsfile. The pipeline is divided into several stages, each responsible for a specific part of the process.

Breaking the workflow into stages made the pipeline easier to understand and manage.

pipeline {
 agent any

 tools{
    maven 'maven-3.9.13'
 }

 stages{

    stage('Checkout Version') {
                    steps {
                        checkout scm
                        scmSkip(deleteBuild: true, skipPattern:'.*\\[ci-skip\\].*')

                        script{

                            //Incrementing Version

                            sh "mvn build-helper:parse-version versions:set \
                            -DnewVersion=\\\\({parsedVersion.majorVersion}.\\\\){parsedVersion.minorVersion}.\\\${parsedVersion.nextIncrementalVersion} versions:commit"
                            def matcher = readFile('pom.xml') =~ '<version>(.+)</version>'
                            def version = matcher[1][1]
                            env.IMAGE_NAME = "\(version-\){BUILD_NUMBER}"
                            env.IMAGE_TAG= "dewnuwan/java-maven-app:jma-${IMAGE_NAME}"
                        }
                    }
                }

    stage("Build Project"){
        steps{
            script{

                sh 'mvn clean package'

               //commiting to git
                sh """
                   git config user.name "jenkins"
                   git config user.email "jenkins@thesudofiles.com"
                   git add .
                   git commit -m "[ci-skip] version bump"
                   """
                gitPush(gitScm: scm, targetBranch: 'master', targetRepo: 'origin')

            }
        }
    }

    stage("Test"){
        steps {
            script{
                sh 'mvn test'
            }
        }
    }


    stage("Build Image"){
        steps{
            script{
                withCredentials([usernamePassword(credentialsId: 'dockerhub', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) {
                    sh """
                        docker build --pull --cache-from \({IMAGE_TAG} -t \){IMAGE_TAG} .
                        echo \(PASSWORD | docker login -u \)USERNAME --password-stdin
                        docker push ${IMAGE_TAG}
                        docker rmi ${IMAGE_TAG}
                       """
                }

            }
        }
    }


    stage("Deploy"){
        steps{
            echo 'Deploying to remote server..'
            sshPublisher(publishers: [sshPublisherDesc(configName: 'prod-server', transfers: [sshTransfer(cleanRemote: false, excludes: '', execCommand: """docker stop java-maven-app
            docker rm java-maven-app
            docker images dewnuwan/java-maven-app --format "{{.ID}}" | tail -n +2 | xargs -r docker rmi
            docker run -d -p 8080:8080 --name java-maven-app ${IMAGE_TAG}""", execTimeout: 120000, flatten: false, makeEmptyDirs: false, noDefaultExcludes: false, patternSeparator: '[, ]+',
            remoteDirectory: '', remoteDirectorySDF: false, removePrefix: '', sourceFiles: '')], usePromotionTimestamp: false, useWorkspaceInPromotion: false, verbose: false)])
        }
    }

 }

    post {

        success {
            slackSend(
                channel: '#ci-cd',
                color: 'good',
                message: """
:white_check_mark: *BUILD SUCCESS*

*Job:* ${env.JOB_NAME}
*Build:* #${env.BUILD_NUMBER}
*Branch:* ${env.BRANCH_NAME}
*Docker Image:* ${env.IMAGE_TAG}
*Duration:* ${currentBuild.durationString}

*Deployment:* <http://168.144.23.78:8080|Open Application>

*Build Logs:* ${env.BUILD_URL}
"""
            )
        }

        failure {
            slackSend(
                channel: '#ci-cd',
                color: 'danger',
                message: """
:x: *BUILD FAILED*

*Job:* ${env.JOB_NAME}
*Build:* #${env.BUILD_NUMBER}
*Branch:* ${env.BRANCH_NAME}

Check logs:
${env.BUILD_URL}
"""
            )
        }

        unstable {
            slackSend(
                channel: '#ci-cd',
                color: 'warning',
                message: """
:warning: *BUILD UNSTABLE*

*Job:* ${env.JOB_NAME}
*Build:* #${env.BUILD_NUMBER}
*Branch:* ${env.BRANCH_NAME}

Review test results:
${env.BUILD_URL}
"""
            )
        }
    }

}

Pipeline Stages

Stage 1 - Checkout Code & Version Bump

stage('Checkout Version') {
  steps {
          checkout scm
          scmSkip(deleteBuild: true, skipPattern:'.*\\[ci-skip\\].*')

   script{

     //Incrementing Version
sh "mvn build-helper:parse-version versions:set \
-DnewVersion=\\\\({parsedVersion.majorVersion}.\\\\){parsedVersion.minorVersion}.\\\${parsedVersion.nextIncrementalVersion} versions:commit"

  def matcher = readFile('pom.xml') =~ '<version>(.+)</version>'
  def version = matcher[1][1]

  env.IMAGE_NAME = "\(version-\){BUILD_NUMBER}"
  env.IMAGE_TAG= "dewnuwan/java-maven-app:jma-${IMAGE_NAME}"

   }
  }
 }

The first thing the pipeline does is pull the latest code from the Git repository.

After checking out the code, I wanted Jenkins to automatically increment the application version. Instead of manually updating the version every time, I used the Maven versions plugin to automatically increase the patch version in the pom.xml file.

mvn build-helper:parse-version versions:set \
-DnewVersion=\({parsedVersion.majorVersion}.\){parsedVersion.minorVersion}.${parsedVersion.nextIncrementalVersion}

For example, if the version was 1.0.0, the pipeline updates it to 1.0.1.

Once the version is updated, Jenkins reads the new version from the pom.xml file and uses it to generate a Docker image tag.

dewnuwan/java-maven-app:jma-1.0.1-15

This means every build produces a unique Docker image version that can be traced back to the pipeline run.

Stage 2 - Build the Application

stage("Build Project"){
        steps{
            script{

                sh 'mvn clean package'

               //commiting to git
                sh """
                   git config user.name "jenkins"
                   git config user.email "jenkins@thesudofiles.com"
                   git add .
                   git commit -m "[ci-skip] version bump"
                   """
                gitPush(gitScm: scm, targetBranch: 'master', targetRepo: 'origin')

            }
        }
    }

After updating the version, Jenkins builds the application using Maven.

mvn clean package

This step compiles the code and generates the JAR file needed to run the Spring Boot application.

Since Jenkins updated the version earlier, I also configured it to commit that change back to the Git repository. To prevent Jenkins from triggering another build from this commit, I added [ci-skip] to the commit message using SCMSkip plugin.

This avoids an infinite build loop.

Stage 3 - Running Tests

stage("Test"){
        steps {
            script{
                sh 'mvn test'
            }
        }
    }

Next, the pipeline runs all unit tests using Maven.

If any test fails, the pipeline stops immediately. This is important because it prevents broken code from reaching production.

Having automated tests as part of the pipeline ensures that every deployment is verified before it goes live.

Stage 4 - Building and Pushing the Docker Image

stage("Build Image"){
        steps{
            script{
                withCredentials([usernamePassword(credentialsId: 'dockerhub', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) {
                    sh """
                        docker build --pull --cache-from \({IMAGE_TAG} -t \){IMAGE_TAG} .
                        echo \(PASSWORD | docker login -u \)USERNAME --password-stdin
                        docker push ${IMAGE_TAG}
                        docker rmi ${IMAGE_TAG}
                       """
                }

            }
        }
    }

Once the tests pass, Jenkins builds a Docker image for the application.

The Dockerfile packages the Spring Boot JAR file into a container so the application can run in a consistent environment.

FROM eclipse-temurin:25.0.2_10-jre-ubi10-minimal

RUN mkdir app

WORKDIR /app

COPY target/java-maven-app-*.jar .

EXPOSE 8080

CMD java -jar java-maven-app-*.jar

After building the image, Jenkins logs into Docker Hub using stored credentials and pushes the image to the dockerhub registry.

Once the image is successfully pushed, the local copy of the image is removed from the Jenkins server to save disk space. This ensures that the server doesn’t accumulate unused Docker images over time.

Stage 5 - Deploying the Application

  stage("Deploy"){
        steps{
            echo 'Deploying to remote server..'
            sshPublisher(publishers: [sshPublisherDesc(configName: 'prod-server', transfers: [sshTransfer(cleanRemote: false, excludes: '', execCommand: """docker stop java-maven-app
            docker rm java-maven-app
            docker images dewnuwan/java-maven-app --format "{{.ID}}" | tail -n +2 | xargs -r docker rmi
            docker run -d -p 8080:8080 --name java-maven-app ${IMAGE_TAG}""", execTimeout: 120000, flatten: false, makeEmptyDirs: false, noDefaultExcludes: false, patternSeparator: '[, ]+',
            remoteDirectory: '', remoteDirectorySDF: false, removePrefix: '', sourceFiles: '')], usePromotionTimestamp: false, useWorkspaceInPromotion: false, verbose: false)])
        }
    }

After pushing the image to Docker Hub, Jenkins connects to the remote production server using SSH.

The deployment process is simple but effective.

First, Jenkins stops the currently running container. Then it removes the old container and cleans up older Docker images. Finally, it starts a new container using the latest Docker image that was just built.

Within a few seconds, the updated application is running on the server and accessible through port 8080. Everything automated.

Watching the application update automatically without logging into the server manually was very satisfying for me.

Slack Notifications

To make the pipeline more useful, I added Slack notifications.

Whenever a build finishes, Jenkins sends a message to a Slack channel indicating whether the build was successful, failed, or unstable.

The message includes useful information such as the job name, build number, branch, Docker image version, and links to the deployment and build logs.

This makes it easy for the team to quickly see what’s happening with the pipeline.

What I Learned from This Project

Building this pipeline helped me understand how several DevOps tools work together in a real world workflow.

I learned how continuous integration ensures that every code change is automatically built and tested. I also saw how containerization with Docker helps maintain consistency across environments.

Automating version updates made deployments easier to track, while automated deployment removed the need for manual server work.

Most importantly, the pipeline showed me how automation can reduce human error and make the development process much faster.

Final Thoughts

Creating this CI/CD pipeline was a great learning experience.

It was exciting to see the entire workflow run automatically from code commit to deployment without any manual intervention.

This project gave me practical experience with Jenkins, Maven, Docker, GitHub, and Slack integration, and it helped me better understand how modern DevOps pipelines work.

In the future, I plan to expand this project by exploring container orchestration tools like Kubernetes, infrastructure automation, and more advanced deployment strategies such as blue-green deployments.

There is still a lot to learn, but this project was a big step forward in my DevOps journey.

1. whoami

Displays the currently logged-in user.

2. pwd

pwd stands for Print Working Directory. It displays the current directory the user’s in.

3. ls

ls is used to List files and directories. This is one of the most fundamental and frequently used commands in the Linux terminal. When used without any options, it shows the contents of the current directory the user’s in.

Here are the options for the ls.

• -l Long, detailed list of all information.

• -a Lists all files, including hidden files (those starting with a .).

• -h List files with human readable file sizes.

• -r Reverse order lists files with the oldest date first.

4. tree

This command outputs a tree-like view of the specified directory and its content (files, subdirectories). It makes it easier to look up the content inside a directory.

5. cd

The Change Directory command is used for navigating between directories.

cd .. Moves up a directory

cd - Returns to the previous directory

cd Goes to the user’s home directory

6. mkdir

mkdir stands for Make Directory. This command is used for creating directories.

Creating multiple directories at once.

7. cp

cp stands for Copy. This commands is used for copying files and directories.

In this example, I want to copy the linux.txt file into the Documents directory.

So here’s cp command for that.

Verifying inside the Documents directory.

Note using cp with -r allows you to copy a directory with its content.

8. mv

mv stands for Move. This command is used for moving and renaming the files and directories.

Here I moved the linux.txt file from the current directory (/home/dewnuwan/Documents) into the Music directory (/home/dewnuwan/Music).

Verifying inside the Music directory.

While there’s a rename command in Linux, it’s only being used for batch operations. So most of the time we just use mv to rename the files and directories.

9. rm

rm stands for Remove. This is used for removing files from a directory. You need write access for the folder. Here are the most used options for this command.

-r Remove the directory with its subdirectories (alternative to rmdir).

-i Prompt a confirmation message before deleting

-f Force delete (without a confirmation dialogue)

Forceful Recursion

The most common and dangerous combination of options is rm -rf. This command will delete everything in the directory and its subdirectories without any confirmation. So use it carefully.

Here * stands for all in the current directory.

10. rmdir

This is to remove a specified empty directory. Use the option -p to force the deletion.

11. cat

cat is used for viewing content inside of a file. (text files, scripts..etc)

12. echo

echo is useful when we want to get an output of a line of text. This is very useful when creating shell scripts.

Similarly, it can also be used with > , to overwrite a text input to a file.

We can also use echo to append a line of text to a file with ».

13. touch

touch is useful for creating new files. Simply enter the file name with the extension.

Here I created a simple Python script called scripting.py using touch and added a code using echo.

14. grep

grep stands for Global Regular Expression Print. It is used for searching speicifc string or a pattern within a file OR filtering out the results from a command output.

Here I listed the content inside / directory. And I want to see only the results including "“lib”.

so I will filter the ls -l command by using what we called pipe. which redirects the output of the ls -l command through the grep command.

Note that now it’s only showing the results that include the “lib” in their name.

15. locate

This is another simple but very important command. Very useful when it comes to finding the path of a specific file/directory by going through the whole system at once.

Note that locate uses a local database to locate anything. And that database is only updated once per day. So we’ll have to use updatedb command once before using locate sometimes with new files/directories.

16. find

find is the top searching utility command that we can use to find anything we want within a specific directory. Unlike the locate command, find looks for files in real time, so there’s no need to wait for the database to be refreshed.

-name Search files using name

-type Search items using its type (For files use f, for directories use d)

17. sudo

sudo stands for Super User Do. It allows a regular non-root user (who is in the sudo group) to execute commands as the superuser (administrator). Once entered you need to enter the user’s password. This is a regular command you’ll be using in a Linux system.

18. history

history allows us to view the previously entered commands history in the terminal. This is very handy when it comes to troubleshooting.

19. man

man stands for Manual. This is used to figure out what a certain command is doing. Basically allows us to read the manual written by the devs. Simply adds man before a command name.

This example shows the manual for the rmdir command.

20. nano

nano is an easy-to-use simple text editor that comes preinstalled with many Linux distros.

Okay, so this concludes the second post in this Linux Simplified blog series. Let’s talk about user and group management in Linux in the next post!

In this post, we're diving into one of the most fundamental concepts of Linux: the Filesystem Hierarchy Standard (FHS).

Filesystem Hierarchy Standard (FHS)

If you are familiar with Windows, you might know that there are partitions named by letters (C:, D:). But Linux organizes everything into a more unified directory tree system called FHS. This tree starts with the root directory (/). Every file, every directory, every device and even the processes are represented as a file under this / directory.

Remember, everything is a file in Linux!

This may sound intimidating at first, but it’s a pretty simple system, and understanding it is really useful for understanding how things work inside IT and infrastructure in general. Because nowadays almost every system runs on Linux. Also, since this is a standard among Linux distros, no matter what Linux distro you’re in, you’ll find files in roughly the same places. This makes it much easier to learn,troubleshoot and manage Linux systems.

Why Is FHS Important?

• Quickly find files

• Troubleshoot effectively

• Correctly install packages

• Maintaining security

Here's a diagram of the tree hierarchy.

Key Directories

These specific subdirectories have their own purpose.

/ (Root Directory)

• This is the top level directory of the hierarchy, and everything belongs under this.

/root (Root User’s Home)

• Root user’s personal directory (similar to /home/username)

/bin (Binaries/Executables)

• Contains essential user command binaries like mv, cp, ls, cat.

• Always available to all users.

/sbin (System Binaries)

• Contains system binaries that are essential for managing and maintaining the system. (mounting, checking, shutting down disks...etc.)

• Important for troubleshooting.

/lib (Library Files)

• Similar to DLL files in Windows.

• These are the shared libraries and kernel modules primarily required by the essential binaries in /bin and /sbin for system boot and core functions.

• Depending on the system, you’ll find /lib32 and /lib64 directories alongside the /lib directory.

/dev (Devices)

• All the hardware devices(HDD, CD/DVD, USB..etc) are shown as files.

/mnt (Mount)

• Contains the manually mounted devices.

• Useful for system maintenance and recovery situations.

/media (Media)

• Contains the removable devices as usable files (HDD, CD/DVD, USB).

• Unlike /mnt , Linux automatically mounts these devices here.

/boot (Boot)

• Contains all the crucial system files that are required for the system booting.

• Examples:

  • initrd

  • initramfs

  • GRUB

  • grub.cfg

/etc (Editable Text Configurations)

• Contains the system-wide configurations (network,user accounts, startup scripts,service config..etc).

• These are generally static config files, not binaries.

• Use cases

  • ssh/sshd_config SSH Server Config

  • passwd User Password Config

  • fstab File System Table

/proc (Process Information)

• This is a virtual file system.

• Contains the running processes and Linux kernel parameters.

• Tools like top and ps get the information from here.

• Monitoring, debugging, and interacting with processes.

  • /proc/meminfo

  • /proc/cpuinfo

/sys (System Information)

• This is a virtual file system.

• Shows the drivers, kernel and hardware information.

• Used by the system utilities.

/usr (Unix System Resource)

• Contains the system's user programs and utilities, libraries and documentation.

• These aren’t essential for booting up/repairing the system.

• Use cases

  • /usr/bin Popular user executable programs like python, git, firefox.

  • /usr/sbin Nonessential sysadmin programs.

  • /usr/lib Libraries for /usr/bin/usr/sbin

  • /usr/local Reserved for locally installed/compiled programs (To avoid any conflicts with system-managed packages)

/var (Variable Data)

• Contains the variable data files.

• Use cases

  • /var/log System log files

  • /var/www Default location for web server files (ex: Apache)

  • /var/mail User mailbox

  • /var/tmp Temp files that are kept between reboots (Unlike /tmp)

/run (Runtime Data)

• Contains the current running data on RAM

• Starts very early in startup process

• Replacement for legacy /var/run and /var/lock

/srv (Services)

• Contains the service related files.

• Use cases

  • /srv/www Web Server (recommended by FHS instead to /var/www)

  • FTP Server

/home (User Home Directories)

• Contains the personal directories of regular (non-root) users.

• Each user has their own directory

  • /home/username1

  • /home/username2

• Usually a user’s documents, downloads, personal scripts… etc all belong here.

/opt (Optional)

• Used for optional software packages that aren’t part of the standard system.

• Most of the time used to install software by third party software vendors.

/tmp (Temporary)

• Stores the temporary data used by applications and users.

• Automatically erase all the data after a reboot.

• Writeable by everyone.

As you might understand now, this FHS provides a logical, consistent format that makes our lives easy to find configuration files, locate logs for troubleshooting, and manage the system more effectively.

Ok, so this is a wrap-up. See you in the next post where I’ll talk about the basic commands in the Linux terminal.