53 lines
2.1 KiB
Markdown
53 lines
2.1 KiB
Markdown
CI:持续集成
|
||
CD:持续交付,持续部署
|
||
|
||
## 持续集成
|
||
```
|
||
持续集成可以使问题尽早暴露，从而也降低了解决问题的难度，正如老马所说，持续集成无法消除bug，但却能大大降低修复的难度和时间。
|
||
|
||
如何做到持续集成？
|
||
首先，持续集成需要：
|
||
|
||
1. 单一的代码仓库，团队成员都像该仓库提交代码；
|
||
|
||
2. 自动化构建且构建过程需要包含自动化测试；
|
||
|
||
3. 有单独的集成机器用于构建；
|
||
|
||
4. 保证构建速度不要太慢（曾经有一个项目构建需要20分钟，就会很痛苦）；
|
||
|
||
5. 在类产品环境进行测试；
|
||
|
||
6. 能够方便获取最新的可执行程序；
|
||
|
||
7. 可视化，大家都能看到构建过程及结果；
|
||
|
||
8. 自动化部署。
|
||
|
||
其次，我们通过以下步骤进行持续集成：
|
||
|
||
1. 程序员将代码下载到本地，并在完成修改后提交代码；
|
||
|
||
2. CI服务器监测代码库，并在有提交时自动触发；
|
||
|
||
3. CI服务器对代码进行构建，运行单元测试和集成测试；
|
||
|
||
4. CI服务器发布可部署的artefact用于后续测试，并加上本次构建版本的标签。
|
||
|
||
5. CI服务器通知团队构建成功或者失败；失败发生时团队需要尽快修复，以免耽搁后续的持续集成过程，因为失败时处于持续集成的暂停阶段。
|
||
|
||
最后，需要就团队责任达成共识：
|
||
|
||
1. 频繁提交；
|
||
|
||
2. 提交之前确保测试通过；
|
||
|
||
3. 不在持续集成失败时提交代码；
|
||
|
||
4. 提交代码后保证持续集成成功，不然不准回家
|
||
|
||
```
|
||
## 持续交付
|
||
```
|
||
持续交付是持续集成的扩展，指的是将通过自动化测试的软件部署到产品环境。持续交付的本质是把每个构建成功的应用更新交付给用户使用。在持续交付的世界里，我们对完成的定义不是测试完成，而是交付到客户手中。这里需要注意的是，CD代表持续交付（Continuous Delivery）而不是持续部署（Continuous Deploy），因为部署也包括部署到测试环境，而持续交付代表的是功能的上线，交付给用户使用
|
||
```
|