当我们想到门控时，我们会想到保护某些东西。门控最常用于为安全提供物理边界。它们由金属、木材或塑料制成，有时甚至由软件制成。它们使我们免受损害对我们重要的东西的意外风险。
门控对于 DevOps 至关重要
在我们深入探讨门控之前，让我们退后一步，讨论 DevOps 实践在软件交付生命周期 (SDLC) 过程中的作用。我认为 DevOps 的作用是负责并降低 SDLC 管理中固有的风险。这种风险以所有关键业务因素来衡量，从金钱到时间。要深入了解 SDLC 与 DevOps 的关系，请阅读 Bryant Son 关于 DevOps 管道的文章。
整套 DevOps 实践围绕其实践支柱展开：持续集成、持续部署/交付和持续监控。在设置这些支柱中的任何一个时犯的任何错误都会使您陷入麻烦的开发过程。为了缓解这种情况，许多人建议在 SDLC 的适当位置使用以下测试方法
- 单元测试
- 集成测试
- 功能测试
- 渗透测试
- 验收测试
当需要对软件的质量和就绪状态进行某种保证时，必须有人签字并说“继续”。当测试设计良好时，通过测试实际上意味着您的产品足够好，可以交付到客户手中。
关于测试，我们需要了解什么才能适当地阻止客户过早地更改我们的产品？
门控的类型
门控必须涉及更精确的测试和批准，以确保 SDLC 过程得到妥善处理，而不会影响软件交付时间。
我想讨论两种类型的门控：手动和自动化。
手动门控
在某些组织中，即使是产品最基本的功能的测试也被认为是质量保证 (QA) 工程师的全职工作。手动门控需要 QA 团队成员签字，QA 工程师运行一些测试并证明产品已准备好提升到流程中的下一步，以便交付到客户手中。
手动批准
假设您的发布流程需要经过 变更管理 流程。在您执行更改之前，您需要某人（通常是变更经理）审查并批准您的变更请求。
手动测试
在手动批准之后，QA 工程师（或专门负责测试的类似职位）手动对更改运行测试。他们的工作通常非常 thorough，可以识别出使用自动化测试难以检测到的挑战。
自动化门控
自动化门控使用软件来管理对软件开发中下一步的批准。
自动化批准
假设您使用 Hashicorp 的 Terraform 编写了一个执行计划来启动您的基础设施，利用基础设施即代码的优势，但您想验证是否已按照开发团队要求的数量和规范创建了资源。通过运行 terraform apply -input=false my_terraform_plan 而不使用 -auto-approve 标志，您将选择 Terraform 的内置交互式批准流程，该流程设置了一个门控，在应用配置之前需要您的确认（有关 Terraform 工作流程 的更多信息）。您还可以使用 Jenkins pipeline: input step 插件在 terraform plan 之后等待您的批准，然后再应用配置。Jenkins 是一种常见的 DevOps 管道工具，可以减少这些流程中的摩擦。
自动化测试
我们在补丁通过门控之前可以进行的测试越多越好。自动化测试增加了更新按我们预期工作的可能性。假设您通过向代理服务器 Nginx 发送新的配置文件来更新您的基础设施。如果您运行类似 InSpec 的工具来验证 Nginx 状态是否会是部署后您期望的状态，那么您可以提前知道更新将按设计工作
describe service('nginx') do
it { should be_enabled }
it { should be_installed }
it { should be_running }
end如果 InSpec 抛出异常，您就知道更新后的配置对于生产环境来说是不安全的，并且您的门控有效地支持了客户对安全部署的需求。
在另一个示例中，假设您部署了一个 Docker Swarm 集群，并且需要验证名为 myservice 的服务。以下是此场景的 InSpec 代码
describe docker_service(myservice) do
it { should exist }
its('ports') { should include '*:8080->8080/tcp' }
its(‘repo’) { should eq 'alpine' }
its('tag') { should eq 'latest' }
en这些是集成测试和功能测试的示例，尽管两者之间的界限经常被争论。InSpec 是一个强大的开源工具，可以实现声明式测试策略，并且它可以与 Terraform、Ansible 和 Chef 等标准自动化工具一起使用。InSpec 是多种可用于验证基础设施状态的工具之一，从开放端口到已安装的组件及其功能。
选择哪些门控？
在我们进一步深入探讨何时进行门控之前，我们应该检查选择哪些门控。为了理解上下文，让我们看看传统的测试流程以及在为更多门控和批准腾出空间之前需要考虑的事项。
传统测试
下图显示了在 SDLC 中使用敏捷流程交付软件时的传统测试流程。每个步骤的结果决定了您需要采取的操作，然后您将代码放回循环中，并重复此过程，直到它变得足够好以交付给客户。
现代软件开发的速度和多样性创造了传统方法无法处理的新问题。考虑到这种新范例，需要牢记以下几点
- 跟踪测试代码覆盖率，以便您了解正在测试的代码百分比，并可以了解代码质量。
- 单元测试必须涵盖安全功能，例如在构建步骤后生成的工件中的漏洞扫描。
- 集成测试和功能测试应包括软件将要部署的平台（例如，Kubernetes）。
过多的自动化可能是不好的
不要忘记运行手动测试仍然很重要，因为有时过多的自动化可能会适得其反。手动测试通常更容易上手，并且它可以随着您弄清楚您到底想测试什么、如何测试以及为什么重要而进行调整。在您可以回答是什么、如何和为什么之前，自动化不是正确的解决方案；它可能会过度设计您的测试，并使简单的事情看起来复杂。
限制门控
您不是在建造监狱。DevOps 中门控的目标是确保稳定的生产环境。您只需要必要的门控。虽然认为在所有内容提升到生产环境之前都需要验证的想法很诱人，但您还需要知道如何控制门控以及在何处放置门控，以便它们不会影响软件交付时间表或使流程过于复杂。
例如，测试是否在云中运行
- 当代码与其他组件集成以创建软件包时，必须运行单元测试。
- 基础设施测试可以在基础设施启动并首次准备就绪后完成。
- 冒烟测试必须在应用程序部署到平台后在应用程序上运行。
- 网络扫描和渗透测试可以在应用程序部署到平台后进行。
另请注意，并非本文中讨论的每种类型的批准或门控在工件（例如，容器运行时映像、虚拟机映像或软件存档）提升到生产环境后每次都是必需的。
结论
门控一直是软件开发的一部分。随着软件开发速度的加快，实现安全部署的策略已从手动门控转向自动化门控。任何一种类型的门控过多都可能与发布稳定代码的目标背道而驰（请记住，这既需要“发布”又需要“稳定”）。
如果没有至少某种程度的自动化，就很难实现这种程度的门控。尽可能使用基础设施即代码原则，并在您的基础设施上运行测试，以确保它与您在其上放置的软件一样可靠。
4 条评论