无论您仍然使用 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 条评论