1. 行为准则

2. 软件交付

2.1. 你应该了解你的代码最终是如何出现在用户面前的

2.2. 当软件在生产环境中稳定运行，并且被客户真实使用时，它就被交付了

3. 软件交付流程

3.1. 交付阶段并没有行业标准的定义

3.1.1. 从打包到展开，统称为发布(release)

3.1.1.1. 打包一个构件称为发布

3.1.2. 把构件交付下载的过程称为发行(publishing)

3.1.3. 直到一个特性在生产环境中被打开时才能称其为被“发布”了，而在这之前的一切行动都是部署(deploy)

3.1.3.1. 部署的软件还不能被用户访问

3.1.3.1.1. 只是被安装了而已

3.1.3.2. 一旦部署，软件就会通过将用户转移到新的软件上而进行展开

3.1.4. 一旦展开完成，就意味着完成了交付

3.1.4.1. 交付过程是更大的产品开发周期中的一部分

3.2. 软件交付的4个阶段，即构建(build)、发布、部署和展开(rollout)

3.2.1. 软件包应该是不可变的，并且被标记了版本

3.3. 正确的分支策略将使软件交付变得简单和可预测

3.4. 错误的策略将使交付变成与流程本身的缠斗

4. 分支策略

4.1. 发布的软件包是使用VCS中的代码进行构建的

4.1.1. 软件包是建立在稳定的发布分支上的

4.2. 主分支

4.2.1. 主干或主线

4.2.2. 包含整个代码库的主版本，并有修改的历史记录

4.3. 分支

4.3.1. 是从主分支上“切”下来的，以进行代码修改

4.3.2. 分支被用于单个小型特性、修复bug或更新

4.4. 只有当各分支可以快速合并到主分支时，基于主分支的开发模式的效果才是最好的

4.4.1. 如果不是在几小时内，也应该在几天内合并到主分支，并且不在开发人员之间共享

4.4.2. 在一个分支被合并到主分支上之前，要运行快速的自动化测试来验证其是否可以通过

4.4.3. 面向服务的系统通常使用基于主分支的开发模式

4.4.4. 除非你真的需要那种长期存续的特性分支，否则请坚持使用基于主分支的分支策略

4.5. 频繁地合并被称为持续集成(CI)

4.5.1. CI可降低风险，因为代码上的变化会迅速传递给所有的开发人员，使他们彼此之间不太可能有很大的分歧

4.5.2. 让开发人员的代码库保持同步，可以防止潜在的最后一分钟的集成障碍，并尽早暴露出错误和不兼容的情况

4.6. 基于特性分支的开发模式

4.6.1. 在基于特性分支的开发模式中，许多开发人员同时在长期存续的特性分支上工作，每个特性分支与产品中的一个特性相关联

4.6.2. 当主分支太不稳定以至于无法发布给用户时，或者开发人员希望避免进入特性冻结期，即在主分支线稳定后禁止提交特性时，基于特性分支的开发就很常见

4.6.3. 基于特性分支的开发模式在收缩型软件中更为常见，因为不同的用户使用着不同的版本

4.7. 最流行的特性分支方法，由文森特·德里森在2010年归纳提出，被称为Gitflow

4.7.1. Gitflow使用开发分支、热修复分支和发布分支

4.7.2. 开发分支被用作主分支，特性分支与之合并和变基

4.7.3. 主分支总被认为是可以随时部署到生产环境的，因为它只包含稳定的版本

4.7.4. 热修复被应用于热修复分支，然后会被合并到主分支和开发分支

4.7.5. 特性分支是长期存续的，它与开发分支之间有提交和合并

4.7.6. 德里森已经修改了他最初关于Gitflow的博文，不再鼓励将Gitflow用于可持续集成和交付的软件

5. 构建环节

5.1. 软件包是为每个发布版本而构建的，所以软件不必在每台运行它的计算机上再次构建

5.1.1. 与每台计算机使用自己的环境和特异的工具集来编译和运行代码相比，预先构建好的软件包更加一致

5.2. 如果软件的目标是在一个以上的平台或环境中运行的话，构建环节就会产生多个软件包

