Continuous Integration, Continuous Delivery and Continuous Deployment - ilya-khadykin/notes-outdated GitHub Wiki

TO DO:

Continuous Integration is a software development practice in which developers should commit their changes to a master branch at least daily (changes should be relatively small and frequent). This approach solves a merge problem in the end of development cycle. It also guaranties that the team always has a working version of developed software in a master branch. Key Ingredients needed for CI:

  • Local workspace
  • Source code repository
  • Automated build
  • Interrogation environment
  • Teamwork

Continuous Delivery is a software development practice witch extends a use of Continuous Integration (CI) by automatic deployment of the last working version of developed software to a required environment. Additional settings may include running automated tests before deployment, schedule deployment time etc. Production deployment is triggered manually.

Continuous Deployment extends the practice of continuous delivery by automating production deployment meaning that Deployment to Production is triggered automatically.

All three mentioned practices require Integration Server like Jenkins.

Continuous Delivery/Integration/Deployment

For those not familiar with Continuous Delivery/Integration/Deployment these are all actually quite different concepts. Here are some quick and simple definitions from Wikipedia:

  • Continuous Delivery: a software engineering approach in which teams keep producing valuable software in short cycles and ensure that the software can be reliably released at any time. It is used in software development to automate and improve the process of software delivery.
  • Continuous Integration: the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day.
  • Continuous Deployment is actually redirected to Continuous Delivery on Wikipedia, but you they are actually different concepts. While continuous delivery is about whether software can be released at any time, continuous deployment is about the deployment process being totally automated (whether it happens automatically, or at a push of a button is irrelevant).

Continuous Delivery Providers in 2016

Logo CD Provider Overview
Travis CI Free for Open Source; "You basically have a single YML file that you use to tell travis about your environment, integrations, and what scripts to run and that’s it."
Codeship "I very much like codeship’s UI and separation between setup, testing, and deployment. This makes it easier and more obvious what goes where."
CircleCI "After trying Codeship, I wasn’t shocked or impressed with CircleCI. It looks like it’s quite comperable and would be a good CI service. But I didn’t really see much of anything by way of differentiating features that CircleCI gave me"
Wercker "Wercker wins the prize for the most appealing UI. Very smooth and sensible animations. the one thing that stopped me from going any further was it didn’t just work with firing up Chrome or Firefox with karma to run my unit tests like Codeship or CircleCI ..."
Snap "What Snap offers that other providers simply don’t is the idea of a pipeline with stages. Each stage is in a totally isolated environment from other stages (though you can share artifacts of stages as well as common commands between stages)"

References