1 相关概念
1.1 持续集成CI
敏捷开发解决了单体应用的开发和每日构建的问题。单体应用拆分为微服务，微服务模式下应用部署的复杂度高，需要有新的方法来组装这些微服务，组装成为可以联合运行的微服务架构，持续集成为微服务的组装提供支持。
持续集成是一种软件开发实践，帮助团队成员频繁地集成工作，通常每个项目每天至少集成一次，从而每天会产生可测试的版本，每次集成使用自动化构建/测试实现打包和测试，快速地验证问题，持续集成可以有效地降低集成过程中遇到的错误，使团队可以更加迅速地开发软件。
自动化测试使得一个模块的功能集成在一起后可以验证其的正确工作能力，通过联调测试环境可以将不同模块集成在一起，在一个类生产环境中进行测试。
1.2 持续部署CD
软件部署是将软件按照期望的状态部署到目标机器上的期望路径上，持续部署是自动化地将一个或多个软件尽可能快地、稳定地、可重复地联合部署到目标机器上，以便进行软件功能的验证和运行。可能是在云环境的自动部署、APP升级、更新网站或者只更新可用版本列表。
持续部署的关键在自动化部署，自动化部署常用Ansible实现，通过Spring Cloud Config可以实现应用与配置分离，一次构建，多处运行，Spring Cloud Actuator提供了应用健康监测的接口。
1.3 区别
相关概念的区别：
- DevOps=计划+代码+构建+测试+发布+部署+运维
- 持续部署=计划+代码+构建+测试+发布+部署
- 持续交付=计划+代码+构建+测试+发布
- 持续集成=计划+代码+构建+测试
- 敏捷开发=计划+代码+构建
1.3 发布部署方式
1.3.1 蓝绿发布
蓝绿发布维护了两个相同的主机环境，一个为蓝色表示生产环境，一个是绿色表示预发布环境，在实例之前是调度系统，充当产品或应用程序的客户网关，通过调度系统指向蓝色或绿色实例，可以将客户流量引流到期望的部署环境，通过这种方式切换指向那个部署实例。
1.3.2 金丝雀部署
一部分客户流量被重新引流到新的版本部署中，以在生产环境中对其进行测试。如果新版本没有问题，就将更多的流量引流过去，随着时间的推移，可以对新版本进行增量部署，直到100%的流量都被调度到新版本上。
1.3.3 功能开关
对于可能需要轻松关掉的新功能，开发人员可以添加功能开关，在代码中的if-then软件功能开关，仅在设置数据值时才激活新代码，此数据值可以是全局可访问的位置，部署的应用程序检查该位置是否应执行新代码，如果设置了数据值，就执行代码，如果没有就不执行。这为开发人员提供一个远程的终止开关，以便部署到生产环境后发现问题时关闭新功能。
2 DevOps流程
2.1 敏捷开发
- 需求管理：Jira
- Release单位为月
- Spring单位为周
- Issue问题
- Epic
- Story
- Task
- Bug
- 在IDEA中可以使用Jira插件关联Jira服务器
2.2 微服务架构
- Springboot：Web应用
- SpringCloud：注册中心、网关、服务治理
2.3 持续集成
- 构建：Maven：
- snapshot
- Release
- 集成：Jenkins
- 制品库：Artifactory开源版
2.4 持续测试
- 单元测试：JUnit
- 代码静态扫描：Sonarqube
- 接口自动化测试：YAPI
- UI自动化测试：Selenium
2.5 容器化：Docker
- 进程隔离：Namespace
- 资源隔离：CGroups
- Docker镜像：联合挂载
- Dockerfile
- 镜像仓库：JFrog Container Registery
2.6 Kubernetes
- 运行环境：minikube
- 核心概念：Pod、Service、Deployment、密钥、PV/PVC、Probe应用探针
- 应用发布：Helm
3 Gitflow
- master：始终保持具备生产部署的状态
- develop：包含所有最新的、可发布的变更也叫集成分支。当从develop发布到Release分支，变更需要合并的master分支。
- feature分支：可能基于develop创建，必须合并回归到develop，不可命名为master、develop、release-*、hotfix-*。
- Supporting分支：
- Hotfix补丁分支：可能基于master创建，必须合并回归到develop、master，分支命名为hotfix-*
