成功地部署和发布软件系统，对于组织是一项重要任务，实现它就需要有坚定的 DevOps 战略。

长期以来，软件系统可靠地发布和部署一直是困难且耗时的过程。随着软件行业慢慢转向更快的发布节奏，部署和发布也变得越来越有价值，尤其是对于托管的软件。

DevOps 就是通过自动化来满足软件发布不断加速的节奏，因此不可避免地要面对挑战。本文将带你一起探讨如何应对挑战，实现 DevOps 的成功。


技巧1：让 DevOps 适应你的文化

“ Devops致力于寻找方法来适应和改革社会结构，文化和技术，以便更有效地开展工作。”
―Jennifer Davis和Ryn Daniels合著的《Effective Devops》

技巧2：对速度的需求

DevOps 频繁交付模型，意味着频繁的构建，测试和部署。团队规模和交付的节奏可能会对计算或网络资源造成巨大压力。无论是私有平台还是云平台，对流水线资源进行投资，都是至关重要的。

自动化的单元测试也至关重要，如果没有自动化的集成测试，就不可能真正了解系统状态。集成测试应包括端到端，安全性，负载和弹性的测试。这些可能是时间密集型的和资源密集型的，但是对于衡量交付质量至关重要。如果运行回归测试需要8个小时，那么你会可以创建虚拟测试环境。

技巧3：可用性

与性能齐头并进就是可用性。持续交付中的“持续”，意味着高可用的流水线。这就需要选择高可用组件，使他们能够在部分失效的情况下，重新或继续运行。

可以通过使用高度可用的系统，或使用无需用户干预进行扩展和修复的云端SaaS 解决方案，来实现可用性。CircleCI 和 Github Actions 是流行的 SaaS 服务，将提供高度可用的基于云的 DevOps 平台。两者都支持本地测试，以便你可以根据需要将云服务与本地环境混合在一起。

技巧4：收集和使用 DevOps 指标

“如果无法衡量，就无法改善。”
– 彼得·德鲁克

像任何软件系统一样，DevOps 流水线本身也需要随着时间的推移而发展和改进。

为了适应不断变化的环境，必须经常对执行自动测试和交付的系统进行测量和改进。针对诸如测试时间性能（单位和回归），故障率，成本（如果是云托管）和实际可用性（停机）之类的指标，进行评估。

这些指标也与业务指标相关联，例如交货时间，部署频率和平均恢复时间（从故障中恢复）。DevOps工具链的性能是所有这些的基础。

技巧5：关注有意义的测试

“追求测试覆盖率指标的组织，应该做些更有用的事情”
―马丁·福勒（Martin Fowler）

常见的开发测试指标是“代码测试覆盖率”。此度量标准的目的是确定对代码中潜在逻辑路径进行了多少百分比的测试。因此，它们是指出哪些代码需要被更正的一种很好的工具。当然，他们仅限于分析给出的代码，没有告诉你应该编写什么代码来处理某些情况，例如，他们不会告诉你异常处理不充分，或者你忽略了处理特定的返回状态。

倾向于使用特定的代码覆盖率，这是一个错误，因为开发人员在承受压力时会以牺牲质量为代价来提高覆盖率。测试覆盖范围不是代码质量的实际度量，它所提供的是对开发人员检查其工作的方法。

良好的测试覆盖范围应该是目标，而不是硬性限制。为了捕获那些“遗漏错误”，强大的集成测试功能可以提供帮助。

为了安全和可用性起见，我们应该知道所有代码都不相等。广泛重复使用的代码或可能执行破坏性行为（例如删除客户数据）的代码需要更高级别的测试覆盖范围和审查。编写测试非常耗时，需要首先全面地关注关键代码。

为了对自动化测试结果充满信心，集成测试环境应尽可能模拟生产环境。在托管应用程序的情况下，这可能非常简单，而在本地环境中，复杂性几乎是无限的。目标环境越复杂，越多样化，就需要进行更多的测试。

总结

DevOps 的基本目标是简化向客户交付产品的过程。它试图打破开发人员和运维人员之间的传统障碍，以实现软件功能的频繁发布和错误修复。频繁交付的能力需要高度的自动化，尤其是端到端的测试。

虚拟化技术的一大优势是能够启动服务器和网络配置的任意集合（测试沙箱）。使用适当的编排工具，可以按需配置测试环境，从而大大增加了测试面积，并实现了自动化。（转自王延飞）

