继续根据软件业务价值流图来学习总结，本篇我们接着上一次的需求管理&变更管理来关注与它们密切相关的版本控制。
版本控制可以说是我的老本行了，在华为的五年配置管理岗位都是围绕着版本控制打转，然而当时还没有彻底理解版本控制的意义所在。如今将版本控制作为持续交付流水线的一部分来看待，反而能对其本质有更深一层的理解。
版本控制是变更管理的最佳拍档和技术手段，它能够控制和记录目标对象的每一次变更信息，确保变更过程可控和可追溯。常用的版本控制工具包括Git/SVN/Perforce等，各有自己的优缺点，比如Git适合管理源代码，Perforce适合管理二进制制成品。
执行版本控制需要秉持一个理念：将一切纳入版本控制库管理。这里的一切不仅包含源代码，同时还包含数据库脚本、构建脚本、测试用例、测试脚本、部署脚本、相应工具集、配置文件等所有与软件程序质量相关联的内容。
在将一切都纳入版本控制库管理后，即可以体现出版本控制的第一点意义：协作同源。版本控制可以使得所有团队清晰地维护同一份源头，避免出现信息壁垒，提高协作效率。
版本控制通常与在线评审工具系统配合使用，例如git与gerrit，这体现出版本控制的第二点意义：变更可控。通过权限配置方案与变更评审机制，可以确保每一次变更都经过所需要的审核后才能生效。
版本控制的第三点意义，也是最重要的一点，即是：变更可溯。可溯分为两部分：第一，版本控制工具可以记录目标的每一次变更信息，并使用一个唯一的全局版本号来标识这次变更，那么后端的构建、归档、测试、部署过程均可以记录相应的全局版本号信息，以确保每一次的流水线产物都可以清晰对应到具体变更。第二，版本控制工具可以通过脚本或钩子使得目标的变更信息中带有对应的变更流程单号（例如Jira bug单号或需求编号），使得每一次具体变更都可以对应到相关需求或缺陷的变更流程。通过变更可溯，可以确保从前端的需求到最终部署的产物之间的联系是清晰可见的。
版本控制的第四点意义就是使得持续交付的自动化程度大大提升，包括与持续集成的配合、与二进制库的配合等。
说完版本控制，我们再着重说一下其中的配置文件相关管理。软件的配置文件包括很多种，比如编译的配置文件、应用启动的配置文件、环境的配置文件等。此处我们关注环境的配置文件（包括生产环境、类生产环境、测试环境、开发环境等），即业界所说的“基础设施”管理。
如今的基础设施管理为了满足软件应用更频繁更复杂的发布场景，必须依靠更加规范的管理和更高程度的自动化，来实现快速的环境新建、伸缩和销毁等。业界常说的“基础设施即代码”即是这个目的，通过Puppet/Ansible等工具将环境的搭建转换成描述性的语言（维护环境配置文件），确保生产、类生产、测试甚至开发环境的搭建都经过充分的评审和测试并且实现自动化和可视化。虚拟化技术和Docker容器技术更使得基础设施的管理效率上了一个台阶，环境的扩容、伸缩和销毁代价更小，能够支撑的场景压力也大大增加。
环境管理是持续交付不可或缺的一环，是实现持续部署进而持续交付的基础。常用的工具包括Puppet/Ansible/Docker/K8s等，后面在总结持续部署时我们会再进行学习。