drupal_Drupal社区在DevOps采纳中的地位

drupal

在本文的第一部分，我们解释了为什么DevOps是现代技术组织最重要的战略。要了解有关如何使用DevOps的更多信息，我们启动了2019年Drupal社区DevOps调查，该调查正在收集数据，直到4月10日在DrupalCon上展示结果为止。该调查要求Drupal社区成员使用以下方法评估24个DevOps维度上的团队：利开特式量表。

对调查中的每个维度进行评分，对所有受访者进行平均，然后汇总为总体得分。每个DevOps维度也都进行了评分，可以针对其对团队的价值以及团队在此方面的起步或改进方式进行单独考虑。尽管在撰写本文时调查仍在进行中，但整个Drupal社区的结果（随着反馈的加入而更新）似乎已经趋于稳定。

在60年代中期，Drupal社区一直在使用DevOps做法浮动。虽然真正的价值是团队可以随着时间的推移跟踪其高水平的改进，但从表面上看，这可以理解为意味着Drupal社区感觉与DevOps实践的一致性比某些时候要强得多。

一个双赢的机会：快速发布代码

如果我们以高影响力，轻松获胜的方式扫描结果，则可能会选择以下内容：

何时可以将代码安全地发布到生产环境多久一次？

在83％的团队中，大多数团队进展顺利，而且对于DevOps如此高影响力的领域，没有更多的进展。这意味着，对于许多人来说，这是一个已解决的问题，而且通过一些快速的学习和主动行动，任何团队都可以很好地做到这一点。

为什么保持一致很有价值

我们可能都有过向生产中发布某种关键错误的经验。最终中断生产是不可避免的，DevOps优先考虑快速行动，而不是不惜一切代价避免中断。在这种情况下，“快速移动”意味着能够立即发布修补程序以解决该问题。如果您在master分支上有100％不确定准备就绪的更改，则这是不可能的。

如何开始

要确保可以随时固定生产，很难击败GitFlow模型。在部署之前，GitFlow会将未发布的工作保留在单独的分支（通常称为“ develop”）上。仅在部署时，它才会合并到主分支（通常是“主”）。这样就可以使母版始终保持干净以获取修补程序，并允许您在修补程序中遵循正常发布过程的缩写形式。

入门意味着学习版本控制并使用它（如果您还不了解，那么将近100％的Drupal受访者表示在他们的工作中始终使用版本控制）。从那里开始，将站点的大部分配置都放入代码中也很重要，例如，D7的功能或D8中的配置管理，以便所有工作可以被团队中的其他人审查。最后，实施基本的持续集成（CI）来运行您的测试套件，以及将持续交付（CD）交付给预览环境以进行视觉检查，这将使正在进行的功能开发与生产管道脱钩，并允许对现成的分支机构或分支机构进行更具战略性的部署在不影响master分支一致性的情况下，根据需要提供修补程序。

幸运的是，存在许多以这种方式与Drupal一起使用的服务，并且可以在不花太多力气的情况下基本地学习和实施。

另一个双赢的机会：安全性

在2019年Drupal社区DevOps调查结果集中的另一个快速胜利可能是：

请多久进行一次安全考虑，而不是将其留在流程的最后？

在确定如何开发功能时，安全性可以是过程的一部分。它也可以像其他所有东西一样进行测试。这显然是一项具有重大影响的改进，应该容易吸引人，因为它始于可以学习和实践的思维转变。

为什么保持一致很有价值

当人们想到安全问题时，他们往往会想到攻击者从一个单一的“漏洞”中漏出而造成漏洞。现代Web应用程序具有成百上千个微小的安全漏洞，每个安全漏洞都可能导致可能导致公司破产的安全问题。不要将安全性视为布尔值（安全/不安全），而应将其视为规模。为了朝着秤的安全端发展，您需要在将安全问题投入生产之前防止或发现安全问题。

为此，在流程的每个阶段都需要安全意识。

如何开始

在业务方面，请考虑希望用户能够执行的操作类型。在体系结构中，进行深度防御设计。在开发中，教育自己如何使用框架提供的安全性机制。在质量检查中，学习如何利用应用程序并积极尝试这样做。在流程的每个阶段考虑安全性都会减少（但永远不会消除）团队产生的安全性问题的数量。

在Drupal中，提出有关用户帐户，表单，集成，安全库和框架以及安全更新之类的问题很重要。以下是一些问题，使用用户帐户作为示例响应，请尽早提出：

