不可错过的持续集成进阶指南

随着软件部署的越来越成熟，敏捷、DevOps和CI/CD，Docker等词语慢慢出现在工程师的视野中。对于持续集成，业界也没有一个通用的模式，每个团队可能习惯的方式和关注点都不一样。而持续集成的关键在于「持续」与「自动化」。这篇文章根据这两个关键点，将 CI 系统分为四个进阶过程，来看看你们团队处在哪个阶段。

第一进阶 — 代码级别的集成，这是最初的持续集成

在最初的持续集成过程中，不依赖独立的持续集成工具，一般语言的 build 工具基本内置，比如 java 的maven/gradle/ant/ivy，c/c++ 的make /premake，同时也会加入代码风格检查，静态代码分析，单元测试调用，测试覆盖率检查等增强功能。接下来的交付准备环境、运行测试、备份旧版本、新版本打标签以及反馈机制等其他重复的事情全由手工完成 ，会花费很多时间。

第二进阶 — 集成 workflow，基本实现了真正的持续集成

单一的编译-构建工具逐渐地不能满足产品快速交付的需求。

整个开发流程的重心从「代码级别的集成」转移到了 更自动化地编译 和 更完美的测试验证 ，致力于在最短的时间内发现问题，缩短开发周期，提高软件质量。比较常见的一个场景，某个团队先进行代码 Build，触发单元测试、集成测试，打包测试完毕后再自动部署到测试环境，循环往复，形成编译 - 构建 - 测试 - 集成 - 部署到测试环境的集成 Workflow 。

flow.ci 是融入了 workflow 机制的持续集成（CI）服务，也可以理解为自动化流程平台，除了集成代码、编译、测试之外，还可以集成常用的工具、灵活自定义流程，帮助你们塑造一个更优秀智能的持续集成系统。

第三进阶 — 持续交付与部署，相对成熟的持续集成系统

在上个进阶中，产品是自动部署在测试环境，手动部署在生产环境。之所以这样选择，是因为产品在从需求到部署的过程中，会经历若干种不同的环境，例如 QA 环境、各种自动化测试运行环境、生产环境等。这些环境的搭建、配置、管理，在不同环境中的具体部署是比较复杂的。经常会遇到这么一种场景：明明在测试环境已经部署成功，但线上环境又出现部署故障。这种情况很可能是生产环境和测试环境的异构造成的。

原文转自：http://blog.flow.ci/ci_advancedguide/