软件配置管理与低风险发布策略解析

### 软件配置管理与低风险发布策略解析 #### 1. 软件配置管理核心要点 软件配置管理（SCM）是构建持续交付部署管道和加速持续验证循环的基石。它主要遵循以下三个核心原则： - **版本化一切**：确保所有与软件相关的元素都进行版本管理。可以通过以下五个问题来验证是否做到了全面的版本管理： 1. 源代码和测试代码是否都存于版本控制系统（VCS）中？ 2. 软件应用的配置是否在VCS里？ 3. 各种环境的系统配置是否在VCS中？ 4. 自动化构建和部署脚本是否在VCS中？ 5. 软件包是否处于版本管理之下？ - **共享真实源**：保证团队成员使用的是一致的、准确的源文件。 - **标准化与自动化**：通过标准化流程和自动化工具，提高软件配置管理的效率和准确性。 此外，还可以用以下两个问题来检验SCM是否做得到位： 1. 只要从代码库中检出源代码，能否一键自动构建出完整的软件包？ 2. 团队中的任何成员能否在无需他人帮助的情况下，一键自动设置应用的最新版本以体验新功能？ #### 2. 高频发布成为趋势 自2001年敏捷宣言诞生以来，软件交付的敏捷模式曾饱受质疑。早期，中国很少有软件公司对其感兴趣，一些IT公司甚至认为不需要如此快速地交付软件，而互联网公司则觉得敏捷模式两周一次的发布频率太慢。然而，2009年John Allspaw和Paul Hammond在Velocity大会上关于“每天10多次部署：开发与运维合作”的演讲，开启了DevOps运动，让人们看到了软件快速发布的可能性。 ##### 2.1 互联网公司的高频发布实践 - **亚马逊**：早在2011年5月，其月度统计显示平均每11.6秒触发一次部署，该月最高部署频率达到每小时1079次。平均有10000台服务器同时接收部署请求，最高纪录是30000台服务器同时进行部署操作。 - **Facebook**：2017年，其前端代码每天推送多次，移动应用每周推送到应用市场一次。每天会向内部员工发布绿色版本，同时分别向100000和数百万用户推送Alpha和Beta版本。不过，并非所有推送都是功能发布，部分包含前端的bug修复。尽管部署频率增加、代码总量和提交次数增多，但严重缺陷的数量并未增加。 - **Etsy**：这是一家从事手工制品交易的P2P电子商务公司。2009年底开始转向持续交付，此前采用瀑布模型，发布过程缓慢、复杂且高度定制。2010年后，其部署具有“快速、简单、一致”的特点，具体对比如下： | 对比项目 | 2010年前 | 2010年后 | | --- | --- | --- | | 每次部署前置时间 | 需要6 - 14小时的停机部署时间 | 15分钟（配置更改少于5分钟） | | 每次部署的人员 | 专门的部署团队 | 1人 | | 部署频率 | 公司的首要任务，高度规划，低频 | 2012年30次/天，2014年50次/天 | | 代码贡献者数量 | 无数据 | 2012年170 + 人 | | 部署步骤 | 1. 创建发布分支<br>2. 准备数据库结构更改<br>3. 准备数据转换<br>4. 打包<br>5. 分发、部署、重启<br>6. 清理缓存<br>7. 查看结果 | 1. 使用主干代码<br>2. 极少的链接和构建<br>3. 通过rsync分发<br>4. 结束 | Etsy每次部署包含以下内容： 1. 应用程序软件中添加的新类或函数。 2. 页面上的图像、样式表或模板文件。 3. 内容更改等。 4. 修改切换开关或逐步推出。每次部署可能是对在线问题（如安全风险、缺陷、用户请求或扩展/缩减）的快速响应，也可能是对配置的补丁。 ##### 2.2 高频发布的利弊分析 高频发布每次发布的内容通常比低频发布少，但众多公司仍朝着高频发布的方向发展，原因在于它具有以下好处： - 有更多机会与真实用户互动，从而快速决定或调整产品方向。 - 每次更改较小，风险较低。 - 部署成本降低且趋于稳定。以Etsy为例，采用大版本发布模式时，每次部署需要大量精力和时间；2010年实施高频发布后，每次部署所需的精力和时间减少且基本保持不变。频繁部署的压力促使人们构建大量自动化设施，从而降低成本和精力消耗。 - 问题易于调试和快速修复。 不过，高频发布也并非没有成本。如果强制以低频发布的工作模式进行高频发布，会导致更高的迭代成本。例如，一个原本每月手动发布一次的团队，突然改为每周发布一次，若仍采用原有的手动模式，每月的验证工作量将增加四倍。而且，发布周期缩短后，原本成本相对较低的操作（如编译时间和测试工作强度）会成为突出的矛盾。 #### 3. 降低发布风险的方法 为了降低软件发布的风险，可以采用以下几种策略： ##### 3.1 蓝绿部署 蓝绿部署是准备两个相同的环境，一个作为正式生产环境提供外部服务，另一个作为预生产环境部署新版本软件并进行验收测试。确认新版本质量后，将访问流量导向新版本所在环境，使其成为正式生产环境，同时保留旧版本环境。直到确定新版本稳定后，旧版本环境将作为下一个版本的预生产环境。 在实际应用中，由于数据库复制的时间和成本较高，通常蓝绿部署解决方案会使用相同的数据库，但其他应用使用不同的环境。此时，相同数据的存储格式必须兼容新旧版本，以确保同一数据能同时用于两个版本的操作。另外，还需要解决用户请求跨事务处理时的数据一致性问题。一般来说，切换不是瞬间完成的，在切换过程中，新请求会被导向新版本环境，而旧版本环境不再接受新请求。对于切换时尚未响应的旧请求，可以继续访问旧环境，但不能有新请求进入。 ##### 3.2 滚动部署 滚动部署是从集群中选择一个或多个实例，停止服务并进行更新，然后重新投入使用。重复此步骤，直到集群中的所有实例都更新完毕。与蓝绿部署相比，滚动部署更节省资源，可将实例数量减少一半。 当新版本出现问题时，滚动部署不能像蓝绿部署那样简单地切换回旧版本，而是需要回滚新版本的实例。另一种快速修复的方法是创建一个补丁版本V3，并立即启动V3的滚