1 辨析敏捷/持续集成/持续交付/DevOps
2 持续集成
2.1 为何会有持续集成？
敏捷开发解决了单体应用的开发和每日构建的问题。
而单体应用拆分成微服务，就需要有一套方案来组装这些微服务，使其成为可协作运行的微服务架构。该方案就是持续集成。
- 持续集成强调开发人员提交新代码后，立刻进行构建、（单元）测试。根据测试结果，可确定新代码和原有代码是否正确集成在一起。
2.2 持续集成的定义
持续交付的鼻祖Martin Fowler提出：持续集成(Continous Integration)是一种软件开发实践，帮助团队成员频繁集成他们的工作，通常每个项目每天至少集成一次，从而每天有可测试的版本。
每次集成使用自动化构建(含测试)来实现打包和测试，快速验证问题。许多团队发现持续集成显著地降低了集成遇到的错误，使团队能够更加迅速地开发软件。
2.3 为何需要持续集成
就如同Git是为了把代码集成在一起管理，持续构建就是把功能集成在一起，保证编译不出错。
类似的还有自动化测试保证一个模块的功能集成在一起能够正确工作。
联调测试环境则能将不同模块之间集成在一起，在一个类生产的环境中进行测试。
2.4 持续集成流水线的设计
3 持续部署
3.1 传统部署的缺陷
- 传统部署部署方式严重依赖手工部署，人力成本高
- 生产环境依赖手工配置进行变更，非常繁琐
- 熬夜加班进行上线部署，效率很低
3.2 持续部署的定义
首先明确概念，软件部署：将软件按期望状态部署到目标机器的期望路径。
持续部署：自动化的将一或多个软件尽可能快的、稳定的、可重复的联合部署到目标机器，以便软件功能的验证和实际运行。
可能是在云环境中自动部署、app升级(如手机上的应用程序)、更新网站或只更新可用版本列表。
- 持续部署是在持续交付基础上，将部署到生产环境这一过程自动化。
3.3 持续部署的基本要素
- 自动化部署 - ansible
- 应用与配置分离，一次构建，多处运行 - Spring Cloud Config
- 提供应用健康监测的接口 - Spring Cloud Actuator
3.4 常见自动化部署方法
其中的vault专门用于存储一些加密信息，比如用户密码
