Continuous Integration
Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.
By integrating regularly, you can detect errors quickly, and locate them more easily.
The CI part of CICD can be summarized with: you want all parts of what goes into making your application go to the same place and run through the same processes with results published to an easy to access place.
The simplest example of continuous integration is something you might not have even thought of being significant: committing all your application code in a single repository! While that may seem like a no-brainer, having a single place where you “integrate” all your code is the foundation for extending other, more advanced practices.
Once you have all your code and changes going to the same place, you can run some processes on that repository every time something changes.
This could include:
- Run automatic code quality scans on it and generate a report of how well your latest changes adhere to good coding practices
- Build the code and run any automated tests that you might have written to make sure your changes didn’t break any functionality
- Generate and publish a test coverage report to get an idea of how thorough your automated tests are
These simple additions allows you, the developer, to focus on writing the code. Your central repository of code is there to receive your changes while your automated processes can build, test, and scan your code while providing reports.
Developers generally use a tool called the CI Server to do the building and the integration for them.
With the entire team getting instant reports about integration failures, it is easier to iron out mistakes that are causing such issues.
Continuous Delivery
Continuous delivery, as the name suggests, picks up from where continuous integration ends. While CI establishes a consistent integration process, CD automates the delivery of applications so that new iterations can reach the end-consumers more quickly.
This practice allows developers to accelerate their time to market, allowing an opportunity to elicit user feedback more quickly. A hallmark of continuous delivery is that your code is not directly released to production which means that software developers have the chance to conduct manual tests in a staging environment.
Deploying code can be hard. If you’ve ever been jamming on building a project for a while, shifting your mindset to getting it ready to be deployed can be jarring.
One of the best things you can do to avoid this, much like other things in software, is to automate it! Make it so that your code gets automatically deployed to wherever you or your users can get to it.
Continuous Delivery means that each time there are changes to the code:
- Integrate
- Build
- Test
- Deploy
Tip
A well-tested CI/CD pipeline can greatly assist organizations in automating the delivery process for their software — all the way from starting code builds to deploying the code in an environment.
Continuous Delivery vs. Continuous Deployment
Continuous delivery dictates that every code change that is validated through automated tests must pass through the developer for manual tests.
Twitter: @ccaum
Continuous Delivery doesn'n mean every change is deployed to production ASAP. It means every changes is proven to be deployable at any time.
In contrast, continuous deployment bypasses the ‘check with developer’ stage and releases every accepted change right into production. This usually symbolizes a robust software development pipeline that requires a minimal manual.
Continuous Deployment
Continuous deployment is in turn an extension of the continuous delivery idea. In the previous step, we had all the processes automated, together with release. However, deploying an application to production environment needed our intervention. Here, having continuous deployment, that manual step is replaced with an automatic step.
It means that when we commit any change to a repository, it automatically appears on production. The only thing that can withhold the whole process is a failed test. Only in this case the whole pipeline is stopped and the change doesn’t appear on production.
Summary
Pros and costs
The main advantages of the CI/CD approach are:
- fewer bugs on production
- programmers can work more efficiently as they don’t have to go back to the code and remind themselves the context to fix the bug — they are informed about a bug almost immediately
- complexity of the deployment process falls into oblivion, team members don’t have to spend additional time to prepare for release
- frequent release means quicker feedback from our clients
- greater clients’ satisfaction as they are often updated on progress
Unfortunately, as usually, these solutions are not free from costs for the organization, such as:
- necessity to write automated tests for each, even the slightest, change
- being aware that test quality impacts directly the quality of final release
- programmers need to be disciplined as they need to merge their code into the main branch as frequently as possible
- necessity to introduce additional mechanisms so that the unfinished functionalities don’t affect application performance
Read more