5.3. 构建通常会为不同的操作系统、CPU架构或语言运行环境产生软件包

5.4. 软件包的内容和结构各不相同

5.5. 软件包可以包含二进制包或源代码、依赖关系、配置、发行说明、文档、媒体文件、许可证、校验和，甚至是虚拟机镜像

5.6. 应用程序包通常以ZIP压缩包、TAR压缩包（.tar文件）或安装包（.dmg或setup.exe文件）的形式构建

5.6.1. 容器和机器包允许开发者不仅可以构建他们的软件，而且还可以构建软件运行的环境

5.7. 打包决定了什么软件会被发布

5.7.1. 了解你的打包系统的假设和约定将防止部署环节出问题

5.8. 打包需要带版本号

5.8.1. 软件包也应该被纳入版本管理，并且被分配唯一的标识符

5.8.2. 语义化版本是一个安全的选择

5.9. 将不同的资源单独打包

5.9.1. 软件不仅仅是代码，配置、schema、图像和语言包（各种语言的翻译）都是软件的一部分

5.9.2. 不同的资源应该被分开单独地打包，这样它们就可以被修改而不需要重新构建整个软件包

5.9.3. 分开打包让每种类型资源都有自己的发布周期，可以独立向前和向后滚动

5.10. 元包

5.10.1. 一个包含所有包的包

6. 发布环节

6.1. 发布环节可以让用户使用软件，并实现部署，即交付的下一阶段

6.2. 面向用户的发布则需要发布构件、文档的更新、发行说明和用户沟通

6.3. 发布管理是一门艺术，它可以采用可预测的节奏来发布稳定的、拥有良好文档的软件

6.4. 理解发布管理将帮助你有效地参与你公司的发布流程

6.5. Apache软件基金会的发布流程

6.5.1. 每一个Apache项目发布环节都会指定一名发布经理来运作

6.5.2. 发布包括源代码和通常的二进制包

6.5.3. 发布经理使用加密密钥对构件进行签名，这样用户就可以验证下载的软件包是否来自Apache

6.5.4. 发布也包括用来检测损坏的校验和

6.5.5. 发布包括LICENSE和NOTICE文件，以声明各种软件许可和版权，并且所有源文件的头注释里都包括许可信息

6.6. 请勿只想着发布

6.6.1. 请对你的软件发布负责

6.6.2. 你应该确保你的代码在测试环境中运行良好，跟踪发布时间表，理解那些可用的选项，并为你的应用程序选择正确的配置

6.7. 将包发布到仓库

6.7.1. 存储资源库会为终端用户提供已发布的构件

6.8. 保持版本不变性

6.8.1. 一旦发布了，就永远不要改变或覆盖这个已发布的包

6.8.2. 不可变的发布包可保证所有运行特定版本的应用程序实例都是相同的，在字节层面上都一样

6.8.3. 相同的发布包让开发者可以推理出应用程序中的代码以及它应该如何表现

6.8.4. 版本会变化的包并不比没有版本的包更优秀

6.9. 频繁发布

6.9.1. 应该尽可能频繁地发布

6.9.2. 在实践中，快速的发布会产生更稳定的软件，当发现bug时更容易修复

6.9.3. 具有自动发布和部署特性的软件应该可以在每次提交时都触发发布流程

6.10. 对发布计划保持透明

6.10.1. 发布时间表定义了软件的发布频率

6.10.2. 有些项目有可预测的基于时间的计划

6.10.2.1. 每季度或每年发布一次

6.10.3. 有些项目则在特定特性完成时发布（也就是基于里程碑的发布）

6.10.4. 内部系统经常在每次提交时都发布版本

6.10.5. 公开时间表并在新版本发布时通知用户

6.11. 撰写变更日志和发行说明

6.11.1. 变更日志和发行说明可以帮助你的用户和支持团队了解一个版本中包含的具体内容

6.11.2. 发行说明是对一个版本中包含的新特性和修复的bug的汇总

6.11.3. 变更日志主要会被支持团队和开发团队阅读，而发行说明是专门给用户看的