在本文的第一部分中，我们解释了为什么 DevOps 是现代技术组织最重要的战略。为了更多地了解 DevOps 的使用情况，我们发起了 2019 年 Drupal 社区 DevOps 调查，该调查正在收集数据，直到我们在 4 月 10 日的 DrupalCon 上展示结果。该调查要求 Drupal 社区成员使用李克特量表评估其团队在 24 个 DevOps 维度上的表现。
调查中的每个维度都会被评分，在所有受访者中取平均值，然后汇总成一个总分。每个 DevOps 维度也会被评分，并且可以根据其对团队的价值以及团队如何开始或改进它进行单独考虑。即使在我们撰写本文时调查仍在进行中，但结果（随着回复的到来而更新）似乎已经在 Drupal 社区中趋于稳定。
Drupal 社区在使用 DevOps 实践方面一直徘徊在 60 多分的水平。虽然真正的价值在于团队跟踪其高层次的长期改进，但可以粗略地理解为 Drupal 社区感觉它在 DevOps 实践方面比有时更一致一些。
一个快速获胜的机会：快速发布代码
如果我们扫描结果以寻找高影响、易于获胜的机会，我们可能会选择类似这样的问题
在任何时候，安全且有可能将代码发布到生产环境的频率有多高？
83% 的团队在这项高影响力的 DevOps 维度上进展顺利，并且没有太多需要改进的地方。这意味着，对于许多人来说，这是一个已解决的问题——通过一些快速学习和积极性，任何团队都可以在这个维度上实现一致性。
为什么保持一致性很重要
我们可能都经历过将某种关键错误发布到生产环境的经历。生产环境最终出现故障是不可避免的，DevOps 优先考虑快速行动，而不是不惜一切代价避免故障。在这种情况下，“快速行动”意味着能够立即发布热修复程序来解决问题。如果您在主分支上有无法 100% 确定已准备就绪的更改，则这是不可能的。
如何开始
很难超越 GitFlow 模型来确保可以随时修复生产环境。GitFlow 将未发布的工作保留在单独的分支（通常称为“develop”）上，直到部署为止。仅当部署时才将其合并到主分支（通常为“master”）。这使得 master 分支始终保持干净，以便进行热修复，并允许您在热修复期间遵循正常发布过程的缩减版本。
入门意味着学习版本控制并使用它（如果您尚未这样做——近 100% 的 Drupal 受访者报告说在其工作中始终如一地使用版本控制）。从那里开始，将您网站的大部分配置放入代码也很重要，例如，D7 的 Features 或 D8 中的配置管理，以便可以将所有工作拉到一起供团队中的其他人审查。最后，实施基本的持续集成 (CI) 以运行您的测试套件，以及持续交付 (CD) 到预览环境以进行可视化审查，将使您正在进行的特性开发与生产管道分离，并允许更战略性地部署就绪分支或热修复程序，而不会危及 master 分支的一致性。
幸运的是，存在许多以这种方式使用 Drupal 的服务，并且可以学习和实施到基本程度，而无需付出太多努力。
另一个快速获胜的机会：安全性
2019 年 Drupal 社区 DevOps 调查结果中的另一个快速获胜机会可能是
在流程的早期就尽可能多地考虑安全问题，而不是将其留到流程的最后，这种情况发生的频率有多高？
安全可以成为确定如何开发特性的过程的一部分。也可以像其他任何事情一样进行测试。而且，它显然是一项高影响力的改进，并且应该很容易获得动力，因为它始于可以学习和实践的思维模式转变。
为什么保持一致性很重要
当人们想到安全问题时，他们倾向于想到攻击者 slip 通过的单个“漏洞”以导致 breaches。现代 Web 应用程序有成百上千个微小的安全漏洞，其中任何一个都可能是可能使公司破产的安全问题的根源。与其将安全性视为布尔值（安全/不安全），不如将其视为一个量表。要朝着量表的安全端移动，您需要在安全问题进入生产环境之前阻止或捕获它们。
为了实现这一目标，您需要在流程的每个阶段都具有安全意识。
如何开始
在业务方面，考虑您希望用户能够执行的操作类型。在架构中，设计纵深防御。在开发中，学习如何使用框架提供的安全机制。在 QA 中，学习如何利用应用程序并积极尝试这样做。在流程的每个阶段都考虑安全性将减少（但永远不会消除）团队产生的安全问题的数量。
在 Drupal 中，重要的是要尽早提出关于用户帐户、表单、集成、安全库和框架以及安全更新等方面的问题。以下是一些问题，以用户帐户为例进行回答，尽早提出
- 我们正在做什么？用户可以登录以获得对特性的特殊访问权限。
- 可能会发生什么问题？用户的角色配置错误，导致访问权限过大，从而导致业务损失或技术中断。
- 我们能做些什么？我们可以使用自动化测试和持续集成在每次提交时测试角色是否配置错误。
- 我们做得好吗？这些测试涵盖了所有内容吗？还能做些什么？
有关更多想法，请参阅 威胁建模安全设计。
如何改进
有一些方法可以自动化某些类型的安全检查。它们将特定于您的环境，但一些效果良好的想法包括
- 通过自动使用“恶意”字符串填充您的数据结构，然后测试这些字符串是否在您的输出中被转义，从而测试 XSS 漏洞。
- 监控您的第三方依赖项中是否存在不安全的库，并在安全更新可用时发出警报。（奖励：自动化更新库的拉取请求。）
- 在自动化测试期间填写表单时，包含 SQL 注入字符串（例如，drop tables）。
在 Drupal 中，自动化提供了一些机会，可以通过一些巧妙的方法，以非常少的努力进行极其强大的自动化测试。例如，我们只需在实体加载时注入 XSS 字符串并检查各个页面是否存在泄漏，即可获得全站 XSS 覆盖率。权限方面也可以做很多事情，例如验证除了管理员用户之外，没有人拥有“危险”权限。
这些类型的测试之所以成为可能，是因为 Drupal CMS，我们应该作为一个社区努力使任何想要它们的团队都可以访问和使用它们。在 Drupal 中拥有这种级别的强大自动化测试使我们能够在发生零日漏洞事件时快速响应，因为这些测试将在部署之前捕获此类问题，否则这些问题可能会在发布后造成灾难性的后果。
更大的挑战：测试覆盖率
Drupal 社区 DevOps 维度中最需要关注的是
当开发特性时，可以编写测试来验证它们是否提供了业务价值。以允许在 CI 环境中运行的方式编写测试的频率有多高？
您可能需要在您的团队中获得相当好的势头才能解决这个问题，但这绝对是值得的。
如何开始
在确定哪些特性需要测试时，请考虑哪些特性在损坏时会导致计划外的工作。例如，如果您正在创建一个食谱数据库，并且您的特性之一是食谱录入表单，那么您需要测试食谱是否可以录入并且表单可以提交，因为如果没有该特性，您的应用程序将不再为您的用户提供价值。
一旦您的测试编写完成，如果它们在每次提交时都在 CI 系统中运行，而不是按计划或以临时方式运行，它们将提供最大的价值。这缩短了开发人员意识到他们引入的故障所需的时间——目标是让他们在转向下一个任务之前意识到故障，这样他们就不必切换上下文来返回修复它。
如何改进
即使您有一个出色的手动审查流程，包括人工进行的功能测试，也很快会变得不可能手动检查应用程序的每个特性。相反，您应该寻求自动化测试来覆盖（至少）您的业务关键特性。这种测试的价值将随着项目中的开发人员数量、每天推送的提交数量以及您拥有的业务关键特性的数量而成倍增加。
在测试方面有很多选择，但以下是人们通常使用的两种类型
- 单元：对单个“单元”代码（函数、类等）的详尽测试。对于应用程序，我们通常进行较少此类测试，但将其用于特别复杂或重要的代码位。此外，单元测试可以强制执行良好的设计实践。
- 功能：对用户看到的一段功能的测试，例如用户登录。这种类型的测试可以覆盖许多不同的代码路径，但通常不会详尽地覆盖它们。对于应用程序来说，这是一个不错的选择，并且通常可以使用“行为”框架（如 Behat 或 Cucumber）来实现。
对于 Drupal，请务必了解 Drupal Test Traits，它是 Moshe Weitzman、Jibran Ijaz 和 Rob Bayliss 编写的“用于测试具有用户内容（而不是未填充站点）的 Drupal 站点”的特性集合。DTT 的构建是为了使功能测试变得容易，因为它在您已安装的站点上运行，因此您无需担心在每次测试时从头开始模拟站点安装。它还提供了随着您的站点自然发展的测试，因为它使用您今天的配置，而不是您写入测试的配置。
结论
了解 DevOps 的背景和历史将意味着在行业中是追随者还是领导者的区别。如果时间还允许，请参与 Drupal 社区 DevOps 调查，以便我们可以将您的意见纳入结果中。
Rob Bayliss 和 Kelly Albrecht 将在他们的演讲 DevOps：为什么、如何和什么 中展示 2019 年 Drupal 社区 DevOps 调查的结果，并在 4 月 8 日至 12 日在西雅图 DrupalCon 2019 举办后续的 Birds of a Feather 讨论。
2 条评论