成功地部署和发布软件系统，对于组织是一项重要任务，实现它就需要有坚定的 DevOps 战略。

长期以来，软件系统可靠地发布和部署一直是困难且耗时的过程。随着软件行业慢慢转向更快的发布节奏，部署和发布也变得越来越有价值，尤其是对于托管的软件。

DevOps 就是通过自动化来满足软件发布不断加速的节奏，因此不可避免地要面对挑战。本文将带你一起探讨如何应对挑战，实现 DevOps 的成功。


技巧1：让 DevOps 适应你的文化

“ Devops致力于寻找方法来适应和改革社会结构，文化和技术，以便更有效地开展工作。”
―Jennifer Davis和Ryn Daniels合著的《Effective Devops》

技巧2：对速度的需求

DevOps 频繁交付模型，意味着频繁的构建，测试和部署。团队规模和交付的节奏可能会对计算或网络资源造成巨大压力。无论是私有平台还是云平台，对流水线资源进行投资，都是至关重要的。

自动化的单元测试也至关重要，如果没有自动化的集成测试，就不可能真正了解系统状态。集成测试应包括端到端，安全性，负载和弹性的测试。这些可能是时间密集型的和资源密集型的，但是对于衡量交付质量至关重要。如果运行回归测试需要8个小时，那么你会可以创建虚拟测试环境。

技巧3：可用性

与性能齐头并进就是可用性。持续交付中的“持续”，意味着高可用的流水线。这就需要选择高可用组件，使他们能够在部分失效的情况下，重新或继续运行。

可以通过使用高度可用的系统，或使用无需用户干预进行扩展和修复的云端SaaS 解决方案，来实现可用性。CircleCI 和 Github Actions 是流行的 SaaS 服务，将提供高度可用的基于云的 DevOps 平台。两者都支持本地测试，以便你可以根据需要将云服务与本地环境混合在一起。

技巧4：收集和使用 DevOps 指标

“如果无法衡量，就无法改善。”
– 彼得·德鲁克

像任何软件系统一样，DevOps 流水线本身也需要随着时间的推移而发展和改进。

为了适应不断变化的环境，必须经常对执行自动测试和交付的系统进行测量和改进。针对诸如测试时间性能（单位和回归），故障率，成本（如果是云托管）和实际可用性（停机）之类的指标，进行评估。

这些指标也与业务指标相关联，例如交货时间，部署频率和平均恢复时间（从故障中恢复）。DevOps工具链的性能是所有这些的基础。

技巧5：关注有意义的测试

“追求测试覆盖率指标的组织，应该做些更有用的事情”
―马丁·福勒（Martin Fowler）

常见的开发测试指标是“代码测试覆盖率”。此度量标准的目的是确定对代码中潜在逻辑路径进行了多少百分比的测试。因此，它们是指出哪些代码需要被更正的一种很好的工具。当然，他们仅限于分析给出的代码，没有告诉你应该编写什么代码来处理某些情况，例如，他们不会告诉你异常处理不充分，或者你忽略了处理特定的返回状态。

倾向于使用特定的代码覆盖率，这是一个错误，因为开发人员在承受压力时会以牺牲质量为代价来提高覆盖率。测试覆盖范围不是代码质量的实际度量，它所提供的是对开发人员检查其工作的方法。

良好的测试覆盖范围应该是目标，而不是硬性限制。为了捕获那些“遗漏错误”，强大的集成测试功能可以提供帮助。

为了安全和可用性起见，我们应该知道所有代码都不相等。广泛重复使用的代码或可能执行破坏性行为（例如删除客户数据）的代码需要更高级别的测试覆盖范围和审查。编写测试非常耗时，需要首先全面地关注关键代码。

为了对自动化测试结果充满信心，集成测试环境应尽可能模拟生产环境。在托管应用程序的情况下，这可能非常简单，而在本地环境中，复杂性几乎是无限的。目标环境越复杂，越多样化，就需要进行更多的测试。

总结

DevOps 的基本目标是简化向客户交付产品的过程。它试图打破开发人员和运维人员之间的传统障碍，以实现软件功能的频繁发布和错误修复。频繁交付的能力需要高度的自动化，尤其是端到端的测试。

虚拟化技术的一大优势是能够启动服务器和网络配置的任意集合（测试沙箱）。使用适当的编排工具，可以按需配置测试环境，从而大大增加了测试面积，并实现了自动化。（转自王延飞）