DevOps 技术：版本控制

注意：“版本控制”是一组推动实现更出色的软件交付表现和组织绩效的能力之一。这些能力是由 DORA DevOps 现状研究项目发现的，这是一项针对提升绩效的做法和能力进行的具有学术意义的独立而严谨的调查。如需了解详情，请阅读我们的 DevOps 资源。 

利用 Git、Subversion 和 Mercurial 等版本控制系统，您可以采用逻辑方式整理文件，以及跨团队和组织协调文件的创建、受控访问、更新及删除机制。版本控制与自动化作业密切相关。实际上，自动化作业和持续集成依赖这些文件来处理自动化作业本身的源代码，以及要自动执行的配置和要分发的数据。

为了改善软件交付，团队需要对源代码、测试和部署脚本、基础架构和应用配置信息以及它们所依赖的众多库和软件包使用版本控制。 在版本控制系统中，团队必须能够查询其环境的当前（和历史）状态。 版本控制还具有一些直接优势，例如灾难恢复和可审核性。

研究表明，除了其他方面的功能以外，全面采用版本控制可预测持续交付。具体来说，版本控制可帮助您满足以下关键要求：

• 可再现性。团队必须能够以完全自动化的方式预配任何环境，并且清楚基于相同配置再现的所有新环境都完全一样。实现此目标的前提条件是将预配环境所需的脚本和配置信息存储在可访问的共享系统中。

• 可追溯性。团队应该能够选择任何环境，并快速准确地确定创建该环境所用各依赖项的版本。他们还应该能够比较同一环境的两个版本，并发现二者之间的不同之处。

这些功能会为团队带来多项重要好处，具体如下：

• 灾难恢复。如果环境出现问题（例如硬件故障或安全漏洞），团队需要能够在确定的时间内重现该环境，以便能够恢复服务。

• 可审核性。为了证明交付流程的完整性，团队必须能够提供从每个部署到其来源元素（包括其版本）的反向路径。您可以通过将全面配置管理与部署流水线相结合来实现此目的。

• 提升质量。软件交付流程通常需要等待准备开发、测试和生产环境，因此会出现长时间延迟现象。如果可以通过版本控制自动完成这项准备工作，团队就能够更快地了解其变更所带来的影响，从而便可构建高质量的软件。

• 容量管理。如果团队想要向其环境中添加更多容量，那么就需要能够再现现有服务器。这种功能可让现代云分布式系统实现横向扩缩。

• 应对缺陷。如果团队发现其系统的某个组件存在严重缺陷或漏洞，他们需要尽快发布其软件的新版本。将所有工件存储在版本控制中后，团队可快速、可靠地回滚到先前已经过验证的工作状态。

随着环境变得越来越复杂和多样化，这些目标也逐渐变得更难以实现。对于复杂的企业系统（至少，每个实际系统都是有状态的系统），不可能实现完美的可再现性和可追溯性。因此，配置管理的关键在于简化架构、环境和流程，进而减少实现预期收益所需的投资。

如何实现版本控制

实现版本控制时，我们建议您首先用可度量的术语来定义要实现的目标。这样一来，您和您的团队就能够确定实现这些目标的最佳途径。此外，通过这种方法，如果您选择的途径成本太高或花费时间太长，您还可以改变方向或重新评估这些目标。

版本控制系统会记录对系统中所存储文件的更改。这些文件可以是源代码、资源，也可以是软件开发项目中可能包含的其他文档。团队可以对“提交”或“修订版本”组进行更改。每个修订版本及其相关元数据（例如更改者和更改时间）都会存储在系统中。这不但使团队能够执行提交、比较、合并和恢复到先前修订版本的操作，还能够将生产环境中的对象还原到先前版本，从而最大限度地降低风险。

即使发生灾难性事件，团队也必须能够以重复、可预测（且在理想情况下快速）的方式恢复生产服务，因此他们必须将以下资源签入其共享版本控制代码库中：

