In software engineering, CI/CD or CICD generally refers to the combined practices of continuous integration and either continuous delivery or continuous deployment.
CI/CD bridges the gaps between development and operation activities and teams by enforcing automation in building, testing and deployment of applications. Modern day DevOps practices involve continuous development, continuous testing, continuous integration, continuous deployment and continuous monitoring of software applications throughout its development life cycle. The CI/CD practice or CI/CD pipeline forms the backbone of modern day DevOps operations.1
Continuous integration is a coding philosophy and set of practices that drive development teams to implement small changes and check in code to version control repositories frequently. Because most modern applications require developing code in different platforms and tools, the team needs a mechanism to integrate and validate its changes.
The technical goal of CI is to establish a consistent and automated way to build, package, and test applications. With consistency in the integration process in place, teams are more likely to commit code changes more frequently, which leads to better collaboration and software quality.2
CD 是什么
CD 可以是 Continuous Delivery 的缩写,也可以是 Continuous Deployment 的缩写。CD 是 CI 的一个扩展,这个扩展可以持续地确保快速地将软件迭代版本发布到用户。
Continuous delivery picks up where continuous integration ends. CD automates the delivery of applications to selected infrastructure environments. Most teams work with multiple environments other than the production, such as development and testing environments, and CD ensures there is an automated way to push code changes to them.2
Continuous deployment goes one step further than continuous delivery. With this practice, every change that passes all stages of your production pipeline is released to your customers. There’s no human intervention, and only a failed test will prevent a new change to be deployed to production.3
– Your team will need to write automated tests for each new feature, improvement or bug fix.
– You need a continuous integration server that can monitor the main repository and run the tests automatically for every new commits pushed.
– Developers need to merge their changes as often as possible, at least once a day.
– Less bugs get shipped to production as regressions are captured early by the automated tests.
– Building the release is easy as all integration issues have been solved early.
– Less context switching as developers are alerted as soon as they break the build and can work on fixing it before they move to another task.
– Testing costs are reduced drastically – your CI server can run hundreds of tests in the matter of seconds.
– Your QA team spend less time testing and can focus on significant improvements to the quality culture.
Continuous delivery
– You need a strong foundation in continuous integration and your test suite needs to cover enough of your codebase.
– Deployments need to be automated. The trigger is still manual but once a deployment is started there shouldn’t be a need for human intervention.
– Your team will most likely need to embrace feature flags so that incomplete features do not affect customers in production.
– The complexity of deploying software has been taken away. Your team doesn’t have to spend days preparing for a release anymore.
– You can release more often, thus accelerating the feedback loop with your customers.
– There is much less pressure on decisions for small changes, hence encouraging iterating faster.
Continuous deployment
– Your testing culture needs to be at its best. The quality of your test suite will determine the quality of your releases.
– Your documentation process will need to keep up with the pace of deployments.
– Feature flags become an inherent part of the process of releasing significant changes to make sure you can coordinate with other departments (Support, Marketing, PR…).
– You can develop faster as there’s no need to pause development for releases. Deployments pipelines are triggered automatically for every change.
– Releases are less risky and easier to fix in case of problem as you deploy small batches of changes.
– Customers see a continuous stream of improvements, and quality increases every day, instead of every month, quarter or year.