05-CI,CD领域实践

持续集成

持续集成意味着频繁地提交代码改动到集成分支，并进行测试
持续集成使得集成问题变少并且更容易被解决
引入构建流水线，并且保证其中的各个步骤可以迅速完成
及时修复集成过程中发现的问题
持续集成的实施不应教条化，而是要因地制宜

持续交付

持续交付让各类变更以安全、快速、可持续的方式交付到生产环境或用户手上
持续交付是持续集成的延伸，实现持续交付也需要做好版本控制、自动化、快速执行、及时修复等实践
围绕持续交付的核心目标来行动：从开发完毕到发布所需的时间更短、让发布更可靠
遂特性发布的集成发布方式，是对一个特性从完成到发布所需时间的极致追求的例子

变更管理

变更管理是指软件开发中所有的变更均可以被记录及追溯
变更风险管控的三大原则：可灰度，可监控，可回滚
常见的变更类型：基础设施变更、代码基线变更、配置项变更、依赖项变更、数据库变更、生产发布变更
最佳实践：变更过程尽量自动化、变更评审机制、变更过程可追溯、生产变更过程可灰度、变更操作可回滚

部署自动化

部署自动化使用户能够“一键式”将软件部署到测试和生产环境，理想状态下的所有的操作全部自动化，无需手工干预
对每个环境（包括生产环境）使用相同的部署流程
允许具有必要权限的人以完全自动化的方式，根据需要将任意版本的组件部署到任何环境
对每个环境使用相同的软件包

制品管理

制品一般存放在制品库中，以防损坏或丢失，并且便于查找
除了存放制品本身，还要考虑存放制品的元数据，比如质量等级以及制品与源代码等对象的关联关系
制品是企业核心软件资产，制品仓库是企业软件资产管理平台，是企业的单一可信源
制品管理属于企业基础设施
做好企业管理可以帮助企业合规、安全的使用地方放开源组织及软件

发布策略

理解部署和发布的差异是了解和制定发布策略的前提
没有最好的发布策略，只有最适合场景的发布策略
发布策略的抉择不仅是一个技术举措、还需要纳入业务考量
常见的发布策略包括停机部署、滚动更新、蓝绿部署、灰度发布、A/B测试、影子部署等

数据库变更

数据开发人员应该像应用开发人员一样管理自己的数据资产
数据库架构必须具备演进能力
为应对频繁地数据库重构工作，需要重视数据库 Schema 脚本的变更管理
数据库变更也应该像变更应用程序代码一样，拥有版本控制管理和发布流程
生产数据库的变更既要保证升级或迁移过程是安全可靠的，也要保证生产数据的安全，保护客户隐私

配置参数管理

系统配置参数和业务配置参数都需要被妥善管理
管理配置参数有多重方法，分别有其优缺点，有其适用场景
如果配置参数随着源代码的演进而演进，最好是跟源代码一起走集成发布流程
如果配置参数的值随着不同环境而变化，则无须跟源代码一起走集成发布流程

解读

简单来说，持续集成以及持续交付的主要行为标准就是尽一切可能将软件开发完成后的过程自动化，从自动部署到测试环境，到自动进行单元测试、压力测试，甚至根据对不同分支的对待策略，定量客户进行灰度发布、蓝绿发布等

举个灰度发布的例子（蓝绿发布成本太高，一般情况下只有云原生环境用蓝绿发布才能保证成本）
某个系统有一个需求需要根据某些定制客户进行发布（实际上就是试试业务反馈，好就全公司推广，不行就过后把这个活动变更的需求扯下来），在这种背景下，我们通过代码分支“feature/01”作为该需求变更的分支代码。发布时可根据负载均衡定制为某个应用服务器上引导这部分客户的业务过程，特性分支（feature/01）也同时发布到这个应用服务器而做到灰度发布。有负载均衡和特性分支管理的时候很容易对吧？！

有关于数据库脚本变更的可参考使用 flywaydb liquibase 或在 scm 专门创建一个从建库开始到现在 以变更为维度作为文件夹的方式来管理数据库变更，注意如果时候后者完成管理，请一定要将从建库开始（完成安装后的一切步骤开始作为数据库积累，而不是从数据库导出的脚本作为版本管理。

有关于持续集成 持续部署的工具 jekins 是首选，原因有很多：插件多，文档多，经历过大量项目使用考研，开源且安全。