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年归纳提出，被称为Gitflow4.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.发布经理使用加密密钥对构件进行签名，这样用户就可以验证下载的软件包是否来自Apache6.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.变更日志主要会被支持团队和开发团队阅读，而发行说明是专门给用户看的