概要

• 持续集成缘何而来
• 敏捷，持续集成，持续交付，DevOps的区别
• 为什么需要做持续集成
• 如何设计持续集成流水线

一、持续集成缘何而来

• 敏捷开发解决单体应用的开发和每日构建的问题
• 单体应用拆解成微服务，就需要有方法来组装这些微服务，成为可联合运行的微服务架构。这个方法就是持续集成。

二、持续集成的定义

• 持续交付的鼻祖Martin Fowler提出：持续集成(Continous Integration)其实是一种软件开发实践，帮助团队成员频繁地集成他们的工作，通常每个项目至少集成一次，从而每天有可测试的版本。
• 每次集成使用自动化构建(含测试)来实现打包和测试，快速验证问题。许多团队发现持续集成显著降低了集成遇到的错误，使团队能够更加迅速地开发软件。

三、敏捷，持续集成，持续交付，DevOps区别

四、需要进行持续集成的原因

1、单体应用的部署相对简单

2、微服务模式下应用部署的复杂度高

3、代码统计管理和持续构建

• 为什么需要一个统一的代码仓库Git来做代码管理呢？是为了把代码集成在一起管理。
• 为什么需要进行持续构建呢？就是把功能集成在一起，保证编译不出错。
• 为什么要自动化测试呢？一个模块的功能集成在一起能够正确工作。
• 为什么需要联调测试环境呢？需要将不同的模块之间集成在一起，在一个类生产的环境中进行测试。

五、如何设计持续集成流水线 

六、为什么需要持续部署

• 传统部署方式依赖手工部署
• 生产环境依赖手工配置进行变更
• 熬夜加班进行上线部署

七、持续部署的定义

• 软件部署：将软件按照期望的状态，部署到目标机器上的期望路径。
• 持续部署：自动化的将一个或者多个软件尽可能快的、稳定的、可重复的联合部署到目标机器，以便进行软件功能的验证和实际运行。可能是在云环境中自动部署、App升级(如手机上的应用程序)、更新网站或者只更新可用版本列表

八、持续部署的要素

• 自动化部署 - ansible
• 应用和配置分离，一次构建，多出运行 - Spring Cloud Config
• 提供应用健康监测的接口 - Spring Cloud Actuator

九、常见自动化部署方法

十、如何测试部署的效果

• 蓝绿发布
• 金丝雀发布
• 功能开关

1、蓝绿发布

• 在这种部署软件的方法中，维护了两个相同的主机环境——一个“蓝色”和一个“绿色”。（颜色并不重要，仅作为标识。）对应来说，其中一个是“生产环境”，另一个是“预发布环境”。
• 在这些实例的前面是调度系统，他们充当产品或应用程序的客户“网关”。通过将调度系统指向蓝色或绿色实例，可以将客户流量引流到期望的部署环境。通过这种方式，切换指向哪个部署实例（蓝色或者绿色）对用户来说快速、简单和透明的。

2、金丝雀发布

• 一部分客户流量被重新引流到新的版本部署中。例如，新版本的搜索服务可以与当前服务的生产版本一起部署。然后，可以将10%的搜索查询引流到新版本，以在生产环境中对其进行测试。
• 如果服务那些流量的新版本没问题，那么可能会有更多的流量会被逐渐引流过去。如果仍然没有问题出现，那么随着时间的推移，可以对新版本增量部署，直到100%的流量都调度到新版本。

​​​​​​​

3、功能开关

• 对于可能需要轻松关掉的新功能（如果发现问题），开发人员可以添加功能开关（feature toggles）。这是代码中的if-then软件功能开关，仅在设置数据值时才激活新代码。
• 此数据可以是全局可访问的位置，部署的应用程序将检查该位置是否执行新代码。如果设置了数据值，则执行代码；如果没有，则不执行。
• 这为开发人员提供了一个远程“终止开关”，以便在部署到生产环境后发现问题时关闭新功能。

《新程序员》：云原生和全面数字化实践 50位技术专家共同创作，文字、视频、音频交互阅读