–> We have a git repository where we have java application source code
–> as soon as developer commit the changes we configured webhooks
–> using webhook we trigger the Jenkins pipeline
–> We have used declarative Jenkins pipelines(bcz it is easy)
–> Using declarative pipeline we ran multiple stages
–> such as, first stage is checkout stage and second stage is build stage, we used maven as our build tool
–> using maven, if the build stage is successful then we ran some unit test using JUnit .
–> Then the next stage is static code analysis, we used SonarQube for static code analysis, this helps us to identify code quality and security vulnerability
–> if any of these fail we will send notification to the development team
–> if the above steps is pass then we will go forward and create a docker image
–> we used simple shell command targets to use docker image which we store in GitHub
–> as soon as docker image created we scan the docker image using trivy for vulnerabilities
–> Then using shell command we pushed the docker image to the docker hub
CD
–> Once the images are pushed to docker hub we have Kubernetes cluster
–> inside the Kubernetes cluster we deployed 2 Continues delivery tool, one is Argo image updater and argocd (both are k8s controller which deploy in our k8s cluster)
–> Argo image updater will continuously monitor the image registry as soon as new image come it will pick the new image and will update the new image to our another git repository where we have our k8s manifests
–> Once the new image got updated, then we have another k8s controller which is argocd, it will pick the new image and will deploy it to k8s cluster
What is main branch, release branch and production branch ?
Main Branch: This is often the primary branch where the source code reflects the latest development work. It’s the default branch where most of the development happens and from which other branches are typically created. It’s sometimes called the “master” branch.
Release Branch: This branch is used to prepare for a new production release. When the development on the main branch reaches a stable state and is ready for release, a release branch is created. This branch allows for final testing, bug fixes, and minor adjustments without disrupting ongoing development on the main branch. Once the release is ready, it can be merged into both the main branch and the production branch.
Production Branch: This branch reflects the code that is currently running in production. It’s the live version of your application or project. Only thoroughly tested and approved changes should be merged into this branch to ensure stability and reliability.
Feature branch ->Main Branch (Development) -> Release Branch (Testing/Final Adjustments) -> Production Branch (Live)What is hotfix ?
A hotfix is a quick and urgent software update intended to fix a specific issue or bug, often released without going through the usual testing process. It’s applied directly to a production environment to address critical problems.
Explain the whole process of feature branch, main branch, release branch and production branch ?
In a branching strategy that includes feature, main, release, and production branches, each branch has a unique role in the development and deployment pipeline, enabling structured workflows, better collaboration, and reduced risk of production issues. Here’s how they typically work together:
- Feature Branch: Each new feature or bug fix starts in its own feature branch, usually named after the feature (e.g.,
feature-login). Developers work on this branch in isolation from others, and when complete, they create a pull request (PR) to merge it into the main branch. Jenkins or another CI/CD tool is often set up to build and test this branch, catching issues early before it affects other code. - Main Branch: This branch (often called the development or integration branch) holds code that has passed initial testing and is ready for further integration testing. Feature branches are merged here once reviewed. The main branch represents code that is stable but not yet approved for production. After merging, additional tests are run to verify that combined features don’t create conflicts. Once the code in the main branch reaches stability and readiness for release, it is branched off into a release branch.
- Release Branch: Created from the main branch when the development team decides to release a new version, the release branch (e.g.,
release-v1.0) is where final testing, bug fixing, and tweaks happen. The code in this branch is considered production-ready but requires quality assurance (QA) and staging testing. Minor issues can be fixed directly here. After passing all final tests, the release branch is merged into both the production and main branches, then tagged with the version number for reference. - Production Branch: This branch holds only code that is live in production. Merging into the production branch triggers the deployment pipeline, deploying the latest version to users. In case of issues or hotfixes required in production, hotfix branches can be created directly from the production branch, fixed, tested, and merged back into both production and main (and any open release branch if necessary) to keep all branches updated.
Feature Branches
\
Main Branch -----> Release Branch -----> Production Branch
/ /
(Ongoing Development) (Final Adjustments) (Live Deployment)My project Process
Feature Branch: we don’t have ci/cd process running for this branch, dev will test locally and marge to dev branch
DEV Branch: Developer will push there change to DEV branch the using jenkins an ArgoCD, it will deploy to kubernetes cluster to the dev Environment
Main Branch: Developer will push there change to main branch, using jenkins and ArgoCD, it will deploy to kubernetes cluster to the QA Environment : QA test
Release branch: Once the the testing is completed in QA and everything is working fine, then from release branch using jenkins and ArgoCD, it will deploy to kubernetes cluster to the Stage Environment: QA Regression test
Production Branch: Once all the testing is completed, it will move to the production branch and it will deploy to the production server using jenkins and argocd
NOTE: we used different k8s cluster for different environment
I want to create a pipeline with 10 stages and i want to skip some stage based on the requirement, how can i do that ?
We can achieve this by using conditionals in our Jenkins pipeline. Both Declarative and Scripted Pipelines support ways to conditionally skip stages.
Pipeline
pipeline {
agent any #Any means which ever machine is available it will run on that machine
#If we want to run in a specific machine the write
agent {lebel 'slave1'}
stages {
stage('Git check out') {
steps {
git branch: 'main', url: 'https://github.com/ronny4049/10-MicroService-Appliction.git'
}
}
stage('Sonarqube') {
steps {
withSonarQubeEnv('Sonarqube-conf') {
sh ''' $SCANNER_HOME/bin/sonar-scanner -Dsonar.projectKey=10-Tier -Dsonar.projectName=10-Tier -Dsonar.java.binaries=. '''
}
}
}Tools
#If we want to add any tool like java or something which is required for mvn build we can mention in tools
pipeline {
agent any
tools{
jdk 'jdk17'
maven 'maven3'
}
}Environment variable
pipeline {
agent any
envionment {
SCANNER_HOME = tool 'sonarqube' # mentioned the variable
AWS_Access_Key = credentials ('AWS_Access_Key')
}
}How to connect Jenkins to a private GitHub repository ?
- Generate a Personal Access Token in GitHub
- Add the Credential to Jenkins
- Create a New Jenkins Job and Verify
What is the difference between poll SCM and build periodically ?
- Poll SCM: Jenkins checks the source code repository at specified intervals to see if there have been any changes.
- Build periodically: Jenkins triggers a build at specified intervals, regardless of whether there have been changes in the source code repository.
Test pipeline
pipeline {
agent any
stages {
stage ('build') {
steps {
sh "mvn clean install "
}
}
stage ('test') {
steps {
sh "mvn test "
stage ('deploy') {
when {
branch 'master'
}
steps {
sh "mvn deploy"
}
}
}
post {
always{
sh "pipeline completed"
}
}
post {
success{
sh "pipeline successed"
}
}
post {
failure{
sh "pipeline failed"
}
}How can you configure a pipeline to be run manually in jenkins?
To configure a pipeline to be run manually in Jenkins, you can use the “Build with Parameters” option or the “input” step in a Jenkins pipeline (Jenkinsfile). These allow you to control when the pipeline runs, either based on user input or manual approval.
pipeline {
agent any
parameters {
booleanParam(name: 'RUN_PIPELINE', defaultValue: false, description: 'Run the pipeline manually')
}
stages {
stage('Manual Trigger Check') {
steps {
script {
if (!params.RUN_PIPELINE) {
currentBuild.result = 'ABORTED'
error("Pipeline aborted as RUN_PIPELINE is false")
}
}
}
}
stage('Build') {
steps {
echo "Building the application"
}
}
stage('Deploy') {
steps {
echo "Deploying the application"
}
}
}
}Set up a Jenkins pipeline where one pipeline depends on the completion of another
// Pipeline 1 (upstream)
pipeline {
agent any
stages {
stage('Build') {
steps {
echo 'Building...'
}
}
stage('Test') {
steps {
echo 'Testing...'
}
}
stage('Deploy') {
steps {
echo 'Deploying...'
}
}
}
post {
always {
// Trigger Pipeline 2 (downstream) after Pipeline 1 completes
build job: 'Pipeline-2'
}
}
}
// Pipeline 2 (downstream)
pipeline {
agent any
stages {
stage('Build') {
steps {
echo 'Building...'
}
}
stage('Test') {
steps {
echo 'Testing...'
}
}
stage('Deploy') {
steps {
echo 'Deploying...'
}
}
}
}What is code coverage in sonarqube ?
Code coverage in SonarQube is a metric that measures the percentage of your source code that is executed by your automated tests. It helps you understand which parts of your codebase are tested and which parts are not, providing insights into potential areas that need better test coverage
- Overall Coverage: The percentage of the entire codebase executed by tests.
- Line Coverage: The percentage of lines of code executed by tests.
- Branch Coverage: The percentage of control flow branches (e.g., if statements, loops) executed by tests
Suppose we have 2 pipeline and i want to run 2nd pipeline from 1st pipeline ??
The build step in Jenkins Pipeline is used to trigger another job (pipeline). You can include it in your first pipeline to run the second pipeline.
pipeline {
agent any
stages {
stage('Trigger Second Pipeline') {
steps {
script {
// Trigger the second pipeline
build job: 'Second-Pipeline-Name',
parameters: [
string(name: 'PARAM1', value: 'value1'), // Optional parameters
string(name: 'PARAM2', value: 'value2')
],
wait: true // Wait for the second pipeline to complete
}
}
}
}
Here it will wait for the second pipeline, once it is completed then 1st pipeline will completeHow to downgrade the installed plugin in jenkins ?
- Navigate to Plugin Manager
- Find the Installed Plugin
- Uninstall the Current Plugin
- Download the Older Plugin Version
- Manually Install the Older Plugin Version
- Go to the “Advanced” tab in the Plugin Manager.
- Under “Upload Plugin”, click on the “Choose File” button.
- Select the
.hpifile for the older version of the plugin that you downloaded. - Click “Upload” to install the older version.