对于团队、或者需要维护多个项目场景,统一的构建工具链很重要, 这套工具应该强调”约定大于配置”,让开发者更专注于业务的开发。笔者在<为什么要用vue-cli3?>文章中提出了vue-cli3更新有很多亮点,非常适合作为团队构建工具链的基础:

  • 首先这类工具是推崇’约定大于配置’。即按照他们的规范,可以实现开箱即用,快速开发业务. 在团队协作中这点很重要,我们不推荐团队成员去关心又臭又长的webpack构建配置
  • vue-cli3抽离了cli service层,可以独立更新工具链。也就是说项目的构建脚本和配置在一个独立的service项目中维护,而不是像以前一样在每个项目目录下都有webpack配置和依赖. 这样做的好处是独立地、简单地升级整个构建链
  • 灵活的插件机制。对于团队的定制化构建应该封装到插件中,这样也可以实现独立的更新。





我们可以选择第三方CLI, 当然也定制自己的构建链,按照上面说的这个构建链应该有以下特点:

  • 强约定,体现团队的规范。首先它应该避免团队成员去关心或更改构建的配置细节,暴露最小化的配置接口。 另外构建工具不仅仅是构建,通常它还会集成代码检查、测试等功能
  • 方便升级。尤其是团队需要维护多个项目场景, 这一点很有意义

下面是社区上比较流行的构建工具. 当然,你也可以根据自己的团队情况开发自己的CLI, 但是下面的工具依然很有参考价值

  • create-react-app - 🔥零配置开始React开发
  • vue-cli - 🔥零配置、渐进增强的项目构建CLI
  • parcel - 零配置的Web应用打包工具
  • Fusebox - 高速易用的打包工具
  • microbundle - 零配置, 基于Rollup,适合用于打包‘库’

⬆️回到顶部

1.3 发布工作流规范

发布工作流指的是将‘软件成品’对外发布(如测试或生产)的一套流程, 将这套流程规范化后,可以实现自动化.
举个例子, 一个典型的发布工作流如下:
发布构建规范 - 图1

  • 代码变更
  • 提交代码变更到远程版本库
  • 程序通过CI测试(例如Travis变绿)
  • 提升package.json中的版本
  • 生成CHANGELOG
  • 提交package.json和CHANGELOG.md文件
  • 打上Tag
  • 推送

如果你遵循上面的规范,那么就可以利用社区上现有的工具来自动化这个流程. 这些工具有:

⬆️回到顶部

1.4 持续集成

将整套开发工作流确定下来之后, 就可以使用持续集成服务来自动化执行整个流程。比如一个典型的CI流程:
发布构建规范 - 图2
持续集成是什么,有什么意义呢?
我们需要持续集成拆成两个词分别来理解, 什么是持续? 什么是集成?
持续(Continuous), 可以理解为’频繁’或者‘连续性’. 不管是持续集成还是敏捷开发思维、看板,都认为‘持续’是它们的基础。
举一个通俗的例子,比如代码检查,‘持续的’的代码检查就是代码一变动(如保存,或者IDE实时检查、或者提交到版本库时)就马上检查代码,而‘非持续’的代码检查就是在完成所有编码后,再进行检查。对比两者可以发现,持续性的代码检查可以尽早地发现错误,而且错误也比较容易理解和处理,反之非持续性的代码检查,可能会发现一堆的错误,失之毫厘谬以千里,错误相互牵连,最终会变得难以收拾。
‘持续’的概念,可以用于软件开发的方方面面,本质上就是把传统瀑布式的软件开发流程打碎,形成一个个更小的开发闭环,持续地输出产品,同时产品也持续地给上游反馈和纠正
发布构建规范 - 图3
那什么是‘集成’呢?狭义的集成可以简单认为是‘集成测试’吧. 集成测试可以对代码静态测试、单元测试、通过单元测试后可以进行集成测试,在应用组成一个整体后在模拟环境中跑E2E测试等等。也就是说,在这里进行一系列的自动化测试来验证软件系统。
广义的持续集成服务,不仅仅是测试,它还衍生出很多概念,例如持续交付、持续部署,如下图
发布构建规范 - 图4
OK, 总结一下为什么持续集成的好处:

  • 尽早发现错误,快速试错。越早发现错误,处理错误的成本越低
  • 自动化工作流,减少人工干预。人类比机器容易犯错, 而且机器擅长做重复的事情

对于持续集成规范一般会定义这些内容:

  • 执行的环境. 比如容器、Node版本、操作系统等等
  • 触发的条件。比如定时触发、在哪个分支触发、会触发什么任务等等
  • 执行的任务
  • 划分持续集成的阶段. 比如
    • 检查:包括单元测试和代码lint. 所有push到版本库的代码都会跑这个阶段. 一般可以在提交title中包含[ci skip]来跳过这个阶段
    • 构建: 对前端项目进行构建. 只有打上版本tag的提交或release分支会跑构建任务
    • 发布: 将前端的构建结果进行交付/发布. 只有打上版本tag的提交或者release分支在构建成功后会跑发布任务
  • 定义持续集成脚本模板

常用的CI服务:

扩展