CI/CD
What is CI/CD?
CI/CD stands for Continuous integration and continuous delivery. It is a set of principles that development teams use to build, test, and release code. A lot of companies will have this as part of their software lifecycle, so it is definitely something new developers should at least be familiar with in theory, if not practice.
Continuous integration
“The technical goal of CI is to establish a consistent and automated way to build, package, and test applications” [A]. With consistency in the integration process in place, teams are more likely to commit code changes more frequently,
“Continuous integration is the practice of routinely integrating code changes into the main branch of a repository, and testing the changes, as early and often as possible”[B]. Waiting for changes to be uploaded can cause conflicts between builds, and finding a bug after several days of coding can lead to lost work. It’s a financially secure decision to bring and test changes earlier then let branches linger and diverge. If two developers need a function to do a certain task, and Dev1 made and tested that several days ago, while Dev2 needs that function also, Dev2 could possibly end up writing similar code that during merge time, may be discarded. Or the alternate scenario, Dev2 merge their changes but Dev1 has other functions that needed their version of the function now Dev1 needs to go back and change their subfunctions.
Continuous delivery.
automates the delivery of applications to selected infrastructure environments. Most teams work with multiple environments other than the production, such as development and testing environments, and CD ensures there is an automated way to push code changes to them. CD automation then performs any necessary service calls to web servers, databases, and other services that may need to be restarted or follow other procedures when applications are deployed.
Continuous delivery is the practice “where code changes are automatically built, tested, and prepared for a release to production”[C]. It follows CI by “deploying all code changes to a testing environment and/or a production environment after the build stage”. By testing the changes before deployment, downtime in a production environment can be minimized. Also by continuously delivering changes, if any errors were passed onto production, only a minimal amount of changes can potentially be rolled back upon, since errors should rear themselves up earlier.
Continuous Delivery vs. Continuous Deployment
Why Continuous Delivery and not Continuous Deployment? “The difference between continuous delivery and continuous deployment is the presence of a manual approval to update to production. With continuous deployment, production happens automatically without explicit approval.”[E] Continuous Deployment might make sense in an environment, say Netflix or Youtube, where a small piece of downtime while troublesome, will not cause problems with the customer base. Continuous Delivery with manual checking could make more sense in a scenarios where customers are more fickle, say Amazon, where a person who would want a Garlic press right now, if unable to purchase would come to their sense and say, I would never actually use that. With Continuous Delivery, if there were a scenario that tests did not account for, it is possible manual approval might think of a new test that would catch that error.
vSPARROW 