Search for a command to run...
Series
A Jenkins learning series covering CI/CD pipelines, automation, build jobs, plugins, integrations, and real-world DevOps workflows from basics to production concepts.
If you have been wondering what Jenkins actually does, or why DevOps engineers keep talking about CI/CD pipelines, this post is going to clear all of that up. We are going to start from the very beginning and build a solid mental model before touching a single command.
In the previous post, we covered what Jenkins is and how it fits into a CI/CD pipeline. Now it is time to get Jenkins actually running on a server. We will install it on an Amazon Linux 2 EC2 instance, access the dashboard for the first time, and create a simple job to make sure everything works.
As you get more comfortable with Jenkins and your team grows, one server handling all your builds starts to show its limits. Builds slow down, the server gets overloaded, and eventually things start failing or timing out. The solution is the Jenkins master-worker architecture (also called master-agent architecture). This post explains why it exists, how it works, and exactly how to set it up.
Building a WAR file is only half the job. The other half is getting that WAR file onto a server where it can actually run and serve users. That server, for Java web applications, is Apache Tomcat. In this post, we will set up Tomcat on a dedicated EC2 instance, configure it for Jenkins access, install the deployment plugin, and write the pipeline code to automate the entire deployment process.
After Jenkins builds your Java application and produces a WAR file, that artifact needs to go somewhere safe and retrievable. Leaving it in the Jenkins workspace is not a real option, workspaces get cleaned, servers get terminated, and builds get replaced. Every time a new build runs, the previous artifact is overwritten. This post covers two artifact storage options: AWS S3 (simple, cloud-native) and Nexus Repository Manager (enterprise-grade, self-hosted). Both integrate with Jenkins, and understanding both gives you flexibility to use whichever fits your project's needs.
Every CI/CD pipeline has a code quality gate. Without it, you are shipping code that might compile and deploy successfully but is full of bugs, security vulnerabilities, duplicated logic, and poor practices. SonarQube is the tool that fills this gap. It scans your source code, measures its quality, and reports back everything a team needs to know before approving a deployment. In this post, we will set up SonarQube on a dedicated EC2 instance, integrate it with Jenkins, and add a code quality analysis stage to our pipeline.
