In the context of software process continuity, It refers to the practice of continuously updating the code changes with the mainline or the VCS aka version control system so that all the development changes can be tested and the interoperability of the tested change with other software modules can be verified.The objective of continuous integration is to catch bugs/issues in the software development process as early as possible. Hence, the testing process is underway as often as possible. Under continuous integration, it is a good practice to have a build server to merge all the incoming changes and execute all the tests in a parallel fashion.
Continuous delivery is the next step after continuous integration. To be precise, continuous delivery is an advancement of continuous integration. It refers to the continuous delivery of code changes/development changes to an environment (QA, UAT, Staging) when the developer is confident that his/her code is ready for release.Another major difference between continuous integration and continuous delivery is that in CD one can feed even the business logic tests whereas CI is limited to Unit and Integration Testing. In addition, Continuous Delivery the code can also be scheduled for code review until User Acceptance Testing and Quality Assurance is performed.The underlying idea behind continuous delivery is to feed small fragments of the work to the next step. As a result of this, issues with the business logic can be visible easily at an early stage. Moreover, the developers are more comfortable, as any issues with the code are highlighted before it has been passed on to the next step.
The continuous delivery approach addresses the following concerns: –
The new changes/additions will work in a production-like environment or not.
The additions/modification to the code will install/integrate with other code modules correctly or not.
Continuous Deployment and Continuous Delivery are 2 terms which are in use interchangeably. Continuous Deployment is an evolution of the Continuous Delivery paradigm. There is a slight difference between the two. Unlike Continuous Delivery in Continuous Deployment, the code is not in form of batches or queues for a long UAT Procedure.The objective here is to release the code to production as soon as possible. The testing is in-process before the code is ready for merging into the mainline branch on the VCS. Also, this testing procedure is automatic and involves production-like environments. As a result, the mainline branch always remains stable and is ready to for deployment by an automated process.The automation aspect is important here. Anybody should be able to deploy the final code with great ease (as simple as pressing a button). Furthermore, the Continuous Deployment process encapsulates Continuous Integration and Continuous Deployment. This is essential as, without the two aforementioned paradigms, the possibility of running into errors may increase.
During Continuous Deployment several process and procedures need to be automated. This includes: –
Automation of Continuous Integration build server
Automation of Continuous Delivery to staging
Automation of deployment process to production
The Developer needs to take charge of the code right from development to release.
A QUICK OVERVIEW
The above diagram illustrates all the 3 paradigms essential for maintaining continuity of development operations.
Continuous Integration => Build and Unit Test Code Changes as soon as the developer checks it in
Continuous Deployment => Continuous Integration + Automated Testing + Automated Deployment Process to Production
These 3 processes definitely add-on to the costs of the project, but they also provide benefits that make things easy to manage. They facilitate collaboration among developers. The automation aspect reduces the time spent in testing and deployment procedures.
For custom software applications, mobile apps and design services, Reach Us