5 种自动化开发工具

2025-05-26

5 种自动化开发工具

使用 Dependabot、Auto Assign、Merge Freeze、Husky 和 ​​Scheduled 提醒实现开发自动化。

这篇文章的目的是介绍一些使我们的开发生活更轻松的工具和集成。

其中大多数都很容易在您的工作流程中实现,但对于那些存在一些问题的工具,我可能会单独为该工具编写一个扩展的介绍版本。

1. Dependabot

自动依赖项更新

Dependabot 创建拉取请求以确保您的依赖项安全且最新。

Dependabot非常简单,它的妙语清楚地说明了它的功能。几年前,也就是Github 收购它之前,我们就开始使用它了。

主要原因是,在我们目前的团队接手前端部门时,有很多过时的依赖项需要更新,并且希望保持最新状态。我们找到了 Dependabot,将它添加到我们的项目中,从此让它发挥它的魔力。

现在它已经是 Github 的一部分了,所以添加它比以前更容易。你可以看看如何设置 Dependabot,但最终你会dependabot.yml在你的.github文件夹中看到一个。
我们的文件夹是这样的:

version: 2
updates:
  - package-ecosystem: "npm" # See documentation for possible values
    directory: "/" # Location of package manifests
    schedule:
      interval: "daily"
    open-pull-requests-limit: 2
    commit-message:
       prefix: "BleedingEdge"
Enter fullscreen mode Exit fullscreen mode

与默认设置唯一不同的是:

  • 选择 npm 作为我们的包生态系统
  • 将开放 PR 数量限制为 2
  • 为默认 Dependabots 提交消息添加了前缀(稍后您将了解原因)

四年前,我们只有 3 个前端代码库,现在大约有 14 个活跃的。手动更新每个依赖项会非常耗时。Dependabot 帮了大忙,但审核和合并所有 PR 仍然需要时间。我们通常在每周发布后花一天时间来合并 Dependabot 的 PR。

写到这里,我开始思考是否可以将机器人设置为仅在主版本、次版本或补丁版本上打开 PR。事实上,该功能早在 2018 年就被提出,几个月前就已发布,现在您可以根据需要忽略 SemVer 更新。查看GitHub 的博客文章了解更多信息。

2. 自动分配

当拉取请求打开时,将审阅者/受让人添加到拉取请求中。

所以你创建了一个拉取请求,至少需要两人批准,并且每次都需要添加审阅者。

事情很明显,让机器人去做吧。

设置很简单,前往probot.github.io/apps/auto-assign,点击“添加到 Github”按钮,无需手动添加审阅者!
与 Dependabot 类似,最终会生成一个auto_assing.yml文件:

# Set to true to add reviewers to pull requests
addReviewers: true

# Set to true to add assignees to pull requests
addAssignees: false

# A list of reviewers to be added to pull requests (GitHub user name)
reviewers:
  - teammember1
  - teammember2
  - teammember3
  - ...


# A number of reviewers added to the pull request
# Set 0 to add all the reviewers (default: 0)
numberOfReviewers: 0

# A list of keywords to be skipped the process that add reviewers if pull requests include it
skipKeywords:
  - BleedingEdge

Enter fullscreen mode Exit fullscreen mode

这里没有什么特别的。我们使用了skipKeywords选项,其中包含了BleedingEdge关键字,如果你还记得的话,Dependabot 会在每个拉取请求前加上这个关键字。我们对 Dependabot 提交的拉取请求的处理方式略有不同,因为不想给所有审阅者带来负担。

一旦打开 Pull 请求,机器人就会启动,您会在时间线上看到它请求审核:
自动分配机器人

您也可以尝试使用 Github 提供的默认代码审查任务设置。只需进入您的团队页面,点击右上角的“设置”,即可找到“代码审查任务”选项卡。我们尝试过,但效果不佳。

3. 合并冻结

代码冻结工具可阻止合并和部署

添加合并冻结的原因源于一个简单的问题:

既然我们已经开始回归,你能告诉所有开发人员停止合并吗?