• 所有应用代码和依赖项（例如库和静态内容）
• 任何用于创建数据库架构、应用引用数据等的脚本
• 前面步骤中所述的所有环境创建工具和工件（例如，VMware 或 AMI 映像构建脚本或 Chef 配方）
• 用于创建和编写容器的任何文件（例如 Docker 文件和 buildpack）
• 所有辅助性自动化测试和任何手动测试脚本
• 任何支持代码封装、部署、数据库迁移和环境预配的脚本
• 辅助性项目工件（例如要求文档、部署程序和版本说明）
• 容器编排（例如 Kubernetes 配置、Mesos 配置和 Docker Swarm 配置）
• 所有云配置文件（例如 AWS Cloudformation 模板、Cloud Deployment Manager 配置、Microsoft Azure Stack DSC 文件、OpenStack HEAT、Terraform 文件和 Pulumi 堆栈）
• 创建支持多项服务（例如企业服务总线、数据库管理系统、DNS 地区文件、防火墙配置规则及其他网络设备）的基础结构所需的任何其他脚本或配置信息

除了传统的文件式版本控制系统（如 Git）之外，版本控制还可以采用其他多种形式。团队可以使用多个代码库来存储有版本控制、标签和标记的各种对象和服务及其源代码。例如，团队可以将大型虚拟机映像、ISO 文件、编译的二进制文件等存储在 Nexus 或 Artifactory 等工件代码库中，也可以将对象放入 blob 存储区（例如 Cloud Storage 或 Amazon S3）中，或将 Docker 映像放入 Docker 注册表中。这些方法满足可再现性和可追溯性的要求，并会带来同样的优势。

团队不仅必须能够重新创建生产环境的任何先前状态，而且还必须能够重新创建预生产和构建流程。 因此，他们还需要将其构建流程所依赖的所有内容（包括其所依赖的工具和环境）签入版本控制中。

版本控制中常见的隐患

使用版本控制时，最常见的隐患是应用或使用限制；也就是说，版本控制仅适用于软件应用代码。最佳做法要求能够使用版本控制中存储的脚本、源代码和配置信息，以完全自动化的方式再现所有测试和生产环境，包括其中部署的软件。

改善版本控制的方法

您可以通过多种方式改善版本控制。以下是我们推荐的几种方法：

• 确保每次对版本控制执行提交操作都会触发系统自动创建软件包，这些软件包可以仅使用版本控制中的信息部署到任何环境。
• 可以仅使用版本控制中的脚本和配置信息按需创建类似生产的测试环境，并使用前一方法中所述的自动化流程创建软件包。
• 使用脚本测试和生产基础架构，使团队能够以完全自动化的方式增加容量或进行灾难恢复。

在实现版本控制系统时，请注意您受到的各种限制。例如，从版本控制快速切换到生产环境时，最大的阻碍是什么？您的构建速度是否太慢？是否难以重新创建可部署的软件包？是否难以创建类似生产的测试环境？这些限制可能使您难以实现目标，并且可能表明系统架构存在问题。

版本控制的度量方法

如需度量您的团队在其系统中运用版本控制的效果，请尝试以下建议：

• 应用代码。您是否在应用代码中使用了版本控制？ 存储在版本控制中的应用代码占多少百分比？ 团队从版本控制系统中恢复应用代码的轻松程度和速度如何？

• 系统配置。您是否在系统配置中使用了版本控制？存储在版本控制中的系统配置占多少百分比？团队从版本控制中重新配置系统的轻松程度和速度如何？

• 应用配置。您是否在应用配置中使用了版本控制？存储在版本控制中的应用配置占多少百分比？团队从版本控制系统中的代码重新配置应用的轻松程度和速度如何？

• 用于自动执行构建和配置的脚本。 您是否在版本控制中保留了用于自动执行构建和配置的脚本？存储在版本控制中的脚本占多少百分比？使用版本控制中的脚本重新预配系统的速度和轻松程度如何？

这些建议仅仅只是开始，但极其重要，因此我们建议您从此处入手，了解实现这一目标的正确方法。然后请查看本文中的说明，确定您在开发和交付软件过程中使用的其他工件，并提出类似的问题：这些工件中有多大比例存储在版本控制中？您的团队使用版本控制中的资源部署新系统或配置的速度和轻松程序如何？