devops 中台
当我们想到大门时，我们会考虑要保护一些东西。 为了安全起见，闸门最常用于提供物理边界。 它们由金属，木材或塑料制成，甚至有时它们由软件制成。 它们使我们免于遭受破坏对我们重要的事情的不受欢迎的风险。
门对DevOps至关重要
在开始讨论之前，让我们退后一步，讨论DevOps实践在软件交付生命周期（SDLC）流程中的作用。 我相信DevOps的作用是负责并减少SDLC管理中固有的风险。 风险是从金钱到时间的所有关键业务因素中衡量的。 要更深入地了解与DevOps相关的SDLC，请阅读Bryant Son的文章DevOps管道 。
整套DevOps实践围绕其实践Struts进行工作：持续集成，持续部署/交付和持续监控。 建立这些Struts中的任何错误都会使您陷入麻烦的开发过程。 为了减轻这种情况，许多人建议在SDLC中的适当位置使用以下测试方法：
- 单元测试
- 整合测试
- 功能测试
- 渗透测试
- 验收测试
当需要对软件的质量和就绪性进行某种保证时，有人必须签字并说“继续”。 如果对测试进行了精心设计，则通过测试实际上意味着您的产品足够好，可以放在客户手中。
我们需要了解什么有关测试的信息，以适当地阻止客户过早更改我们的产品？
闸门的类型
盖茨必须进行更精确的测试和批准，以确保在不影响软件交付时间的情况下妥善处理SDLC流程。
我想讨论两种类型的闸门：手动和自动。
手动门
在某些组织中，对于产品质量保证（QA）工程师来说，即使测试产品的最基本功能也被认为是一项全职工作。 手动登机口要求QA团队成员签字，QA工程师进行一些测试，并证明该产品已准备好被推广到流程中的下一步，以交付客户使用。
手动批准
假设您有一个通过变更管理过程的发布过程。 在执行更改之前，您需要一个人（通常是更改经理）来审核和批准您的更改请求。
手动测试
手动批准后，质量检查工程师（或专门从事测试的职位）会根据更改手动运行测试。 他们的工作通常非常透彻，可以识别自动化测试难以检测到的挑战。
自动门
自动门使用软件来管理对软件开发下一步的批准。
自动化批准
假设您已经使用Hashicorp的Terraform编写了一个执行计划，以利用基础架构即代码的优势来提升基础架构的性能，但是您想验证是否已使用开发团队所需的数量和规格来创建资源。 通过运行terraform apply -input = false my_terraform_plan而不使用-auto-approve标志，您可以选择Terraform的内置交互式批准过程，该过程会提出一个需要您进行确认才能应用配置的门（有关Terraform工作流程的更多信息）。 您还可以使用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是可用于验证基础结构状态（从开放端口到已安装组件及其功能）的几种工具之一。
哪个门？
在深入研究何时登机之前，我们应该检查一下WHICH登机口。 为了理解上下文，让我们看一下传统的测试过程以及在为更多的审批和批准腾出空间之前要考虑的事项。
传统测试
下图显示了传统的测试过程，因为软件是使用SDLC中的敏捷过程交付的。 每个步骤的结果决定了您需要采取的行动，然后将代码重新放入循环中，并重复执行直到其质量足以交付给客户为止。
现代软件开发的速度和多样性带来了传统方法无法解决的新问题。 鉴于这种新范例，需要牢记以下几点：
- 跟踪测试代码覆盖率，以便您知道要测试的代码百分比，并可以对代码质量有所了解。
- 单元测试必须涵盖安全功能，例如在构建步骤之后生成的工件中的漏洞扫描。
- 集成和功能测试应包括将在其中部署软件的平台（例如Kubernetes）。
太多的自动化可能是不好的
不要忘记运行手动测试仍然很重要，因为有时过多的自动化会适得其反。 手动测试通常更容易上手，并且可以在您确定要确切测试什么，如何测试以及为何重要时进行调整。 直到您能回答自动化的内容，方式和原因，才是正确的解决方案。 它可能会过度设计您的测试，并使简单的事情看起来复杂。
限制大门
您不是要坐牢。 DevOps中的门控的目的是确保稳定的生产环境。 您只需要必要的门。 虽然很容易想到在将所有产品推广到生产环境之前都需要进行验证，但您还需要知道如何控制以及在何处放置大门，以免影响软件交付的时间表或使流程过分复杂。
例如，测试是否在云中运行：
- 当代码与其他组件集成在一起以创建软件包时，必须运行单元测试。
- 可以在基础结构旋转并首次准备好之后进行基础结构测试。
- 在平台上部署烟雾测试之后，它们必须在应用程序上运行。
- 一旦将应用程序部署在平台上，就可以完成网络扫描和渗透测试。
另外，请注意，在将工件（例如，容器运行时映像，虚拟机映像或软件档案）提升为生产之后，并非每次都需要本文中讨论的每种类型的批准或批准。
结论
门控一直是软件开发的一部分。 随着软件开发速度的提高，实现安全部署的策略已从手动控制转变为自动控制。 任一种类型的选通太多都会不利于发布稳定的代码（请记住既需要“释放”又需要“稳定”）。
没有至少一些自动化，很难达到这种门控水平。 尽可能使用“基础架构即编码”原则，并在基础架构上运行测试，以确保它与置于其之上的软件一样可靠。
接下来要读什么
翻译自: https://opensource.com/article/19/5/gating-production-devops
devops 中台
1082
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
