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"
与默认设置唯一不同的是:
- 选择 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
这里没有什么特别的。我们使用了skipKeywords选项,其中包含了BleedingEdge关键字,如果你还记得的话,Dependabot 会在每个拉取请求前加上这个关键字。我们对 Dependabot 提交的拉取请求的处理方式略有不同,因为不想给所有审阅者带来负担。
一旦打开 Pull 请求,机器人就会启动,您会在时间线上看到它请求审核:
您也可以尝试使用 Github 提供的默认代码审查任务设置。只需进入您的团队页面,点击右上角的“设置”,即可找到“代码审查任务”选项卡。我们尝试过,但效果不佳。
3. 合并冻结
代码冻结工具可阻止合并和部署
添加合并冻结的原因源于一个简单的问题:
既然我们已经开始回归,你能告诉所有开发人员停止合并吗?
我们可以在团队频道中发布公告,希望每个人都能及时看到这条消息。或者,我们可以集成一个工具,让 QA 团队在 Slack 上发出命令,冻结/解冻代码库的合并。“合并冻结”功能可以帮上忙。
同样,设置过程也很简单。我们发现 Merge Freeze 缺少的是批量冻结的功能。当我们需要冻结几个仓库时,它工作得很好。但是,一旦我们的仓库数量增加到 10 个以上,手动输入命令超过 10 次……你就明白了。
为此,我们使用了Slack Apps和AWS Lambda。
我们为工作区创建了一个名为 Deployment 的自定义 Slack 应用程序,它有两个斜杠命令:/freeze_all
和/unfreeze_all
。这两个命令都将请求 URL 设置为我们的 Lambda URL,并将冻结值作为查询参数传递:?freeze=true | false
。
在 Slack 上使用它如下所示:
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';
}
};
输入命令后,MergeFreeze 会列出所有冻结或解冻的存储库,并且您会收到来自 Slack 的确认消息,让您的工作日变得更加美好!
回归完成后,所有内容都会被推送到生产环境并进行烟雾测试,首席 QA 发出unfreeze_all
命令,生活继续。
4.哈士奇
轻松实现现代原生 Git Hooks
我们使用 Jira 作为我们的工作管理工具,因此我们必须将票证 ID 添加到我们的分支名称和提交消息中,以便在查看问题时同时使用开发面板和 VSCodes 扩展 GitLens:
这意味着每次创建分支时,你都必须记住包含 Jira 问题 ID,例如:task- ND-123 -add-authentication。这本身没什么大不了的,因为它很快就养成了习惯。但真正的 PIA 是将它添加到每个提交消息的前面。第一轮自动化只是prepare-commit-message
在本地机器上设置 git hook,但随着团队规模的扩大,我们需要一个更好的解决方案,而 Husky 正好提供了这个解决方案!
Husky与jira-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",
...
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
这很顺利,因为一切都已设置好package.json
,新的开发人员可以做,npm i
而且他/她已经基本设置好了,不需要手动配置钩子。
但是提交消息中的 Jira Ticket ID 与 GitLens 的结合才真正让它变得非常有用。
很多时候,出于各种原因,我们不得不打开并查看与代码变更相关的 Jira 问题。在整个代码库中,每次单击鼠标时都能看到工单 ID,这为我们节省了大量时间。(在浏览器中打开也很简单,只需获取 Jira ID 并将其添加到.../browse/ + ND-123之后,例如https://your-organization.atlassian.net/browse/ND-123)
GitLens 是一款很酷的工具,我个人每天都在使用。它能帮助你通过 Git Blame 注释和代码透视功能一目了然地查看代码作者。你还能轻松地返回历史记录,查看之前的提交,这也很实用。
5. 拉取请求的定时提醒
定时提醒可帮助团队专注于最重要的审核请求
这是我们不久前添加的功能,就在我们迁移到微前端架构后不久。添加它的原因之一是代码库的数量从 4 个增加到了 14 个,因此设立一个专门的拉取请求渠道是合理的。在此之前,我们会在团队的主渠道发布 PR 链接,或者希望大家能在邮件中看到。现在,我们把干扰信息转移到了专门的渠道,开发者们也知道团队会自动收到通知。
我们每个工作日的 8 点到 16 点,每个整点都会收到通知。它会忽略已批准的拉取请求(在我们的例子中,有 2 人以上批准了该请求),并且我们还为BleedingEdge设置了忽略条款,因此它会忽略 Dependabot 提交的拉取请求。
设置定时提醒很简单,你可以在这里找到 GitHub 文档。设置完成后,它看起来是这样的,在我们的例子中,它会在一个私有的frontend-pull-requests频道中发布消息:
...
我们可以在此基础上进行很多改进,比如直接从 Jira 创建分支可以减少记住命名约定的麻烦。或者,我们可以选择一个内置批量冻结功能的合并冻结工具。但通常我们调查的时间有限,或者当时工具本身就足够好,之后我们只是尝试改进流程,而不是更换工具。如果
您有任何建议,请在下方讨论区留言!
欢迎随时联系👋
Twitter | Instagram | LinkedIn
文章来源:https://dev.to/pgarzina/5-tools-to-automate-your-development-3m