高频发布是一种趋势
收益与成本共存
高频发布的收益：
有更多的机会与真实用户互动，从而快速决定或调整自己产品前进的方向
由于每次变更规模较小，软件系统没有剧烈的变化，从而降低部署风险
单次部署成本降低，且趋于稳定
出现问题易定位、易修复，且能够快速更正
降低发布风险的方法
蓝绿部署
指准备两套完全一致的运行环境，其中一套环境作为正式生产环境，对外提供软件服务。另一套环境作为新版本的预生产环境，部署软件的新版本，并对其进行验收测试。当确认没有问题后，将访问流量引流到这个新版本所在的环境中，作为正式的生产环境，同时保持旧版本所在环境不变。直至确定新版本没有问题后，再将旧版本所运行的环境作为下一个新版本的预生产环境，部署未来的新版本。
缺点：
数据库复制成本高，若用一个数据库则需对新旧两个软件版本做兼容性处理
当切换发生在用户的一次业务操作过程当中且涉及事务处理时，数据的一致性问题
滚动部署
指从服务集群中选择一个或多个服务单元，停止服务后执行版本更新，再重新将其投入使用。
金丝雀发布与灰度发布
金丝雀发布：指通过让一小部分用户先行使用新版本，以便提前发现软件存在的问题，从而避免让更多用户收到伤害的发布方式。
灰度发布：将发布分成不同的阶段，每个阶段的用户数量逐级增加。如果新版本在当前阶段没有发现问题，就再扩展用户数量进入下一个阶段，直至扩展到全部用户
实现方式：
通过开关隔离方式实现：将软件的新版本部署到生产环境中的所有节点，通过配置开关的方式，针对不同范围的用户开放新功能（比如通过网关、IP、cookie、基于某个请求参数做流量切换实现白名单）
通过滚动部署方式实现：将软件的新版本部署到生产环境中的一部分节点上，对这些节点的访问流量就会使用这个新版本的功能，而其他节点的访问流量仍旧使用原版本的功能
暗部署
功能或特性在正式发布之前，将其第一个版本部署到生产环境，以便在向最终用户提供该功能之前，团队可以对其进行测试，并发现可能的错误。
特点：用户无感知
实现方式：
通过开关技术来实现
流量克隆方式实现
高频发布支撑技术
功能比较复杂，无法在两次发布之间完成开发
解决方法：
拆分功能：将一个功能进行分解，分解为更小的在一个开发周期内能够完成的功能集
先后再前：先实现服务端功能，再实现用户界面。即首先实现用户不可见的那部分功能，同时要确保不影响原有的功能
功能开关技术
功能开关技术
通过开关隐藏未开发完成的功能
用途：
隔离：即将未完成功能的代码隔离在执行路径之外，使之对用户不产生影响
快速止血：一旦生产环境出了问题，直接找到对应功能的开关选项，将其设置为“关闭”
遵循原则：
在满足业务需求的前提下，尽可能少用开关技术
如果在“分支”和“开关”之间选择，尽可能选择开关技术
开关技术可以小步迭代
可以在主干上与他人代码频繁集成，尽早发现设计冲突问题
创建分支会带来后期的分支合入以及多次测试成本
软件团队应对开关配置项进行统一管理，方便查找和查看状态
尽可能使用统一的开关框架和开关策略。开关策略是指开关的定义、命名，以及如何配置
数据迁移技术
字段尽可能只增不删：对数据库表中的原有字段不再进行修改和删除操作
数据迁移
为数据库结构增加一个新版本
修改应用程序，同时向两个版本的结构中写入数据
编写脚本程序，以后台服务的方式将原来的历史数据回填到新版本的结构中
修改应用程序，从新旧两个版本中读取数据，并进行比较，确保一致
当确认无误后，修改应用程序，只向新版本写入数据。可以将原来的旧版本数据保留一段时间，以防止未预料的问题出现
抽象分支方法
不创建真实分支的情况下，通过设计手段，将大的重构项目分解成很多个小的代码变更步骤，逐步完成重大的代码架构调整
升级替代回滚
尽可能以代码升级的方式代替二进制回滚
影响发布频率的因素
增量发布带来的收益和可能性
每次发布或部署的操作执行成本有多高
出现问题的概率与由这些问题带来的成本有多少
维护同一软件的众多不同版本带来的成本
高频发布模式对工程师的技能要求
支撑这种高频发布所需要的基础工具设施与流程完善性
组织对这种高频发布的态度和文化取向