DevOps 的五个最佳实践

DevOps和持续交付是软件开发的重要理念。如果我们想要不断地向用户交付有价值的软件，我们就必须认真对待 DevOps 的思想。

下面是五个在实际项目中应用DevOps的最佳实践，其中一些可能会让你感到惊讶。

我是《持续交付2.0》的作者，乔梁。今天我们将探讨 DevOps 的重要性。如果你觉得这很有趣，请订阅本公众号，以便随时获取新的内容。

我相信，持续交付是高性能、高质量软件开发的驱动力，也代表了软件开发实践中的最先进水平。虽然大家可能使用不同的术语来描述这个理念，但它确实是我们行业中最新的趋势之一，也是更好的工作方式。

《DevOps报告》和《加速》这本书提供了相关模型的证据，使我们能够对软件开发团队的行为和成功的可能性做出预测。

我喜欢这些研究因为它们提供了有据可依的证据，而不是过度夸大的口号。如果你实践了某些实践方法，它们可能会带来更好的结果。

然而，伟大的软件仍然需要才华横溢和聪明的人才，没有什么简单的解决方案可以取代这些人的创造力和努力。

如前所述，以下是关于成功 DevOps的五种最佳实践，这些预测结果中的一些非常重要。

（图片来源于网络）

我们可以使用自动化测试来安全地将更改发布到生产中，而不需要手动回归测试。许多组织有效地使用这样的测试，但这些测试通常是缓慢、低质量、昂贵、不可靠且容易出错的。它们导致测试用例难以理解，从而影响了测试的质量。

相反，我们应该采用一种详尽的自动化测试策略，测试系统的每个行为，以便评估其质量。这很重要，因为人类不善于做重复的事，人们做重复的事情是很不可靠的，而计算机却擅长这些任务。我们应该让计算机来处理这些事情，让人类专注于探索和评估复杂决策过程中的混合信息，这是人类的亮点。

我们应该能够只按一个按钮就部署到测试或生产环境。这是一个简单的过程，但涉及到我们过程的重复性和可靠性。如果我们想要可靠地并重复地将我们的软件部署到我们想要的任何位置，我们需要能够理解、声明和控制环境中的变量和软件的依赖关系。

我想了解这个特定的候选版本是否能够与环境配置相兼容。我们开始使用自动化部署，并很快将基础架构代码化，并自动化了所有这些任务。

无论你将其称为什么，每天至少合并一次代码变更到主干是至关重要的。根据 2015年的DevOps报告，基于主干的开发可以带来更高的吞吐量、更好的稳定性、更高的工作满意度和更低的疲劳率。

我们发现，将生命周期很短（比如只有一天）的分支合并到主干，并保持不超过三个活动分支，是持续交付的重要方面，这些都有助于提高绩效。

虽然每天将代码合并到主干或主干中并不是必须的，但Linus（创造Git的人）曾经说过，如果你每天频繁地合并，就不会遇到巨大的合并冲突，这些冲突很难解决。

因此，基于主干的开发是一个重要的想法。

也可以说是：在部署流水线中包含包括所有的安全测试和验证。虽然这还是一个有争议的话题，因为目前来说，「安全」意味着慢下来。我没有数据，但我认为这是一个更广泛问题的症状而已。因为，我们原来的软件生产过程就是使用时间比较滞后的大规模审查。

首先是「左移」术语。我们所说的左移的意思是我们试图缩短反馈循环。我们试图使学习更接近任何事情发生的原点。这个术语比较狭隘，因为它是基于从左到右的读者。实际上，它说的是：它正在向事情的源头移动。所以我们希望在过程的更早阶段进行安全测试。这样我们可以更快地学习。当然，我认为这是一个更广泛的问题，涉及的组织和角色会更多。

对于部署流水线的描述是：它从代码提交到可发布结果自动化且可视化的过程，无论构成可发布的结果是什么，这都是一个公平的游戏。所以我们应该努力优化，以获得关于该过程内的任何活动的最佳反馈。

无论它决定了什么，我们将在部署流水线周期内评估我们软件的发布能力。所以安全性当然是这个属性的一个属性。当然，合规性、可伸缩性、弹性和许多其他方面，这些重要的功能也是如此。所以我认为这是绝对正确的。

然而，我认为，当在 DevOps 的状态下对这个问题进行采样时，人们更关注的是安全性，而不是构成我们软件可发布性的所有东西。

我们可以在系统的一个部分进行更改，而不需要在再次发布到生产之前测试整个系统。我并不反对这一点，我认为这是一种绝对有效的方法。

以这种思想作为划分软件系统的驱动器，是高效软件工程师的一个非常好的属性，即：流程快速、高效、高质量的反馈。你可以通过两种方式实现这一点。

你可以将系统分解为可独立部署的模块。每个模块都更小、更简单，更容易构建、测试和评估。这种模型使构建、测试和部署各个部分非常有效。

但在争取更分布的体系结构的过程中，还有另一个完美可行的替代方案，人们经常会错过它。即：我们也可以选择同时构建、测试和部署所有的内容。当然，这种方法需要在部署流水线中投入大量资金，最终可能会得到一个更复杂的部署流水线，以便为你提供所需的速度和质量的反馈。这种更大规模的软件实际上是一种非常可伸缩的技术，需要足够的反馈，以便你仍然可以每天多次清楚地了解你的进度。

将你的体系结构分解为更小、更独立的单元确实是为了实现这一目标进行优化，但是评估你的系统也是如此。很可能需要在更大的范围内对其进行足够有效的评估。

这两种策略之间存在权衡，但它们都是同样可行的。如果你能有效地管理好所有这些实践，就会取得很好的进展，并将能够保持你的系统质量在顶端。