01-IaC CloudFormation的必要性和使用方法

前言

将应用的需求、开发、测试、部署和运营统一起来，基于整个组织的协作和应用架构的优化，实现敏捷开发、持续交付和应用运营的无缝 集成。帮助企业提升IT效能，在保证稳定的同时，快速交付高质量的软件及服务，灵活应对快速变化的业务需求和市场环境。

1 持续交付

持续交付是指持续的将各类变更(包括新功能、缺陷修复、配置变化、实验等)安全、快速、高质 量地落实到生产环境或用户手中的能力。

持续交付的分级技术要求包括:配置管理、构建与持续集成、测试管理、部署与发布管理、环境管 理、数据管理、度量与反馈等，如表1所示。

表1 持续交付分级技术要求

持续交付
配置管理	构建与持续 集成	测试管理	部署与发布 管理	环境管理	数据管理	度量与反馈
版本控制	构建实践	测试分层策略	部署与发布模式	环境管理	测试数据管理	度量指标
变更管理	持续集成	代码质量管理	部署流水线		数据变更管理	度量驱动改进
		自动化测试

1.1 配置管理

配置管理是指所有与项目相关的产物，以及它们之间的关系都被唯一定义、修改、存储和检索的过程，保证了软件版本交付生命周期过程中所有交付产物的完整性，一致性和可追溯性。

配置管理是持续交付的基础，是保障持续交付正确性的前提，良好设计的配置管理策略，可提高组织协作的效率，改善产品价值交付流程。配置管理可以分为版本控制和变更管理两个维度表述。

1.1.1 版本控制

版本控制是指通过记录软件开发过程中的源代码、配置、工具、环境、数据等的历史信息，快速重现和访问任意一个修订版本。

版本控制是团队协作交付软件的基础，应支持所有变更历史的详细信息查询及共享，包括修改人员、 修改时间、文件内容以及注释信息等，通过有效信息共享，加快问题定位速度和沟通协作效率，主要包括版本控制系统、分支管理、制品管理和单一可信数据源，如表 2 所示。

1.1.1.1 版本控制系统

版本控制系统是指通过记录一个或若干文件内容变化,能够查阅特定版本修订情况的系统。

1.1.1.2 分支管理

分支管理是对软件研发过程中的分支和集成策略的管理，分支策略代表了研发协作方式。

1.1.1.3 制品管理

2

制品管理是对软件研发过程中生成的产物的管理，一般作为最终交付物完成发布和交付。

1.1.1.4 单一可信数据源

单一可信数据源是一种信息数据模型和关联模式，保证每个数据元素只存储一份，确保数据的一致 性。

表2 版本控制

级别	版本控制系统	分支管理	制品管理	单一可信数据源
1	源代码分散在研发本地自行管理	无	构建产物分散在研发本 地自行管理	无
2	1) 使用统一的版 本控制系统 2) 将全部源代码 纳入版本控制系统管理	多条分支长期并行存在且分支合并到主干的周期长	1) 使用统一的制品库 管理构建产物 2) 有清晰的存储结构 3) 有唯一的版本号 4) 通过统一的制品库地址进行构建产物分发	开发测试部署环节所用到的源代码来源于统一版本控制系统
3	1) 将配置文件、 构建和部署等 动化脚本纳 入版本控制系统管理 2) 有健全的版本控制系统管理 机制，包括: 代码库命名规范备份与可用性保障机制权限模型专人专岗管理	短周期分支 分支频繁地向主干合并	将依赖组件纳入制品库管理 将所有交付制品纳入制品库管理，比如:测试报告 制品库读写有清晰的权限管控制度	版本控制系统和制品库作为单一可信数据源， 覆盖生产部署环节
4	1) 将数据库变更脚本和环境配 置等纳入版本控制系统管理 2) 版本控制系统 相关操作以自 动化的方式实 现，而非手工操作 3) 有针对版本控制系统的度量与监控机制	1) 分支策略满足持续交付需求，可灵活适应产品交付 2) 主干随时可进行指定版本的测试和发布 3) 特性代码可按需合并到主干进行验证和发布	对制品库完成分级管理 已建立体系化的制品库 管理策略，包括:备份与 恢复机制、策略管理，制 品库完整性与一致性保 障机制	单一可信数据源进一步覆盖研发本地环境
5	1) 将软件生命周期的所有配置项纳入版本控制系统管理 2) 可完整回溯软件交付过程满足审计要求 3) 持续优化的版本控制系统	1) 持续优化的分支管理机制 2) 可以针对不同业务和技术要求， 选用不同的分支策略，在指定时间发布	持续优化的制品管理机 制	1）单一可信数据源贯 穿整研发价值流交 付过程 2) 在组织内部开放共 享，建立知识积累 和经验复用体系

