无论您仍在使用 Subversion (SVN)，还是已迁移到像 Git 这样的分布式系统，版本控制都在现代运维基础设施中找到了自己的位置。如果您听取会议上的演讲并了解新兴公司正在做什么，很容易认为现在每个人都在使用版本控制，并且有效地使用它。不幸的是，情况并非如此。我经常与完全不跟踪其基础设施变更的组织，或者没有以有效方式进行跟踪的组织互动。
如果您正在寻找说服您的老板花时间设置它的方法，或者只是在寻找一些技巧来改进如何使用它，以下是在运维中使用版本控制的五个技巧。
1. 使用版本控制
很久以前，在一个遥远的星系中，系统管理员会登录服务器并手动更改配置文件和重启服务。随着时间的推移，我们致力于自动化其中的大部分工作，以至于您的运维团队成员甚至可能没有登录服务器的权限。一切都可能通过您的配置管理系统或其他工具进行集中管理，以自动管理服务。无论您使用什么来处理基础设施中的配置和预期，您都应该拥有对其所做更改的历史记录。
拥有更改历史记录使您能够
- 通过将提交到存储库并部署的更改与中断、基础设施行为更改和其他问题进行匹配来调试问题。我们总是倾向于责怪开发人员造成问题，但这很诱人，但说实话，确实有极少数时候是我们的错。
- 了解更改的原因。一条好的提交消息（您应该坚持使用）不仅会解释更改正在执行什么操作，还会解释为什么要进行更改。这将帮助您未来的同事和您未来的自己理解为什么会做出某些架构更改。这些决定在当时可能是合理的，并且继续有意义，或者它们是基于不再适用于您组织的标准。通过跟踪这些原因，您可以利用过去的决策来做出今天更好的决策。
- 恢复到之前的状态。无论是对基础设施的更改导致问题并且您需要进行重大回滚，还是仅仅是在运行备份之前删除了文件，将生产更改存储在版本控制中都允许您及时回到已知状态以进行恢复。
对于一个组织来说，这第一步通常是最难的事情。您正在从静态配置或文件系统上的配置管理文件转移到版本控制系统，这改变了流程，并经常改变进行更改的速度。您的工程师需要知道如何使用版本控制，并习惯所有他们投入生产的更改都将被组织中的其他人跟踪的想法。
2. 制定计划，确定应将哪些内容放入版本控制
这有几个主要组成部分：确保您的基础设施中有多个针对特定服务的存储库；不要将自动生成的内容或二进制文件放入版本控制；并确保您安全地工作。
首先，您通常希望将服务的不同部分拆分到不同的存储库中。这允许对谁有权提交到特定服务存储库进行微调控制。它还可以防止存储库变得太大，这可能会使试图将其复制到系统上的系统管理员的生活复杂化。
您可能不相信存储库会变得非常大，因为它只是文本文件，但是当您已经使用存储库五年，并且每个副本都包含曾经做出的每个更改时，您会有不同的看法。让我向您展示 OpenStack 基础设施项目的 system-config 存储库。对该项目的首次提交是在 2011 年 7 月进行的
elizabeth@r2d2$:~$ time git clone https://git.openstack.org/openstack-infra/system-config Cloning into 'system-config'... remote: Counting objects: 79237, done. remote: Compressing objects: 100% (37446/37446), done. remote: Total 79237 (delta 50215), reused 64257 (delta 35955) Receiving objects: 100% (79237/79237), 10.52 MiB | 2.78 MiB/s, done. Resolving deltas: 100% (50215/50215), done. Checking connectivity... done. real 0m7.600s user 0m3.344s sys 0m0.680s
对于一个纯文本存储库来说，五年内的数据超过 10M。
再说一次，是的，纯文本。您通常要避免将二进制文件塞入版本控制。您通常不会获得这些文件的差异，它们只会使您的存储库膨胀。找到一种更好的方式来分发您的二进制文件。您也不希望将自动生成的文件放在版本控制中。将创建这些自动生成文件的配置文件放入版本控制，并让您的配置管理工具完成其工作以自动生成文件。
最后，将所有秘密数据拆分到单独的存储库中。组织可以从允许其所有技术人员查看其存储库中获得相当大的好处，但您不一定希望向所有人公开每个私有的 SSH 或 SSL 密钥。您还可以考虑在将来开源您的一些工具，因此从一开始就确保您的存储库中没有私有数据将防止以后出现很多麻烦。
3. 使其成为更改的规范位置，并从中部署
您的版本控制系统必须是您基础设施的中心部分。您不能只是在您记得的时候更新它，或者将其添加到您在生产环境中进行更改时应执行的操作清单中。任何人进行更改时，都必须在版本控制中跟踪它。如果没有，请提交一个错误，并确保将来将该配置文件添加到版本控制中。
这也意味着您应该从版本控制系统中跟踪的配置进行部署。除非在实际紧急情况下，并且您有严格的流程在紧急情况结束后尽快恢复正常，否则任何人都不应能够登录服务器并进行更改而无需通过版本控制。
4. 使用预提交脚本
人类非常健忘，我们系统管理员经常分心，并在一个非常受中断驱动的环境中工作。帮助自己，并为您的系统管理员提供一些脚本，以提醒他们更改消息应包含的内容。
这些提醒可能包括
- 您是否在提交消息中解释了更改的原因？
- 您是否包含了对与此更改相关的错误、工单、问题等的引用？
- 您是否更新了文档以反映此更改？
- 您是否为此更改编写/更新了测试？（请参阅本文末尾的奖励技巧）
作为奖励，这也记录了您的更改的审查者应该寻找什么。
等等，审查者？那是第 5 条。
5：将其全部挂钩到代码审查系统
现在您已经设置了一个健康的版本控制系统，您有了一个出色的平台来为系统管理员添加另一个很棒的工具：代码审查。这通常应该是一个同行评审系统，您所有级别的系统管理员都可以审查更改，并且您的更改将满足某些约定的合并标准。这允许整个团队对更改负责，而不仅仅是提出更改的人。我喜欢开玩笑说，由于我们团队的更改需要两个人批准，因此当出现问题时，这是三个人的错，而不仅仅是一个人！
刚开始时，您不需要做任何花哨的事情，也许只是让团队成员提交合并提案或拉取请求，并在社交上确保合并它的人不是提案人。最终，您可以研究更复杂的代码审查系统。大多数代码审查工具都允许诸如内联评论和讨论式评论之类的功能，这些功能提供了一种非对抗性的方式来向您的同事建议更改。对于可能不会面对面讨论更改，甚至可能不在同一时间醒来的远程分布式团队来说，这也非常有用。
奖励：对每次提交进行测试！
您已将所有内容都放在版本控制中，您让您的同伴审查了它，为什么不添加一些机器人呢？从简单的事情开始：计算机非常擅长确保文件按字母顺序排列，而人类则不然。计算机非常擅长确保语法正确（空格/制表符的数量是否正确？）；检查这些事情对您杰出的系统工程师来说是浪费时间。一旦您有了简单的测试，就开始添加单元测试、功能测试和集成测试，以便您确信您的更改不会在生产环境中崩溃。这也将帮助您找到您尚未自动化生产基础设施的地方，并首先在您的开发环境中解决这些问题。
4 条评论