CI, CD AND CD
When we talk about software compilers modern and release process, often hear the phrase acronym CI and CD. CI is easy to understand, is continuous integration. But the CD can mean both sustained delivery of the code, the code can also be interpreted as a continuous deployment. There are many similar portions between CI and CD, but also very different. Here we will introduce the differences and connections between them all.
Continuous Integration (CONTINUOUS INTEGRATION)
In the continuous integration environment, developers will frequently submit code to the trunk. These new submission before the final merger into the mainline, we need to compile and automation to validate the test flow. This is done based on previous
Continuous integration process very seriously automated verification test results to ensure all submitted after the merger of the main line of quality problems, some problems may arise warning.
Continuous Delivery (CONTINUOUS DELIVERY)
Continuous Delivery is the process of speaking out our application delivery. This process can be achieved as quickly as possible to ensure that we deliver. This means that in addition to automated testing, we also need to have an automated publishing flow, and you can achieve the deployment of on-line applications from anywhere via a button.
By continuous delivery, you can decide daily, weekly, bi-weekly, which can be set according to their own business.
However, if you really want to experience the advantages of continuous delivery, we need to make a small batch published, deployed to the production line as soon as possible, in order to facilitate troubleshooting if a problem occurs.
Continuous deployment (CONTINUOUS DEPLOYMENT)
If we want a more in-depth step, then, it is the continued deployment. By this way, any amendments adopted all existing customer workflows and will meet directly. Without human intervention (no push-button deployment), modified only when a build fails to stop it deployed to the product line in the workflow.
Continuous deployment is a very good way, we can accelerate the feedback loop with customers, but will put pressure on the team, because there is no longer "release date" was. Developers can focus on building the software, they see their changes in a few minutes after they finished work on the line. Basically, when the developer submitted a merger in the main branch, the branch will be constructed, tested, and if all goes well, then deployed into the production environment.
The combined CI CD and CD?
Of course, as I said, they are closer to each part of the production environment. You can build your own continuous integration environment, and then, once the team to adapt to, you can add a continuous delivery stream, and finally, you can add flowing to the continued deployment of the entire workflow.
For example CI, CD and CD line
In the end it is worthwhile to do so?
Continuous integration:
What are the conditions you need to have:
- Your team needs for each new function, the code improvements, bug fixes or create automated test cases.
- You need a continuous integration server, it can monitor the submission of the code, automated tests for each new submission.
- Research and development team needs to submit code as soon as possible, submit at least once a day.
What can you get it? :
- You can get ahead of the results of regression testing through automated testing, to avoid some of the problems will be submitted to delivery production
- Published compilation would be easier, since the beginning of the merger will have all the problems are circumvented
- Problems switching to reduce R & D can quickly build fails to get the message, you can quickly solve a task before starting the next.
- Significantly reducing the cost of test - your CI server can run hundreds of tests in a matter of seconds.
- Your QA team to test the cost will be significantly reduced in the above time, it will be more focused on improving the quality culture above.
Continuous Delivery
What do you need? :
- You need to have a strong and sustained an integrated component of a sufficient number of test items to meet the needs of your code
- Automated deployment needs. Manual trigger, but the deployment once started, can not be human intervention.
- Your team may need to accept the switch characteristics, did not complete the function module does not affect the product line.
What can you gain? :
- No tedious deployment. Your team does not need to spend a few days to prepare a release.
- You can be delivered faster, thus accelerating the feedback loop with customers.
- Easy to deal with small change, accelerated iterative
Continuous Deployment
You need to have:
- R & D team tested the idea more perfect. Robustness testing unit directly determines the quality of your delivery.
- Your documents and deployment of frequency to be consistent.
- Signature to become an intrinsic part of publishing a major change process to make sure you can communicate with other departments (support, marketing, public relations ...) coordination.
What can be achieved? :
- Publishing frequency faster because you do not need to stop and wait for the release. Every submission will automatically trigger release stream.
- When released in small quantities, risk reduction, and found the problem can be easily fixed.
- Customers can see every day in our continuous improvement and upgrading, rather than monthly or quarterly, or annually.
As mentioned, you can use continuous integration, continuous delivery and continuous deployment. How do you depends on your needs and your business situation. If you are just starting a project, and no customers, then you can go to create these workflows, it is best to achieve these three aspects, and at the same time they iteration in your project iterations and demand growth. If you already have a production project, then you can step by step in stages to achieve them.
Original link: http: //www.ttlsa.com/news/ci-cd-cd/