5.1.2 变更管理

变更管理指软件系统中的所有变更都可追溯变更的详细信息记录，并向上追溯变更的原始需求、流 转过程等所有关联信息，主要包括变更过程、变更追溯和变更回滚三方面，如表 3 所示。

可追溯性是版本回滚的历史依据和实施基础，建立良好的版本可追溯性可实现对任一版本完整环 境流程的自动化，精确回滚，快速重现问题和恢复正常环境。

5.1.2.1 变更过程

变更过程是变更的触发条件和实施手段，覆盖变更的完整生命周期。

5.1.2.2 变更追溯

变更追溯是变更相关信息和状态的识别和查询，包括变更人员、变更时间、变更原因、变更内容等。

5.1.2.3 变更回滚

 变更回滚是将变更恢复到变更之前的状态的过程。 

表3 变更管理

级别	变更过程	变更追溯	变更回滚
1	1) 无变更过程 2) 变更信息分散在每个系统内部，缺乏信息 的有效共享机制	无	无
2	1) 建立代码基线 2) 记录代码变更管理信 息 3) 针对重点变更内容进 行评审	1) 有清晰定义的版本号规则 2) 实现制品和代码基线的关联，可追溯指定版本的完整源代 码信息	手工实现回滚
3	1) 所有配置项变更由变 更管理系统触发 2) 针对每次变更内容进行评审，并使用自动 化手段	实现版本控制系统和变更管理系 统的自动化关联,信息双向同步和 实时可追溯	1) 实现变更管理系统和版本 控制系统的同步回滚，保证 状态的一致性 2) 回滚操作实现自动化
4	1)  使用统一的变更管理系统 2)  变更管理过程覆盖从需求到部署发布全流 程 3)  建立变更的分级评审机制	1) 变更依赖关系被识别和标记 2) 实现数据库和环境变更信息的可追溯	自动化回滚全流程的所有变更 包括变更依赖
5	可视化变更生命周期，支持全程数据分析管理	实现从需求到部署发布各个环节的相关全部信息的全程可追溯	同上

5.2 构建与持续集成

构建是将软件源代码通过构建工具转换为可执行程序的过程，一般包含编译和链接两个步骤，将高 级语言代码转换为可执行的机器代码并进行相应的优化，提升运行效率。

持续集成是软件构建过程中的一个最佳实践，在版本控制的基础上，通过频繁的代码提交，自动化 构建和自动化测试，加快软件集成周期和问题反馈速度，从而及时验证系统可用性。

5.2.1 构建实践

构建实践关注软件代码到可运行程序之间的过程，通过规则、资源和工具的有效结合，提升构建质 量和构建速度，使构建成为一个轻量级，可靠可重复的过程。同时构建产物被明确标识管理，采用清晰 的规则定义版本号和目录结构有助于团队成员可以随时获取到可用版本，以及版本相关的信息，快速验 证回溯版本变更，主要包括构建方式、构建环境、构建计划和构建职责四方面，如表4所示。

5.2.1.1 构建方式

 构建方式是源代码转变为可运行程序的方法和过程。 

5.2.1.2 构建环境

 构建环境是构建实际运行过程的设备和资源依赖的载体。 

5.2.1.3 构建计划

 构建计划是构建被触发的方式，频率和编排过程。