Continuous integration (CI) on other hand is a process in which developers and testers collaboratively validate the new code. Traditionally, developers wrote code and integrated it once a week/month for testing purpose. That was inefficient—a mistake in code from two/four weeks ago could force the developers to revise code written one week ago. To overcome that problem, CI depends on automation to integrate and test code continuously. Scrum teams using CI commit code daily at the very least, while a majority of them commit code for every change introduced.
Is Continuous Delivery (CD) actually good for developers, or is it just one more set of expectations that gets in the way of what they really want … writing great code?
Continuous delivery (CD) is the process of continuously creating releasable artifacts.
Continuous Delivery brings a lot of improvement in software delivery process, faster with greater scale. Flip side of conitnuous delivery is it requires time, commitment and a incredible cultural/environmnet changes. At times continous delivery burdens developers with more overhead, infusing more tools and expectation to delivery faster.
Thus, CI/CD is a process for continuous development, testing, and delivery of new code.
Regardless of everything stated above CI/CD is not perfect, there are DARKEST dangers of CI/CD.
With an automated pipeline a team automatically gets continuous feedback.Especially in the beginning of setting up a pipeline, a team will get a lot of feedback information, so a team should be prepared for this. And be ready to use the feedback.