浅谈前端组件发布自动化

从09年angularJS被谷歌推出以来，涌现了很多前端应用的开发、设计等方面优秀的解决方案（框架、库、设计规范）。随着SPA的普及，"Web Components"的设计标准渐渐开始影响各个框架的设计方向，开发人员的逻辑封装也不再像以前效率相对低下，优秀的框架给开发者提供了简洁且快速的组件化解决方案。

本文会尽量少的贴代码，尽量少的谈及工程化本身的东西，旨在分享组件自动化基础设施建设过程中的些许经验。

工程化的内容后续会有单独的“毒文”来祸害大家。

一、应用背景

如上所述，中大型的团队或公司在未来的一段时间，都需要封装足够多且完善的UI组件来支撑快速开发和降低学习成本。这样的情境下，就会有一些人，去进行组件的标准化开发，快速迭代，而随之而来且亟待解决的问题：

组件的版本控制
组件的产出物（包、文档）的相关性
组件构建、测试的冗长的工作量
组件发布环节的不可控
权限的不可控性（组件仓库权限、源码仓库权限）

组件发布自动化的目的不仅仅是减少你的手动构建、发布的工作量，它的本质是对多人协同组件开发方式的规范和管控。

没有这些你的前端研发工作也能支撑？能用和好用是两个概念。

二、涉众及相关技术栈

1、人员涉众

开发人员：组件开发者，源码的提交者
配置管理员：版本发布的流程、权限控制者，同时也是发布节奏的控制者

2、相关技术名词

了解以下，阅读过程会相对轻松：

nodeJS：自动化流程中的主要参与者
gradle：负责整体流程的包装，同时也会用到其生态中的一些插件
jenkinsFile：推荐用声明式（groovy），本文基于脚本式
webdav：用来做文档发布的服务器（优势是可控的发布权限），可以用其他web容器替代

3、工程职责

为了详略得当，这里列举工程的一些基础功能（这里默认已经实现，实际需要我们自己根据我们的实际情况去实现），以免赘述与本文不相关的内容。

包输出：工程提供构建的基础功能（将源码输出为npm仓库的package的功能）
文档输出：工程提供文档输出的功能（推荐markdown手写合成的体验较好的文档输出机制）
测试：提供单元或e2e测试的基础框架

三、流程概览

自动化流程.png

如上图所示，发布流程主要为（区别化的内容加粗）：

开发人员提交代码（git push）/配置管理员打tag
git接到push/tag，根据配置好的webhook给jenkins发请求
jenkins接收请求并触发指定的task，根据jenkinsFile执行pipeline：
- 更新项目并检查设置
- sonar：推送代码到sonar
- 测试：单元测试&&e2e测试
- package构建
- package发布：计算版本号并发布package
  - 根据git 的最后一条log计算下一版本号
  - 根据git的最后一条log区分发布测试版本（snapshots）还是正式版本（release）
- 构建doc
- 发布doc：根据git的最后一条log区分发布测试版本文档（snapshots）还是正式版本文档（release）

四、流程详述（冗长的细节，可略）

1、update project - 更新项目并检查设置

echo 'update source'
checkout scm
echo 'reset config'
sh './gradlew widget-pkg-reset-config -q'
echo 'update dependencies'
sh 'npm install && npm update'

更新（初始化）源码：jenkins行为，更新项目源码checkout SCM （也可用gradle或node执行代码更新）
更新（初始化）gradle依赖：gradle行为，根据gradle配置，更新gradle相关依赖
更新（初始化）npm依赖：node行为，根据pkg版本，更新相关依赖（可能为运行时依赖，也可能为开发时依赖）
检查配置： gradle包装（node行为），检查当前构建环境的正确性，如当前所需的环境变量、当前所设置的仓储地址、当前所需要的所有构建环境的版本等，如缺失则发出警告并中断集成，如不正确则重置正确环境设置。

2、test - 测试

暂略。

3、build source - 构建资源

echo 'Building source..'
sh 'npm run pre-release'
echo 'Build source completed'

构建资源：node行为，进行资源构建。

4、publish source

sh './gradlew widget-pkg-modify-version -q'
sh './gradlew widget-pkg-set-config -q'
echo 'Publish source..'
sh 'npm run publish-to-npm'

修改版本号： gradle包装（node行为），根据插件计算出的currentVersion，临时修改当前构建结果中的package.json文件的version字段。
设置相关发布配置：gradle包装（node行为）。
- 根据当前版本状态选择发布的仓库
- 根据当前环境变量设置当前发布仓储的认证信息
发布资源：node行为，发布构建资源。

5、build doc

echo 'Building doc..'
sh 'npm run build'
echo 'Build doc completed'

构建资源：node行为：构建当前使用手册

6、publish doc

echo 'Publish doc..'
sh './gradlew widget-docs-publish -q'
echo 'source doc completed'

清除已发布文挡：gradle行为，尝试清除已经发布在webdav上的当前版本文档（为了防止文挡重复发布的文件冗余，因为前端静态有文件名有MD5后缀，重复发布无法覆盖）。
修改文挡资源的BASE：gradle包装（node行为），根据文挡发布需要，在webdav的服务目录下，文件夹深度决定url上下文层级，构建后的静态为angular工程，需要上下文，否则无法正常调用web history，所以需要根据当前的currentVersion修改当前文档资源的base href。
发布文档：gradle行为，调用gradle插件进行递归发布。

五、专项剖析

1、不同层级的行为及调用关系分析

行为及调用关系分析.png

2、版本的计算

2.1、版本发布到正式、测试仓库的判断规则

检查当前仓储的最后一次行为（git log）：

如果没有tag，版本从0.1.0-SNAPSHOT开始
如果有tag，但最新的commit不是tag，则根据语义规范发布相应版本的SNAPSHOT版本
如果有tag，且最新的commit是tag，则根据tag发布

2.2、版本递增计算规则

请综合参照：

3、如何指定版本号发布

在发布时遇到的一个问题，java的包发布的版本可以通过gradle变量来指定，那前端的package的版本号如何动态指定？在npm文档搜索无果后，决定写插件去修改“package.json”的version来指定发布版本。

为了避免导致其他问题，建议在初始化的步骤将“package.json”进行checkout。

五、总结和思考

1、如何在“简化技术栈”与“前后端自动化统一”上做出取舍？

这其中的一个关键点为，前端自动化为什么要使用gradle。

在本文的实践中，受我们团队已经存在后端的自动化工作流的影响，为了与其统一版本的升级规则，会用到gradle的“axion-release-plugin”插件，以及在发布到webdav时会用到“uk.co.firstzero.webdav”，出于前后端统一和不重复造轮子考虑，前端才增加gradle的使用。

那么我们不用gradle可以吗？当然可以，你只需要以上提到的内容用node再造一遍轮子，祝你好运。

送一个版本计算的node轮子（不再更新，但可供参考）：axion-release-node-plugin

2、前端有各种lint，sonar相对前端的意义大吗？

后续补充。