A CI/CD pipeline on Jenkins to automate parts of the SDLC of a simple maven project
Why CI/CD?
The above is the dev-ops life cycle. The build-test-release-deploy parts of the cycle are automated using this CI/CD pipeline. Any commits made in GitHub is quickly built, unit tested, integration tested, static code analyzed and deployed if all the above pass succesfully. This is useful to avoid merge hell and quickly deploy reliable code to stakeholders to uphold agile iterations. Complex CI/CD pipelines are used in the industry to make sure only high quality code passes through and that all deployed code is tested properly.
Features and Concepts:
AWS ec2 instances for the jenkins, sonarqube and nexus deployment:
The CI/CD pipeline will start on the jenkins ec2 instance that contains apache maven and jdk to build a simple java project.
The sonarqube instance will handle the static code analysis and the nexus instance can be thought of as the deployment server which contains releases.
The pipeline's first stage is the build stage
In the build stage, we pull the code from the SCM (in this case GitHub)
The next step in the build stage is to build the java project using maven and compile it into a artefact file. This node is configured to automatically start the pipeline if there is a new commit to the GitHub repo; It will also start the pipeline every 5 hours everyday.
Unit testing & integration testing These nodes are essential before trying to deploy to the nexus repo. In an industry setting, we want to avoid technical debt. This is basically a small bug that when left unfixed, may grow to become a larger issue later on in the life cycle due to other integration. Thus, any code should be unit tested before deployment.
Static code analysis using SonarQube Scanner
The above is the dashboard lauched on the sonarqube ec2 instance. This provides a brief overview of code quality, bugs and static checks.
THe above is a more comprehensive view. Developers will be able to easily view bugs and other errors quickly. Moreover, the ocmpany can set the standard of deployed code. This is done by configuring quality gates. These quality gates will only allow deployment to happen if certain standards are met
This is the release repository where succesful builds in the pipeline end up in. This instance is hosted on a seperate ec2 machine from the jenkins ec2.