Continuous Integration (CI) vs Continuous Delivery (CD)
Continuous delivery (CD or CDE) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time and, when releasing the software, doing so manually.[1][2] It aims at building, testing, and releasing software with greater speed and frequency. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.
DevOps has a broader scope than CD:
-
the collaboration of the various teams involved in software delivery (developers, operations, quality assurance, management, etc.)
-
automating the processes in software delivery
Continuous Delivery is the ability to deliver the software at any time through manual release.
Continuous Deployment is the ability to deliver the software at any time through automatic release. Continuous Deployment requires continuous delivery .
https://en.wikipedia.org/wiki/Continuous_delivery
The purpose of the deployment pipeline has three components: visibility, feedback, and continually deploy:
- Visibility
All aspects of the delivery system including building, deploying, testing, and releasing are visible to every member of the team to promote collaboration.
- Feedback
Team members learn of problems as soon as possible when they occur so that they are able to fix them as quickly as possible.
- Continually deploy
Through a fully automated process, you can deploy and release any version of the software to any environment.
In software engineering, continuous integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day .
A complementary practice to CI is that before submitting work, each programmer must do a complete build and run (and pass) all unit tests. Integration tests are usually run automatically on a CI server when it detects a new commit.
- Maintain a code repository
Use of a revision control system for the project’s source code. Try to maintain one branch / minimize the number of branches.
- Automate the build
A single command to build the system. Automation of the build should include automating the integration, which often includes deployment into a production-like environment.
- Make the build self-testing
Once the code is built, all tests should run to confirm that it behaves as the developers expect it to behave.
- Everyone commits to the baseline every day
By committing regularly, every committer can reduce the number of conflicting changes.
- Every commit (to baseline) should be built
The system should build commits to the current working version to verify that they integrate correctly. A common practice is to use Automated Continuous Integration, although this may be done manually. Automated Continuous Integration employs a continuous integration server or daemon to monitor the revision control system for changes, then automatically run the build process.
- Keep the build fast
The build needs to complete rapidly, so that if there is a problem with integration, it is quickly identified.
- Test in a clone of the production environment
Try as soon as possible to have an exact replicate of the production environment instead of having a different test environment completely different.
- Make it easy to get the latest deliverables
Making builds readily available to testers can reduce the amount of rework. Additionally, early testing reduces the chances that defects survive until deployment.
- Everyone can see the results of the latest build
It should be easy to find out whether the build breaks and, if so, who made the relevant change and what that change was.
- Automate deployment
Write a script to deploy the application to a live test server that everyone can look at.
https://en.wikipedia.org/wiki/Continuous_integration
