Source Episteme:
Continuous Integration :
Continuous integration (CI) is a software engineering practice in which isolated changes are immediately tested and reported on when they are added to a larger code base. The goal of CI is to provide rapid feedback so that if a defect is introduced into the code base, it can be identified and corrected as soon as possible. Continuous integration software tools can be used to automate the testing and build a document trail. It is the practice of merging development work with a Master/Trunk/Mainline branch constantly so that you can test changes, and test that changes work with other changes. The idea here is to test your code as often as possible to catch issues early. Most of the work is done by automated tests, and this technique requires a unit test framework. Typically there is a build server performing these tests, so developers can continue working while tests are being performed.
Continuous Delivery :
Continuous Delivery is the continual delivery of code to an environment once the developer feels the code is ready to ship. This could be UAT or Staging or could be Production. But the idea is you are delivering code to a user base, whether it be QA or customers for continual review and inspection. This is similar to Continuous Integration, but it can feed business logic tests. Unit tests cannot catch all business logic, particularly design issues, so this stage or process can be used for these needs. You may also be delivering code for Code Review. Code may be batched for release or not after the UAT or QA is done. The basis of Continuous Delivery is small batches of work continually fed to the next step will be consumed more easily and find more issues early on. This system is easier for the developer because issues are presented to the developer before the task has left their memory.
Continuous Delivery can help large organizations become as lean, agile and innovative as startups. Through reliable, low-risk releases, Continuous Delivery makes it possible to continuously adapt software in line with user feedback, shifts in the market and changes to business strategy. Test, support, development and operations work together as one delivery team to automate and streamline the build, test and release process. Continuous Delivery is the natural extension of Continuous Integration: an approach in which teams ensure that every change to the system is releasable, and that we can release any version at the push of a button.
Continuous Delivery can help large organizations become as lean, agile and innovative as startups. Through reliable, low-risk releases, Continuous Delivery makes it possible to continuously adapt software in line with user feedback, shifts in the market and changes to business strategy. Test, support, development and operations work together as one delivery team to automate and streamline the build, test and release process. Continuous Delivery is the natural extension of Continuous Integration: an approach in which teams ensure that every change to the system is releasable, and that we can release any version at the push of a button.
Continuous Deployment :
Continuous Deployment is the deployment or release of code to Production as soon as it is ready. There is no large batching in Staging nor long UAT process that is directly before Production. Any testing is done prior to merging to the Mainline branch and is performed on Production-like environments, see Integration blog article for more information. The Production branch is always stable and ready to be deployed by an automated process. The automated process is key because it should be able to be performed by anyone in a matter of minutes (preferably by the press of a button). After a deploy, logs must be inspected to determine if your key metrics are affected, positively or negatively. Some of these metrics may include revenue, user sign-up, response time or traffic, preferably these metrics are graphed for easy consumption. Continuous Deployment requires Continuous Integration and Continuous Delivery – otherwise you will get errors in the release.
Once you have moved to a Continuous Deployment process, you will have to have several pieces of automation in place. You must automate your Continuous Integration Build Server and Continuous Delivery to Staging, as well as have the ability to automatically deploy to Production.
In the ideal workflow, the entire process could be automated from start to finish: Developer checks in code to development branch, Continuous Integration Server picks up the change, performs Unit Tests, votes on the Merge to Staging environment based on test results, if successful deploys it to Staging Environment, QA tests the Environment, if passed, they vote to move to Production, Continuous Integration server picks this up again and determines if it is ok to merge into Production, if successful, it will deploy to Production environment. This process varies slightly based on needs, requirements and approaches.
Continuous Deployment relies on small changes which are constantly tested and that are deployed and released to Production immediately upon verification. The ownership of the code from development to release must be controlled by the developer and must be free flowing. The automation of steps allows this process to be implemented and executed without cumbersome workflows.
Continuous Deployment relies on small changes which are constantly tested and that are deployed and released to Production immediately upon verification. The ownership of the code from development to release must be controlled by the developer and must be free flowing. The automation of steps allows this process to be implemented and executed without cumbersome workflows.
