模板
教程
环境
性能
功能
管理
不可错过的持续集成进阶指南(2)
发表于：2016-10-28来源：flow.ci作者：flow.ci点击数：
标签：持续集成
这时候需要改进你的 CI 系统，建立标准化的环境部署顺序，在 Workflow 中增加部署预生产环境并进行灰度集成测试的流程，做好线上环境部署后的 回归 测
这时候需要改进你的 CI 系统，建立标准化的环境部署顺序，在 Workflow 中增加部署预生产环境并进行灰度集成测试的流程，做好线上环境部署后的回归测试。到这里，已经真正做到了持续交付。
持续交付并不是指软件每一个改动都要尽快部署到产品环境中，它指的是任何的代码修改都可以在任何时候实施部署。而“持续部署”，即自动部署到生产环境中而无需手工干预：得到一个版本后，自动部署该版本到生产环境中。实践证明，相对独立快速地部署新功能是一个核心竞争力，可以减轻大规模功能变更的风险。
持续部署，是相对成熟的持续集成系统。
“开发人员提交代码，持续集成服务器获取代码，执行单元测试，根据测试结果决定是否部署到预演环境，如果成功部署到预演环境，进行整体验收测试，如果测试通过，自动部署到产品环境，全程自动化高效运转。”
第四进阶 — 并行多 workflow 集成以及个性化集成，基于 Docker 的持续集成
随着项目和团队规模增长，模块之间依赖关系变得复杂，如何确保代码质量的同时，保证代码构建的一致性和稳定性，成为一大挑战。Docker 可以方便地以“容器化”的方式部署，它就像集装箱一样，打包了所有依赖，在其他服务器上部署很容易，不至于换服务器后发现各种配置文件散落一地，这样就解决了编译时依赖和运行时依赖的问题。
还有一个问题，开发的分支越来越多，每个活跃分支都进行环境部署和集成测试，对持续集成环境的维护成本也就越高。而 Docker 的快速启动和镜像仓库是天生为 CI/CD 设计的，以前启动一个虚拟机需要几分钟，而启动 Docker 只需要几秒钟，让并行的持续集成才能成为可能。
目前，比较常见的基于 Docker 进行持续集成的流程如下：
-
开发者提交代码；
原文转自：http://blog.flow.ci/ci_advancedguide/
