CICD 的思考
CICD(Continuous Integration, Continuous Delivery)，作为工程人员大家都一致认可 CICD 的重要性，由于 CICD 的涉及面太过广泛，每个工程人员对 CICD 的第一反应都是不尽相同的。在设计 CICD 框架之初，希望可以对 CICD 有一个比较全面而结构化的认识，基于这样的认识进行 CICD 的思考和设计。
CICD 是什么
下面是引用自 Wikipedia 对于 CICD 的解释：
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
CICD 存在于软件工程实践中，它的目的是帮助开发团队更快、更可靠地发布软件迭代，从 DevOps 或者敏捷开发的角度来讲，CICD 是最佳实践，这个毋庸置疑的。从Wikipedia的解释中可以看出软件的生命周期包括：
- continuous development
- continuous testing
- continuous integration
- continuous deployment
- continuous monitoring
RedHat对上述软件生命周期进行了按时序归类，如下图所示。
CI 是什么
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
Continuous Delivery 和 Continuous Deployment 的区别如下图所示。
Continuous Delivery V.S. Continuous DeploymentGain V.S. Cost
CI,CD 的分析表格如下所示3。
| Subject | Cost | Gain |
|---|---|---|
| Continuous integration | – 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. |
对比下来 Continuous Deployment 是一个比较理想的状态，对像蚂蚁这样的复杂基础设施架构的公司来讲，CICD 的投入会非常巨大，所以暂且以 Continuous Delivery 作为CICD的目标。
CICD 通用框架
通过对 CICD 的通盘了解和分析，无论是 CI 还是 CD 它的最终目的都是:
“establish a consistent and automated way to build, package, and test applications.”。
归纳一下 CICD 关键字包括 consistent, automated, build, package, test：
- consistent: 一致的代码仓库、一致的测试环境、一致的发布规则
- automated: 自动化
- build: 构建
- package: release二进制
- test: UT, AT, ST
对 CICD 的理解
经过上述的分析，我认为 CICD 就是一个自动化的 pipeline，该流水线帮助软件开发从代码提交开始就进行构建、测试、release等整个流程。
鉴于蚂蚁基础设施以及开发环境的特殊性，对 CICD 的细节做了一些调整：
- 由于生产环境的稳定性的考量，自动化的部署到生产环境（ CD 的目标之一）当前不做考虑；
- pipeline 原则上应该是以 commit 为粒度来触发整个自动化流程，考虑蚂蚁开发的 collaboration 都是以 PR(Pull Request)/MR(Merge Request) 为基本单元，所以从效率的角度，pipeline 修改为以 PR/MR 为粒度进行快速迭代；
CICD 通用框架
通用的 CICD pipeline 如下图所示。
通用 CICD 框架
