持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第14天，点击查看活动详情
二 持续部署面临的挑战
1 持续交付与持续部署的区别
- 持续交付是在部署到生产环境之前，加了一个业务判断，决定是否交付给客户，然后一键部署到生产环境;持续部署是自动化的将一切变更放到生产环境。
- 持续部署代表将所有变更自动通过流水线推到生产环境，持续交付则意味着你有能力这样做，但可以基于业务选择不这样做。
从这个角度看持续交付更像是一个业务行为，而不是技术行为。所以不应该讨论两者有谁包含谁，两者在这个层面讲，一个是技术领域，一个是业务领域。
2 业务与技术方面的难点
- 业务方面：涉及模块多，版本控制不规范，需要花很多心思在模块与模块之间、模块与组件之间的适配。导致简单的测试用例并不能完全覆盖复杂问题;
- 技术方面：当一个服务的部署运行环境很复杂，那么部署方式会成为一个难点。
有必要从业务上和技术上分别举例来说明持续部署面临的痛点
三 当DevOps碰到了微服务
微服务很火，但是我觉得真正能称之为微服务架构的少之又少。原因也很简单，大多都没有做到微服务架构的一个基本要求：服务的独立部署（交付）
1 微服务的独立部署
举例，并且假设该流程为极端情况，每个服务互相调用，不考虑是否合理。
三个模块，分别进行编译、单元测试和部署，自动发布到产线，完成了每个模块的独立部署
但是假设A模块版本升级，破坏了与B和C的契约，导致A服务部署到产线引起严重的bug。要解决这个办法，我们可以加上集成测试。
这里加上一个e2e(e2e: end to end 端到端测试)
通过添加E2E测试，解决了服务间集成的验证问题，但也失去了微服务架构的那个重要的特性：“服务的独立交付”。 若没通过集成测试，所有微服务都会在部署的道路上被阻塞。最后这一个红绿灯，让所有的服务又纠缠在了一起，所有的服务化拆分形同虚设，最终得到的也只是一个看起来像微服务架构的单体应用而已。
要解决这个问题，可以在每个服务单元测试之后分别进行集成测试。
此时的E2E测试并不是像之前一样获取B和C服务的最新代码库版本做集成验证，而获取当前产品环境上的B和C服务的已部署当前版本做集成验证。
该例子很简单，看似是简单的变化，但是揭示了持续集成和持续交付的本质区别。
（关于更优的测试方式还有契约测试，不是重点，感兴趣的可以自行了解。）
