by The CI in the title stands for Continuous Integration.
Once upon a time there were two developers working on an application. Developer 1, who was called Sam, was working on a feature of the application to make it all shiny. It was called Shiny 1000. (It was extremely shiny.)
Developer 2, Jo, has been working on a super serious upgrade for the layout, due to complaints from users that they couldn’t find the unsubscribe button. Apparently they didn’t appreciate receiving daily emails about how the application was going to be super shiny in 2 months time.
After two months of hard work, Jo had created an unsubscribe button and committed the changes to the application’s github repository. All of a sudden there were warnings of merge conflicts. It looked like the unsubscribe button was totally incompatible with the updates that Sam had made to make the rest of the application super shiny. This unsubscribe button was in serious danger of never being as shiny as the other buttons.
There was a lot of effort required here as Sam had to contact Jo and work out a way to resolve the issues in the merge, so that the button could finally be Shiny 1000 certified. This impacted on their own time and the overall costs of the application. Ain’t nobody got time for that.
The solution to this issue is to implement Continuous Integration.
Continuous Integration
Instead of submitting code every two weeks, Sam and Jo can submit their changes multiple times a day. The repository can be linked to a Testing Framework, such as Github Actions or Travis CI. This testing framework can run the tests they need to ensure their code changes will not negatively impact on the application. Any failures will be reported back to the Sam or Jo straight away. The office is finally at peace.
The benefit here is that Sam can be sure the work that Jo has been doing will not stop the unsubscribe button from being super shiny, as they are working on updated code that has been tested as working. This has the nice by-product of better quality code. 🙂
Continuous Delivery/Deployment? Are They the Same?
No, there is a subtle difference between the two terms. It boils down to whether there is a manual step in the process of deploying the code changes to Production.
- Continuous Delivery
- May involve a manual approval before the successful build can be deployed to PRD.
- The deployment is still automated.
- This is useful if there needs to be a sign off before the changes can be pushed to PRD.
- Continuous Deployment
- No manual intervention or approvals required.
- Fully automated deployment to PRD, once the build process completes.
In general, the CD process ensures that the build software can be deployed when it’s needed.
In the case of Sam and Jo, the unsubscribe button finally got it’s Shiny 1000 certification, and everyone lived happily ever after.
