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