当我们想到“门”时，我们想到的是保护某物。门最常用于为安全提供物理边界。它们由金属、木材或塑料制成，有时甚至由软件制成。它们使我们免受损害对我们重要的东西的意外风险。
门对于 DevOps 至关重要
在深入探讨“门”之前，让我们退后一步，讨论 DevOps 实践在软件交付生命周期 (SDLC) 过程中的作用。我认为 DevOps 的作用是负责并降低 SDLC 管理中固有的风险。这种风险以所有关键业务因素衡量，从金钱到时间。要深入了解 SDLC 与 DevOps 的关系，请阅读 Bryant Son 关于 DevOps 管道的文章。
整套 DevOps 实践都围绕其实践支柱展开：持续集成、持续部署/交付和持续监控。在设置这些支柱中的任何一个时犯的任何错误都会使您陷入麻烦的开发过程。为了缓解这种情况，许多人建议在 SDLC 的适当位置使用以下测试方法
- 单元测试
- 集成测试
- 功能测试
- 渗透测试
- 验收测试
当需要对软件的质量和就绪性进行某种保证时，必须有人签字并说“继续”。当测试设计良好时，通过测试实际上意味着您的产品足够好，可以交付给客户。
关于测试，我们需要了解什么才能适当地阻止客户过早地更改我们的产品？
门的类型
门必须涉及更精确的测试和批准，以确保 SDLC 过程得到良好照顾，而不会影响软件交付时间。
我想讨论两种类型的门：手动门和自动门。
手动门
在某些组织中，即使是产品最基本功能的测试也被认为是质量保证 (QA) 工程师的全职工作。手动门需要 QA 团队成员签字，QA 工程师运行一些测试并证明产品已准备好提升到流程中的下一步，以便交付给客户。
手动批准
假设您的发布过程经历了 变更管理 过程。在执行变更之前，您需要某人（通常是变更经理）审查并批准您的变更请求。
手动测试
在手动批准后，QA 工程师（或专门负责测试的类似职位）手动对变更执行测试。他们的工作通常非常彻底，可以识别出自动测试难以检测到的挑战。
自动门
自动门使用软件来管理对软件开发下一步的批准。
自动批准
假设您使用 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 条评论