我们正在做什么？ 用户可以登录以对功能进行特殊访问。
有什么问题吗？ 用户的角色配置错误，以允许太多访问，从而导致业务损失或技术中断。
我们对于它可以做些什么呢？ 我们可以使用自动测试和持续集成来测试角色在每次提交时是否配置错误。
我们做得好吗？这些测试涵盖所有内容吗？还有什么可以做的？

有关更多想法，请参阅安全性威胁建模设计 。

怎么提高

有一些方法可以使某些类型的安全检查自动化。它们将特定于您的环境，但是一些效果很好的想法包括：

通过自动用“恶意”字符串填充数据结构来测试XSS漏洞，然后测试这些字符串是否在输出中转义。
监视第三方库中不安全库的依赖关系，并在有安全更新可用时发出警报。（奖金：自动执行拉取请求以更新库。）
在自动测试期间填写表单时，请包括SQL注入字符串（例如，删除表）。

如果您很聪明，在Drupal中，自动化为您提供了一些机会，只需很少的精力即可完成一些非常强大的自动化测试。例如，我们可以通过在实体加载时注入XSS字符串并检查各个页面是否泄漏来获得全站点XSS覆盖。权限还有很多事情可以做，例如验证除管理员用户外没有人具有“危险”权限。

由于Drupal CMS，这些测试是可能的，我们应该作为一个社区工作，以使任何想要它们的团队都可以访问和使用它们。在Drupal中具有这种强大的自动化测试水平，使我们能够在零日漏洞发生时Swift做出响应，因为这些测试将在部署之前发现此类问题，如果发布该版本会造成灾难性的后果。

更大的挑战：测试覆盖率

Drupal社区最需要关注的DevOps维度是：

开发功能时，可以编写测试以验证它们是否正在提供业务价值。以允许测试在CI环境中运行的方式编写测试的频率如何？

您可能需要团队中有一些不错的动力来解决这一问题，但这是值得的。

如何开始

在确定哪些功能需要测试时，请考虑哪些功能如果损坏将导致计划外的工作。例如，如果您要创建配方数据库，并且其中一项功能是配方输入表单，则需要测试是否可以输入配方并提交表单，因为如果没有该功能，您的应用程序将不再提供为您的用户带来价值。

编写测试后，如果它们在CI系统中每次提交而不是按计划或临时方式运行，它们将提供最大的价值。这缩短了开发人员了解其引入的中断所需的时间，其目的是使他们在移至下一个任务之前就已意识到中断，因此他们无需切换上下文即可解决此问题。。

怎么提高

即使您有一个出色的手动审核过程，包括由人工进行的功能测试，也将很快无法手动检查应用程序的每个功能。相反，您应该寻求自动化测试以（至少）涵盖您的业务关键功能。该测试的价值将乘以项目中开发人员的数量，每日推送的提交数量以及您拥有的关键业务功能的数量。

关于测试，有很多选择，但是人们通常使用以下两种类型：

单位：对单个“单位”代码（功能，类等）的详尽测试。我们通常不会对应用程序进行此类测试，而是将其用于特别复杂或重要的代码段。同样，单元测试可以强制执行良好的设计规范。
功能性：测试用户所看到的一项功能，例如用户登录。这种类型的测试可以涵盖许多不同的代码路径，但通常不能全面涵盖它们。这是应用程序的不错选择，通常可以使用“行为”框架（例如Behat或Cucumber）来使用。

对于Drupal，一定要了解Drupal测试特质，它是Moshe Weitzman ， Jibran Ijaz和Rob Bayliss的 “用于测试具有用户内容的Drupal网站（相对于未填充的网站）”特征的集合。 DTT的构建是为了使功能测试变得容易，因为它可以在已安装的站点上运行，因此您不必担心在每次测试时都从头开始模拟站点安装。它还提供了可以随您的站点自然发展的测试，因为它使用的是您今天拥有的配置，而不是您写入测试中的配置。

结论

了解DevOps的背景和历史将意味着关注和领导行业之间的差异。如果还有时间，请参加Drupal社区DevOps调查，以便我们将您的输入包括在结果中。

Rob Bayliss和Kelly Albrecht将在其演示文稿DevOps：为什么，如何以及做什么中介绍2019年Drupal社区DevOps调查的结果，并在4月8日至12日于西雅图举行的DrupalCon 2019 上进行羽毛讨论的后续活动。

接下来要读什么

翻译自: https://opensource.com/article/19/3/drupal-community-devops-adoption

drupal