DevOps中的闸门生产[DevOps]

DevOps就是在不降低人员速度的前提下平衡风险。

图片来源：opensource.com

当想到闸门时，会考虑要保护一些东西。为了安全起见，闸门最常用于提供物理边界。它们由金属，木材或塑料制成，甚至有时由软件制成。使我们免于遭受重要事情破坏的不速而至的风险。

闸门对DevOps至关重要

在这之前，让我们来讨论DevOps实践在软件交付生命周期（SDLC）流程中的作用。我相信DevOps的作用是负责并减少SDLC管理中固有的风险。此风险是从金钱到时间的所有关键业务因素中衡量的。要更深入地了解与DevOps相关的SDLC，请阅读Brian Son关于DevOps管道的文章。

整套DevOps实践围绕其实践支柱进行工作：持续集成，持续部署/交付和持续监控。建立这些支柱中的任何错误都会使您陷入麻烦的开发过程。为了减轻这种情况，许多人建议在SDLC中的适当位置使用以下测试方法：

1.单元测试

2.整合测试

3.功能测试

4.渗透测试

5.验收测试

当需要对软件的质量和就绪性进行某种程度的保证时，有人必须验收并说“继续”。如果对测试进行了精心设计，则通过测试实际上意味着产品足够好，可以放在客户手中。

为了使客户免受产品过早更改的影响，需要了解什么测试？

闸门的类型

闸门必须进行更精确的测试和批准，以确保在不影响软件交付时间的情况下妥善处理SDLC流程。

我想讨论两种类型的闸门：手动和自动。

手动门

在某些组织中，对于产品质量保证（QA）工程师来说，即使测试产品的最基本功能也被认为是一项全职工作。手动门需要QA团队成员验收，QA工程师进行一些测试，并证明该产品已准备好被推广到过程中的下一步，以交付客户使用。

手动批准

假设有一个通过变更管理的发布过程。在执行更改之前，需要一个人（通常是更改经理）来审核和批准更改请求。

手动测试

手动批准后，质量检查工程师（或从事测试的类似职位）会根据更改手动运行测试。他们的工作通常非常透彻，可以发现自动化测试难以发现的挑战。

自动门

自动门使用软件来管理对软件开发下一步的批准。

自动化批准

假设已经使用Hashicorp的Terraform编写了一个执行计划，以利用基础架构即代码的优势来提升基础架构的性能，但是想验证是否已使用开发团队所需的数量和规格来创建资源。通过运行terraform apply -input = false my_terraform_plan而不使用-auto-approve标志，您将选择Terraform的内置交互式批准过程，该过程会提出一个需要进行确认才能应用配置的闸门（有关Terraform工作流程Terraform workflow的更多信息）。还可以使用Jenkins管道：输入步骤插件在terraform计划之后等待批准，然后再应用配置。 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）。

过多自动化是不好的

不要忘记运行手动测试仍然很重要，因为有时过多的自动化会适得其反。手动测试通常更容易入门，并且可以在确定要确切测试什么，如何测试以及为什么重要时进行调整。在不能回答自动化的内容，方式和原因之前，不是正确的解决方案。它可能会过度设计测试，并使简单的事情看起来很复杂。

限制闸门

不是搭建jail。 DevOps中的gating目的是确保稳定的生产环境。只需要必要的闸门。虽然很容易想到在将所有产品推广到生产环境之前都需要进行验证，但还需要知道如何控制以及在何处放置闸门，以免影响软件交付时间表或使流程过分复杂。

例如，测试是否在云中运行：

当代码与其他组件集成在一起以创建软件包时，必须运行单元测试。

可以在基础结构旋转并准备就绪后进行基础结构测试。

冒烟测试在平台上部署后必须在应用程序上运行。

一旦将应用程序部署在平台上，就可以完成网络扫描和渗透测试。

另外，请注意，在将工件（例如，容器运行时映像，虚拟机映像或软件档案）提升为生产后，并非每次都需要本文讨论的每种类型的批准或批准。

结论

Gating一直是软件开发的一部分。随着软件开发速度的提高，实现安全部署的策略已从手动控制转变为自动控制。任一种类型的选通太多都会不利于发布稳定的代码（请记住，既需要“释放”又需要“稳定”）。

没有至少一些自动化，很难达到这种水平的门控。尽可能使用“基础架构即编码”原则，并在基础架构上运行测试以确保其可靠性与安装在其之上的软件一样可靠。