部署持续代码

持续集成、持续交付、持续部署的区别与关系

持续集成尽可能快的把不同开发人员修改的代码集成到一起，通常一天进行多次需要结合自动化单元测试，每次集成都运行...

持续集成

尽可能快的把不同开发人员修改的代码集成到一起，通常一天进行多次

需要结合自动化单元测试，每次集成都运行一整套单元测试

目标是尽快发现代码问题

持续交付

持续的把改动的代码交给预演环境，接受QA检查，确保此套代码是可以随时部署的

持续交付比持续集成更进一步，持续集成是代码层面的测试，持续交付不仅把代码集成起来，还会把真实环境中需要的配置信息设置好，在预演环境中运行起来，进行整体业务逻辑检查

目标是保证代码处于可部署状态

持续部署

把所有通过测试的代码尽快部署到线上产品环境

持续部署是持续交付的更高阶段，它把处于可部署的代码自动发布到了产品环境，所以持续部署需要持续集成、持续交付的支撑

假如把工作流程粗略分为以下几个阶段：

编码完成 -> 单元测试 -> 集成 -> 验收测试 -> 部署

持续集成完成前3部分自动化

持续交付完成前4部分自动化

持续集成实现全部自动化

持续部署是理想的工作流程：

开发人员提交代码，持续集成服务器获取代码，执行单元测试，根据测试结果决定是否部署到预演环境，如果成功部署到预演环境，进行整体验收测试，如果测试通过，自动部署到产品环境，全程自动化高效运转

但也是很有难度的，例如产品规模很大，服务器数量多，拓扑关系复杂，而且可能需要蓝绿部署，部署工作本身就很繁重，这种情况下想实现从头到尾的全自动持续部署的确困难

如果不便实现持续部署，最好能实现持续交付，保证代码在模拟环境完全没问题，那么大家心里就有底多了