60 lines
3.5 KiB
Markdown
60 lines
3.5 KiB
Markdown
---
|
||
title: Continuous Integration
|
||
localeTitle: 持续集成
|
||
---
|
||
## 持续集成
|
||
|
||
在最基本的情况下，持续集成（CI）是一种敏捷开发方法，开发人员定期将代码直接合并到主源，通常是远程`master`分支。为了确保不引入重大更改，在每个可能的构建上运行完整的测试套件以对新代码进行回归测试，即测试新代码不会破坏现有的工作特性。
|
||
|
||
这种方法需要对代码库进行良好的测试覆盖，这意味着大多数（如果不是全部）代码都具有确保其功能完全正常运行的测试。理想情况下，持续集成将与完整的[测试驱动开发一起实施](https://guide.freecodecamp.org/agile/test-driven-development) 。
|
||
|
||
### 主要步骤
|
||
|
||
以下基本步骤是实现最标准的当前持续集成方法所必需的。
|
||
|
||
1. 维护一个中央回购和一个活跃的`master`分支。
|
||
|
||
必须有一个代码存储库，供每个人合并并从中提取变更。这可以在Github上或任意数量的代码存储服务上。
|
||
|
||
2. 自动化构建。
|
||
|
||
使用NPM脚本或更复杂的构建工具（如Yarn，Grunt，Webpack或[Gulp）](https://guide.freecodecamp.org/developer-tools/gulp) ，可以自动构建，以便单个命令可以构建产品的完整功能版本，随时可以在生产环境中部署。更好的是，将部署作为自动构建的一部分！
|
||
|
||
3. 使构建运行所有测试。
|
||
|
||
为了检查新代码中是否有任何内容破坏了现有功能，需要运行完整的测试套件，如果其中的任何测试失败，则构建需要失败。
|
||
|
||
4. 每个人都必须每天将变更合并到`master` 。
|
||
|
||
5. 必须构建并完全测试每个合并到`master` 。
|
||
|
||
|
||
### 最佳实践
|
||
|
||
还有一些最佳实践可以充分利用CI提供的内容及其带来的挑战，例如：
|
||
|
||
1. 保持快速构建，这样就不会浪费大量的开发人员时间来等待构建。
|
||
|
||
2. 在生产环境的完整克隆中测试构建。
|
||
|
||
|
||
例如，如果您有一个部署在Heroku或Digital Ocean之类的应用程序，那么您可以在那里部署测试版本，以确保它们不仅可以在测试中工作，而且可以在真实的生产环境中工作。此测试环境应在功能上与实际生产环境相同，以确保测试准确。
|
||
|
||
3. 让您轻松保持最新状态。
|
||
|
||
编码员应定期从`master`分支中提取，以便将代码与其团队的更改集成在一起。回购也应该提供给产品经理，公司高管或有时是关键客户等利益相关者，以便每个人都能轻松地看到进展。
|
||
|
||
4. 保留构建记录，以便每个人都可以看到任何给定构建的结果，无论是成功还是失败，以及引入新更改的人员或内容。
|
||
|
||
5. 自动部署。
|
||
|
||
|
||
在所有测试通过并且生产环境克隆中的测试部署成功后，通过在生产环境中自动部署作为构建过程的最后阶段，使您的应用程序与任何新更改保持最新。
|
||
|
||
### CI服务
|
||
|
||
存在大量服务来处理持续集成的过程，这使得建立可靠的CI管道或构建过程变得更加容易。在评估这些时，请考虑预算，构建速度以及您正在处理的项目类型等因素。一些服务，如[Travis CI](https://travis-ci.org)为开源项目提供免费服务，这可以使它们成为像这样的项目的简单选择，但它们可能比其他服务（如[Circle CI](https://circleci.com/)或[Codeship）的](https://codeship.com/)构建速度慢，仅举几例。
|
||
|
||
#### 更多信息：
|
||
|
||
关于[持续集成](https://en.wikipedia.org/wiki/Continuous_integration)的维基百科条目。 |