Continuous Integration (CI)
Continuous
Integration using Jenkins, Nexus, Sonarqube, and Slack
Scenario:
The current situation of the SDLC is the Agile method.
Developers make regular code changes
These commits need to be Build and Tested
Usually, the Build and Release team will do this job.
Or, Developer's responsibility to merge and integrate code.
Problem:
Issues with the current situation:
In an Agile SDLC, there will be frequent code changes.
Not so frequently code will be tested so if there is a bug then it will be known later.
This accumulates bugs and errors in the code.
Developers need to rework to fix these bugs and errors.
Manual Build and Release process
Inter team dependencies
Solution:
Regular build and test for every commit
Automated Build and Release process
Whenever the build is done then the developers should notify automatically.
So that if any error is found then the developer stops the further development of the code and focuses on the bugs and errors with the current Build and Test.
This process is called as Continuous Integration Process.
Input to this process is any code commit and output is the well-tested artifact.
Now, these well-tested artifacts will be deployed to servers for further software testing (performance, load, etc). If everything is good then it can be promoted to production. It requires so many tools to connect to achieve this.
Benefits of CI
Pipeline:
- Short MTTR
- No human intervention and well work with Agile team.
- Fault detection is quick.
Tools to create sample CI Pipeline:
Jenkins: Continues integration server and main hero!
Git/GitHub: Version Control
Maven: Build tool (Eg: to build java program)
CheckStyle (out dated): Code Analysis tool
Slack: Notification
Sonatype Nexus: To store our artifact and download the dependencies for Maven. It is a software repository.
Sonarqube server: Code analysis server, scan our code in sonarqube scanner and checkstyle. Then publish our results in the Sonarqube server dashboard.
AWS EC2: To set up the Jenkin server, Nexus server, Sonarqube server, we will use AWS EC2 instances.
The architecture
of Continuous Integration Pipeline:
We have breaks at every level so if any failures then the process will automatically break and the process will not continue to the next phase.
The flow of Execution:
- Login to AWS account
- Create login Key
- Create ServiceGroup for Jenkins, Nexus, Sonarqube VMs.
- Create these 3 EC2 instances for Jenkins, Nexus, Sonarqube with user data so that automatically it will be provisioned.
- Jenkins Post-installation, need to install some plugins.
- Nexus Repository Setup, 3 repositories for Maven. It will store the dependencies. Maven will automatically download the dependencies from the Maven repository which is in Sonatype Nexus. Again we will this repository to store the software after the Artifact is included. So we use Sonatype nexus for 2 reasons, one is to download the Maven Dependencies and another one is to upload our Artifacts. We can have the version in the storing Artifacts. It is as a various version of the software to deploy.
- Sonarqube Post installation
- Jenkins Steps, Build Job, Setup Slack notification integration, Checkstyle code analysis job, Setup Sonar Integration, Sonar code analysis Job, Artifact upload job.
- Finally, connect all jobs with Build Pipeline
- Set Automatic build trigger. (Eg: if there is any code change then Jenkins will automatically detect that an entire process will run).
- Test this with our IDE (Intellij), will make code change, and commit to seeing the entire process.
- Cleanup the AWS resources (otherwise it may incur cost for you in AWS)