我们可以在团队频道中发布公告,希望每个人都能及时看到这条消息。或者,我们可以集成一个工具,让 QA 团队在 Slack 上发出命令,冻结/解冻代码库的合并。“合并冻结”功能可以帮上忙。

同样,设置过程也很简单。我们发现 Merge Freeze 缺少的是批量冻结的功能。当我们需要冻结几个仓库时,它工作得很好。但是,一旦我们的仓库数量增加到 10 个以上,手动输入命令超过 10 次……你就明白了。

为此,我们使用了Slack AppsAWS Lambda

我们为工作区创建了一个名为 Deployment 的自定义 Slack 应用程序,它有两个斜杠命令:/freeze_all/unfreeze_all。这两个命令都将请求 URL 设置为我们的 Lambda URL,并将冻结值作为查询参数传递:?freeze=true | false

在 Slack 上使用它如下所示:

Slack Freeze 命令

Merge Freeze 工具会为每个添加到其中的仓库公开一个 API 端点,您可以使用该端点冻结或解冻仓库。这使得 Lambda 的使用变得相当简单,它只需向 MergeFreeze 提供的每个端点发出 POST 请求即可。

const https = require('https');

exports.handler = async (event) => {

  const freezeValue = getFreezeValue(event);
  if (!freezeValue) {
    return {
      statusCode: 400,
      body: JSON.stringify('BOOM! You need to provide a freeze value as a query param, either true or false'),
    };
  }

  const userName = getUserName(event)

  const baseOptions = {
    hostname: 'mergefreeze.com',
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Content-Length': 0,
    },
  };

  const appOneOptions = {
    path: `/api/branches/your-organization/your-repo/main/?access_token=${process.env.ACCESS_TOKEN}&frozen=${freezeValue}&user_name=${userName}`,
    ...baseOptions,
  };
  ...
  /** Removed the rest of declaration to keep the preview short */


  await Promise.all([
    doRequest(appOneOptions),
    ...
    doRequest(appElevenOptions),
  ]);

  console.log("I'm done with all your promises!");

  // Text that gets return to Slack that is only visible to the person entering the command
  return {
    statusCode: 200,
    body: JSON.stringify('You have such power!!!'),
  };

  function doRequest(options) {
    return new Promise((resolve, reject) => {
      const req = https.request(options, (res) => {
        res.setEncoding('utf8');
        let responseBody = '';
        res.on('data', (chunk) => responseBody += chunk);
        res.on('end', () => resolve(responseBody));
      });

      req.on('error', (err) => reject(err));
      req.end();
    });
  }

  function getFreezeValue(event) {
    let freezeQueryString;
    let freeze;

    if (event && event.queryStringParameters && event.queryStringParameters.freeze) {
      freezeQueryString = event.queryStringParameters.freeze;
    }

    if (freezeQueryString === 'true' || freezeQueryString === 'false') {
        freeze = freezeQueryString;
    }

    return freeze;
  }

  function getUserName(event) {
    const bodyQueryParams = new URLSearchParams(event.body);
    return bodyQueryParams.get('user_name') || 'Web API';     
  }
};
Enter fullscreen mode Exit fullscreen mode

输入命令后,MergeFreeze 会列出所有冻结或解冻的存储库,并且您会收到来自 Slack 的确认消息,让您的工作日变得更加美好!

强大的力量

回归完成后,所有内容都会被推送到生产环境并进行烟雾测试,首席 QA 发出unfreeze_all命令,生活继续。

4.哈士奇

轻松实现现代原生 Git Hooks

我们使用 Jira 作为我们的工作管理工具,因此我们必须将票证 ID 添加到我们的分支名称和提交消息中,以便在查看问题时同时使用开发面板和 VSCodes 扩展 GitLens:

Jira ticket 开发面板:
Jira 开发面板

这意味着每次创建分支时,你都必须记住包含 Jira 问题 ID,例如:task- ND-123 -add-authentication。这本身没什么大不了的,因为它很快就养成了习惯。但真正的 PIA 是将它添加到每个提交消息的前面。第一轮自动化只是prepare-commit-message在本地机器上设置 git hook,但随着团队规模的扩大,我们需要一个更好的解决方案,而 Husky 正好提供了这个解决方案!

