「精确类型」代码仓库是一个 TypeScript 类型工具库。
这个工具库使用一套独特的开发流程,可以概括性地称为以功能为中心的迭代速度很快的开发流程。 我也不知道简称什么,就暂时简称功能快速开发吧。
accureleaser
就是功能快速开发的一个实现工具。
「精确类型」的英文名是 Accurate Type,包名是 accurtype
。
可以发现包名就是把 Accurate 和 Type 两个单词拼一起。
所以「精确类型」配套开发流程管理工具的英文名是 Accurate Releaser,自然包名就是把两个单词拼到一起,变成 accureleaser
了。
功能快速开发其实一开始并不是一整套完全的开发流程。
由于「精确类型」是一个由高端社区驱动的项目,我就选择通过 GitHub Actions 来发布 npm 包。 因为这样子仓库的右边就有“Packages”栏,看起来更加高大上了。
然鹅在尝试给「精确类型」编写自动发布流程时,我发现自动发布作为一种不能人工介入的发布方式,是需要通过特定的时机才能发布的。 时机的选择就比较耐人寻味:究竟是每天、每周这样的定时发布,还是每有一个版本就发布一次? 考虑到版本标签还可能有测试版、抢鲜版和正式版的区别,版本号还有破坏性 API 、功能增加和问题修复的区别,版本发布的时机就需要根据开发流程来决定。 然而如果没有一个合适的管理工具,开发流程是十分自由的,根本没法保证版本发布时机的准确性。
我于是就搜索有哪些开发流程管理工具,发现了一个叫 semantic-release 的工具。 (所以想要知道为什么需要功能快速开发,可以先去了解 semantic-release 。)最终还是决定自己写一个工具来实现一个独特的开发流程:功能快速开发。
相较于 semantic 提供的比较主流(大概)的开发流程,功能快速开发有以下区别:
-
考虑到「精确类型」的开发较为连贯,仅有破坏性更新会需要更正主版本号,架构更改问题很少。 所以功能快速开发并不强调不同代版本(比如
2.x.x
和3.x.x
之类的)之间的互动,取而代之是只维护一代常用版本。 -
将“feature”这种提交变成了各个分支~也就是说并不是一次提交实现一个功能,而是一个开发分支实现一个功能。
这种开发方法适用于工具包这种功能之间差异较大,且单个功能开发时间较长的开发环境。
-
分支开发功能还可用于方便地生成 changelog。 在分支被创建时,开发者可以描述这个分支所开发的功能。 这样子在此分支开发完成被合并后,changelog 中就可以包含这个描述,以此来自动生成 changelog。
-
由于「精确类型」是一个类型库,对类型的修改就是对库 API 的修改——任何类型工具被修改,都相当于 API 直接被修改,也就是一个破坏性更新——所以一个功能的发布要非常慎重。
为此,功能快速开发对每个功能都引入了三个开发阶段(milestone):
alpha
、beta
、release
,而且引入了分支之间的依赖关系用以判断一个功能是否能够被合并到稳定版本中。 -
但是功能开发周期过长会导致用户无法及时用到具有最新功能的版本,所以功能快速开发引入了“前瞻版本”这个概念,来代替 semantic 开发流程中的“下一代”版本,扮演
next
版这个角色。前瞻版本不用来开发,仅仅是一个比正式版本功能添加得更早的专门用来使用的版本。
功能快速开发并不全部接管包的开发。
上面说过,功能快速开发的初衷是为了保证包发布的时机可以控制,来通过 GitHub Actions 发包。
所以功能快速开发的目标也包含兼容较简单的包开发流程。
比如 accurelreaser
作为一个功能快速开发流程的实现工具,也允许 monorepo 中出现 semantic 的开发流程。
除了版本号需要自己手动更改(semantic-release 可以帮助更改版本号)之外,最基本的通过 Actions 发包之类功能都能很好的实现。
如果你阅读以上内容,充分了解了功能快速开发的特点,你就能自己判断为什么需要这种开发流程了。 如果你阅读以上内容也没充分了解,欢迎反馈文档问题或者为这个文档贡献!