目录
一、持续集成
1. 构建触发规则
2. 构建初始化
3. 构建目录
4. 全量构建
5. 构建配置
二、持续交付
1. 部署与发布模式
2. 持续部署流水线
3. 参数配置
一、持续集成
1. 构建触发规则
【强制】每次开发人员提交了新代码之后都应触发软件的构建。
【建议】每次提交都应触发一系列可在几分钟内提供反馈的自动测试。
2. 构建初始化
【强制】构建之前，每个组件的构建入口都要先清除历史构建遗留件。
3. 构建目录
【强制】构建过程中禁止删除或修改源代码已有目录结构。
4. 全量构建
【强制】对于版本发布构建，归档的产品全量交付件（含所依赖的所有平台和组件）必须全部重新编译，禁止使用增量编译。
5. 构建配置
【建议】构建配置文件默认在根目录。
【强制】构建配置文件必须使用UTF-8编码。
【强制】禁止使用与操作系统强绑定的文件（如excel）作为构建配置文件。建议使用跨平台的标准配置文件（如XML）来存放配置选项。
【强制】构建参数化命名不要使用空格、“_”、“-”等特殊字符。
【建议】构建生成的交付件（jar或war）命名方式为：artifactId-版本号.(jar|war)
二、持续交付
持续交付（CD）在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中进行更多的测试。如果代码没有问题，可以继续部署到生产环境中。
1. 部署与发布模式
【建议】持续部署，每次变更都触发一次自动化生产环境部署过程。
【建议】使用恰当的部署发布策略保证流程风险可控，如：蓝绿发布、金丝雀发布、滚动部署等。
2. 持续部署流水线
【建议】可视化部署流水线覆盖整个软件交付过程，每次变更都触发完整的自动化部署流水线。
【建议】部署流水线全员可见，对过程信息进行有些聚合分析展示趋势。
代码与部署环境的对应发布方式：
分支\环境 | 本地开发 | 测试 | 生产 |
feature-* | 基于本地文件 | X | X |
hotfix-* | 基于本地文件 | 基于分支 | X |
master | X | 基于分支 | 基于TAG |
3. 参数配置
【建议】对数据库地址等会变化的参数进行参数化配置。
【强制】对于敏感信息，如数据库密码、Redis密码等进行加密配置。
【建议】对于多个服务都涉及的参数，建议配置全局性的参数。
