In this blog, we’ll explain about Continuous Integration and Continuous Delivery. we’ll also tell you the use of Continuous Integration (CI).
Continuous Integration and Continuous Delivery
What is Continuous Integration ?
It is the practice of merging development working copies (i.e. builds that are in flight on a development system or systems) with the shared source main (branch) multiple times per day. In simple, we can define Continuous Integration is a practice that requires developers to integrate code into a shared repository server times a day.
The concept of multiple integrations per day on the main source branch is to prevent integration problems in large development teams where the odds of one change breaking the changes of another developer would be smaller.
Continuous Integration works hand-in-hand with the previously discussed Build Automation. It takes advantage of those automated build processes to build and test each commit and reporting those results back to the development teams.
So we are looking into Continuous Integration it mainly deals with the development process and the process how you handle source code and how often that code merges to the main development branch, it is really designed to simplify large complex projects with large teams working on them because the more often you integrate and more often everyone gets the updated main branch push to the system whatever they are doing is less likely to conflict with the someone else may be working on.
What is Continuous Delivery?
This is an approach in which software teams keep producing valuable software in very short delivery cycles and ensure that those features can be reliably and consistently released at any point in time.
It is often mistakenly used interchangeably with the continuous integration approach. Whereas CI has more to do with how the software code is managed throughout the development lifecycle, the CD is how valuable and how quickly that software can be released when it is determined that the aggregate features are valuable enough.
Continuous Delivery is the capability to do automated deployments.
Why we use Continuous Integration (CI) ?
- It makes the process much simple
- CI can help you keep tabs on the health of your codebase
- Automatically monitoring code quality
- Automatically monitoring code coverage metrics
- Keep technical debt down
- It also helps to keep maintenance costs low
- You can also automate the approval process
Compare Traditional Approach vs Jenkins
Traditional Approach:
- In the Traditional approach, everything is down manually
- A developer checks-in the code, build and compile the code
- Once the compilation is done, developer as to reach for approvals
- once approvals are received request is submitted to respective teams for deployment
- Lastly, the testing team is involved in testing the application
Jenkins Approach:
- These same process can be implemented in Jenkins as follows:
- Once developer check-in the code Jenkins come into play
- Jenkins automatically checks the code and compiles it
- A code analysis tool is run over the compiled code and report is sent to the respective manager with auto lead for approval
- Once approved the application get deployed and unit test cases are executed on the latest deployment
- So this makes the whole process easy and automated
This is the End of the tutorial, Continuous Integration and Continuous Delivery.
Read this also:
