How to Build a Jenkins GitOps CI/CD Pipeline

TL;DR

Separate continuous integration from continuous delivery by using Jenkins to build, test, analyze, and create the application image, while Argo CD handles Kubernetes delivery through a pull-based GitOps process. Store source code and deployment manifests in separate Git repositories, trigger Jenkins with GitHub webhooks, and configure notifications for failed builds.

Transcript

hello everyone my name is Abhishek and welcome back to my channel okay so today I am here with the ultimate cicd pipeline so last couple of days or you know from last a couple of videos actually so I have been getting this continuous request where people are asking me about Abhishek can you explain me about a real-time cicd project or you know can ... Read More

Key Insights

• Continuous integration is responsible for building the application, executing tests, maintaining code quality, and creating an image. Continuous delivery is responsible for delivering or deploying the resulting application, with Kubernetes serving as the deployment platform in the presented Java project.
• The pipeline uses two Git repositories: one stores the application source code, and the other stores deployment manifests. This separation supports a GitOps delivery model in which changes to application code and changes to deployment configuration follow distinct workflows.
• A GitHub webhook is the recommended mechanism for triggering Jenkins. Instead of requiring Jenkins to watch the repository, GitHub sends a notification to the Jenkins webhook URL when a configured event, such as a commit or pull request, occurs.
• A Jenkinsfile defines the actions that Jenkins performs during continuous integration. For the Java application, those actions include building with Maven, running unit tests, performing static code analysis, integrating scanning tools, and moving forward only when required stages succeed.
• Docker agents can provide the tools needed by individual Jenkins stages. Using available Docker images reduces the need to install and configure every build dependency directly in Jenkins, although plugins and tools can also be configured through Jenkins system settings.
• Pipeline failures should generate notifications for the responsible team. Jenkins can use an email plugin, Slack APIs, or AWS email notifications, allowing failed build stages to be reported instead of silently stopping the integration process.
• Argo CD handles continuous delivery through a pull-based GitOps mechanism. Jenkins finishes its responsibility after the continuous integration portion, and it does not directly trigger the delivery process in the architecture described by the presenter.
• The project combines Jenkins, Maven, SonarQube, Docker, Argo CD, Helm, and Kubernetes in an end-to-end workflow. The accompanying Jenkins Zero to Hero repository contains setup details, required plugins, communication between tools, diagrams, and a step-by-step implementation reference.

Questions & Answers

Q: How does the Jenkins CI/CD pipeline work end to end?

The workflow starts when a developer changes Java code in the source repository. GitHub notifies Jenkins through a webhook, and Jenkins executes stages defined in a Jenkinsfile. Maven builds the application and runs unit tests, followed by static code analysis and scanning. Jenkins also creates the application image. Continuous delivery is separated from Jenkins and handled through Argo CD, deployment manifests, Helm, and Kubernetes.

Q: Why does the project use two Git repositories?

The project uses one Git repository for application source code and another for deployment manifests. The source repository participates in the Jenkins continuous integration workflow, while the manifest repository supports the GitOps delivery process. This structure separates application building and testing from Kubernetes delivery, allowing Argo CD to pull the desired deployment configuration without Jenkins directly triggering the continuous delivery process.

Q: How should GitHub trigger a Jenkins pipeline?

GitHub should trigger Jenkins through a webhook configured in the repository settings. The Jenkins webhook URL is added to GitHub, along with the events that should send notifications. These events can include commits, pull requests, or issues. When a selected event occurs, GitHub sends a notification to Jenkins and asks it to start the pipeline, so Jenkins does not need to keep watching the repository.

Q: What does Jenkins handle in the CI portion of the pipeline?

Jenkins handles the continuous integration stages described in the Jenkinsfile. For the Java application, Maven builds the code and executes unit tests. The workflow then performs static code analysis and integrates tools such as SonarQube for further checking. Jenkins can create the Docker image after successful checks. Each stage depends on the required earlier stages succeeding before the pipeline moves forward.

Q: How can Docker agents simplify Jenkins pipeline stages?

Docker agents allow individual Jenkins stages to use Docker images that already contain the required tools. This approach can avoid installing and configuring each dependency directly on Jenkins. The alternative described is to configure tools such as Maven through Jenkins system settings and plugins. Docker agents therefore provide another way to supply consistent stage-specific tooling for build, test, analysis, and related pipeline operations.

Q: What happens when a Jenkins build stage fails?

When a build stage fails, the pipeline can send alerts instead of continuing to later stages. Jenkins supports email notifications through an email plugin, and teams can also configure Slack notifications through APIs. The presenter additionally mentions AWS email notifications as an option. These alerts inform the responsible people that the build went south, while successful execution allows the pipeline to proceed to the next stage.

Q: How does Argo CD fit into the continuous delivery process?

Argo CD provides the continuous delivery portion of the architecture through a pull-based GitOps model. Jenkins performs continuous integration and ends its work before delivery begins. There is no direct Jenkins trigger attached to the Argo CD process in the presented design. Instead, deployment information is maintained in the manifest repository, and Argo CD uses the declarative delivery approach to support deployment to Kubernetes.

Q: How should this Jenkins project be explained in a DevOps interview?

Explain the complete flow and the responsibility of each tool. Start with a developer commit or pull request, then describe how a GitHub webhook triggers Jenkins. Cover the Jenkinsfile, Maven build, unit tests, static analysis, SonarQube checks, Docker image creation, and failure notifications. Finally, explain that Jenkins handles integration while Argo CD, the manifest repository, Helm, and Kubernetes support the separate GitOps delivery process.

Summary & Key Takeaways

• The pipeline begins when a developer commits code or creates a pull request in the source repository. A GitHub webhook notifies Jenkins, avoiding the need for Jenkins to continuously watch the repository. The webhook can be configured in GitHub settings for events such as commits, pull requests, or issues.

• Jenkins performs the continuous integration work through stages defined in a Jenkinsfile. For the Java application, Maven builds the code and runs unit tests. Static code analysis and SonarQube scanning provide additional quality checks. Later stages proceed only after earlier checks succeed, while failures can trigger email, Slack, or AWS notifications.

• Continuous delivery is separated from the Jenkins pipeline through a GitOps design. Application source and Kubernetes manifests reside in different Git repositories. Jenkins completes the integration process, while Argo CD uses a pull mechanism for delivery to Kubernetes. The project also references Docker images, image updating, Helm, and Kubernetes deployment configuration.