如何在软件项目中与许多贡献者自动化适当的更改。
包括建议的JavaScript或打字稿开发的建议实践和工具，但仅需要NPM或类似于执行。
ChangElogs是在项目版本之间传达更新的绝佳方法。但是，它们也可能是凌乱，技术性过高，冗长的或通常无济于事的。对于具有常规发行版的大型项目，追踪所有更改并正确记录它可能很耗时。
就我而言，我有一个GitHub项目，其中有大约30个贡献者，5位维护人员（决定里程碑并审查拉的请求），以及100个消费项目，其运营商每个都需要两个不同级别的技术说明之一。
创建适当的发布过程的任务（该任务都优先考虑文档，而无需淹没开发人员额外的工作 - 一开始就令人生畏。我在这里说这比我想象的要简单得多。这篇博客文章将引导您介绍我如何自动化的“ Quality”“在我们的委托中”的“质量”。
。任务
从Gene Kim's "3 Ways of DevOps"汲取灵感，我设置了该项目，集中于
的目标“永远不要将已知的缺陷传给下游工作中心”。
这意味着倡导并启用诸如测试驱动开发的实践，并将这些检查放在产品生命周期的早期。
回到Changelogs，我想通过与我的贡献者建立一份可理解的合同，并使责任使责任努力和文档，以类似地转移我们的 文档 改变维护者。
这意味着通过介绍：
使SDLC的3个阶段的开发人员可以- 干净的git过程
- 格式化提交的工具
- 用于生成Changelogs的工作流
惊喜，出现了一头大象！
要实现“无手动变形”的最终目标，我们必须首先解决房间中潜在的大象：不是每个人都同意您 应该 自动化自动化的changelogs。我在这里描述。发现这一点的最快方法之一是访问使用巧妙的标语：
的https://keepachangelog.com“不要让您的朋友将git登录登录到变更元中。”
该网站继续描述一些指导原则，我鼓励您退房。 tl; dr是：
- 遵循语义版本（或提及您的策略）
- 日志每个版本
- 将您的更改按类型进行分组
- 为人类而不是机器编写更改
显然，Git日志与我们希望消费者阅读的内容之间存在差距。下一部分将解决我们想要的过程以使我们的提交类似于人类可读的更改，以下部分将讨论工具以使您的团队可获得该过程。
至于大象，只有 您 才能确定您的权衡。您决定要自动化一个故意的决定，以反映您项目的长期目标。
清洁git过程
为了使用专用工具启用我们的自动化，我们将需要符合我们的提交消息和版本标签的约定。我在这里指的标准有用称为 常规委员
这是大多数NPM软件包符合的非常常见的版本控制（对于JS）。我们的版本控制策略的重要部分是，它可以控制何时生成更改程序：上一个版本标签和当前版本标签之间的提交日志的差异代表在版本中输入我们的ChangElogs的新信息。在SEMVER的情况下，这是3组数字，这些数字会根据您的变化的影响而增加。有关更多信息，请参见Semantic Versioning。 这就是我们可以从提交中解析有关更改（例如类型）的信息。请参阅Conventional Commits的完整规格。 每个提交应表示已知类型和可选范围的单个更改。 例如： 这是我们许多人使用git开始的不良习惯，这是一个很大的进步。但是，使用某些工具，一些练习以及在GitHub中设立的正确合并策略变得容易得多。 通过理论上的“提交历史”记录反映我们的变化历史记录1：1，最清洁的结果将来自简单的分支策略，例如trunk-based development，每个人都从一个共同的主分支中削减了功能（这需要拉拉请求才能更新）。通过在GitHub中配置Rebase+Squash Merge策略（而不是默认值），要求您的功能承诺被压缩为拉的请求，这也将使历史记录保持清洁，并使我想谈论的即将到来的工具更容易避免问题。<<<<<<<<<<<<<<<<<<<<<< /p>
按照我们的标准，我们可以访问我们的工具袋并抓住一些CLI杠杆，以帮助统一贡献者并传达我们成功所需要的东西。我在这里提到的工具适用于使用NPM等包装跑步者的JS/TS项目。请记住，如果您愿意使用node.js或进行一些更改，请记住其他项目可以通过一些额外的工作来使用它们。 以我上面提到的传统提交风格写作非常简单，但是您和您的贡献者所做的所有工作都会有相同的要求。另外，发生事故。每次以相同的方式构造这些消息有助于它。 commitizen是一个CLI工具，您可以引入使用规则来创建提交，默认为常规提交格式！我从NPM安装了commitizen，以依赖我的项目的DevDeconies，以使整个团队具有相同的规则集。为了在不依赖全局安装的情况下进行设置，我使用了NPX： 此命令使用已经设置的标准更新了项目的 一旦到达这一点，您就可以开发 cz的尼斯命令提示使我们在我们写消息时不会删除所需的任何东西，而诸如主题行中的角色数之类的问题会被召唤出来。 现在，我们有了一种工具来帮助我们做出伟大的承诺，让我们成为任何人对项目承诺的默认方式。我们可以设定期望贡献者在每次都需要帮助的帮助下使用命令行的期望。 Husky是我选择的设置git挂钩的工具。使用此工具，我们可以确保提交过程的每个步骤都通过了我们关心的支票。每当用户浏览其提交过程以从其本地计算机推送到GitHub存储库时，单位测试，裁剪，打字稿构建等等都可以从脚本中调用。 为了确保开发人员可以访问与您相同的挂钩，您可以将此软件包安装到DevDections中。除了使用NPM，纱线等安装 - 我们还需要运行一个 在这里，is-ci是另一种可选的DevDectionenty，它将防止挂钩在远程CI环境中注册，您可能会在其中添加繁琐的投入，标签等。 然后，当贡献者安装您的项目和类型的“ git commit”时，将与我们在上一节中看到的相同的CLI满足。漂亮时髦ð 所以现在我们所有的开发人员都是自动ðªª发出好消息，对吗？ 正如您现在可能猜到的那样，是的，有NPM软件包。 最后，通过我们为设置存储库所做的工作，我们可以从播种到收割，再加上一个方便的工具。 conventional-changelog-cli可以随时随地使用您的项目更改版本。他们在链接的NPM页面上的文档会引导您浏览如何将其配置为“ NPM版本”命令，但是如果您只需在撞到版本之后仅运行软件包，则可以使用： 从可以访问所有以前的git标签的环境中。以常规-Changelog-CLI存储库为例，您可以看到可以从此CLI中期望的日志类型： 那是我们的目标。我们要求贡献者将终端用于其git提交，进而我们可以根据对存储库的每个拉动请求自动生成更换的元素。显然，这仍然需要开发人员可以理解的提交消息，但是现在可以在“拉动请求”中看到该反馈，并在其余的传入工作中可见。在发行当天，不再需要捕捉单一的贡献者以比您预期的要长。
语义版本控制
传统提交
这带来了我发现实践中最困难的概念：
fix(core): remove bad behavior xyz
分支和合并策略
格式化提交的工具
承诺
npx commitizen init cz-conventional-changelog
package.json文件中所需的内容
"devDependencies": {
...
"cz-conventional-changelog": "^3.3.0"
},
"config": {
"commitizen": {
"path": "./node_modules/cz-conventional-changelog"
}
npx cz，看看我们希望开发人员在做出提交时看到什么：
范围，更改类型，受影响的问题/门票以及打破更改都被解释了。
沙哑
npx husky install来设置钩子。为了确保在其他开发人员工作空间上发生这种情况，我们将此位打入包装块中。JSON：
"scripts": {
"prepare": "is-ci || husky install",
按照cz's docs，我们可以使用以下方式点击Git Commit命令提示符：
npx husky add .husky/prepare-commit-msg "exec < /dev/tty && npx cz --hook || true"
提交
如果您想确保将其进入功能分支的原因将用于将GIT日志转换为ChangElogs的最后一步，我们还需要一件事：提交linting。
安装@commitlint/cli和@commitlint/config-conventional并用沙哑建立后承诺或前git挂钩是一种选择。另一个是记录您在拉的请求中的最新提交，并从GitHub工作流程中运行合并检查。最终，这取决于您要在传入的变化中如何和何处传达问题。
后者的一个例子看起来像：
git log -n 1 --format=%B | npx commitlint
自动生成更改程序
常规的变性-CLI
npx conventional-changelog-cli -i 'CHANGELOG.md' -s -t v -p angular
尽管在自动化方面都没有什么完整的，但是花时间使每个贡献者都能考虑他们所做的变化并正确地进行交流，这使我们的发行版压力减轻了。我希望我提到的过程和工具向您展示了类似的结果，或者帮助您考虑使文档更容易和清晰的选项。
但是 您 想想？
- 让我知道您是否同意或不同意我的工具和流程。
- 您使用什么用于变频器（或其他发布自动化）？
- 您还想阅读有关此主题的内容（例如在Monorepo中处理ChangElogs）？