Huskyjira-prepare-commit-msg 的结合对我们很有效:

...
  "private": true,
  "husky": {
    "hooks": {
      "prepare-commit-msg": "jira-prepare-commit-msg"
    }
  },
  "jira-prepare-commit-msg": {
    "messagePattern": "$J $M",
    "jiraTicketPattern": "(\\w+-\\w+-\\d+)"
  },
  "dependencies": {
...
  "devDependencies": {
    "husky": "^4.3.8",
    "jira-prepare-commit-msg": "^1.5.2",
...
Enter fullscreen mode Exit fullscreen mode

JIRA 票据 ID 取自 git 分支名称。现在,您只需输入以下内容commit -m "Fixing a typo",即可获得类似“task-ND-123-Fixing a typo”的提交消息。

如果您没有正确命名您的分支,例如:缺少 Jira ticket ID,您将收到错误:

my-application git:(main) ✗ git commit -m "Add authentication methods"
husky > prepare-commit-msg (node v14.15.0)
JIRA prepare commit msg > start
JIRA prepare commit msg > Error: The JIRA ticket ID not found
JIRA prepare commit msg > done
Enter fullscreen mode Exit fullscreen mode

这很顺利,因为一切都已设置好package.json,新的开发人员可以做,npm i而且他/她已经基本设置好了,不需要手动配置钩子。

但是提交消息中的 Jira Ticket ID 与 GitLens 的结合才真正让它变得非常有用。

GitLens 带有 Git blame 注释:
Visual Studio Code 和 GitLens

很多时候,出于各种原因,我们不得不打开并查看与代码变更相关的 Jira 问题。在整个代码库中,每次单击鼠标时都能看到工单 ID,这为我们节省了大量时间。(在浏览器中打开也很简单,只需获取 Jira ID 并将其添加到.../browse/ + ND-123之后,例如https://your-organization.atlassian.net/browse/ND-123

GitLens 是一款很酷的工具,我个人每天都在使用。它能帮助你通过 Git Blame 注释和代码透视功能一目了然地查看代码作者。你还能轻松地返回历史记录,查看之前的提交,这也很实用。

5. 拉取请求的定时提醒

定时提醒可帮助团队专注于最重要的审核请求

这是我们不久前添加的功能,就在我们迁移到微前端架构后不久。添加它的原因之一是代码库的数量从 4 个增加到了 14 个,因此设立一个专门的拉取请求渠道是合理的。在此之前,我们会在团队的主渠道发布 PR 链接,或者希望大家能在邮件中看到。现在,我们把干扰信息转移到了专门的渠道,开发者们也知道团队会自动收到通知。

GitHub 计划提醒

我们每个工作日的 8 点到 16 点,每个整点都会收到通知。它会忽略已批准的拉取请求(在我们的例子中,有 2 人以上批准了该请求),并且我们还为BleedingEdge设置了忽略条款,因此它会忽略 Dependabot 提交的拉取请求。

设置定时提醒很简单,你可以在这里找到 GitHub 文档。设置完成后,它看起来是这样的,在我们的例子中,它会在一个私有的frontend-pull-requests频道中发布消息:

前端拉取请求

...

我们可以在此基础上进行很多改进,比如直接从 Jira 创建分支可以减少记住命名约定的麻烦。或者,我们可以选择一个内置批量冻结功能的合并冻结工具。但通常我们调查的时间有限,或者当时工具本身就足够好,之后我们只是尝试改进流程,而不是更换工具。如果
您有任何建议,请在下方讨论区留言!


欢迎随时联系👋

Twitter | Instagram | LinkedIn

文章来源:https://dev.to/pgarzina/5-tools-to-automate-your-development-3m
PREV
Kubernetes 入门指南 - 1
NEXT
无需 JavaScript 即可实现原生图像延迟加载 关于延迟加载以及为什么要使用它 旧方法(JavaScript) 新方法(HTML)