首发于Ant Design

Ant Design 4.0 的一些杂事儿 - CI 篇

前几篇:

在 《Ant Design 4.0 正式版来了!》宣布 4.0 正式版的到来之后,在这里想聊聊技术之外的事儿。不用动太多脑子,当个小品阅读即可~

CI Never End

如果你为 Ant Design 贡献过代码,十有八九会被第一次看到硕长的一列 CI 所吓到:

这个 CI 列表,管理了非常多的事情。上至站点构建预览、下至代码风格都会给你过一遍。当经历无数个时间的等待后,全绿的 pass 会让人非常有成就感。而从维护者角度看,CI 不仅仅是为了绿而绿。它同时帮助我们知晓一个 PR 的状态如何,是否这个 PR 合进来会引入其他的问题。而对于 PR 的贡献者,也可以通过这个长长的列表知晓自己有什么地方做错了需要改进。今天,我们会聊聊 Ant Design 中有哪些关键的 CI。

Test Case

测试自动化是开源项目最常见的 CI,对于 Ant Design 也不例外。我们在 Ant Design 以及相关库有用到 circlecitravis-ci 以及 Github workflow。交叉使用可以尽量减少大量构建导致的排队拥堵情况。我们的测试 CI 主要由 10 个 job 组成一个 workflow,job 之间会有一定的依赖关系:

  • setup: 作为初始化阶段会进行 node modules 的安装工作。并将 node_modules 进行缓存,从而使得后续的 CI 直接使用安装过的缓存从而避免每个 job 都需要重新安装这些 node_modules 。
  • lint: 用于检查代码语法以及风格是否符合一定的规范。作为前端开发者,相信你们一定不会陌生。由于 antd 默认配置了 .eslint.rc ,如果使用 IDE,在开发节点就会进行自动提示。但是实际 PR 过程中,你会遇到一些“匆匆过客”。他们会直接通过 Github 的 edit 功能发起一个 PR,而不经过 IDE。这时候就会遇到一些诸如变量定义、或者空格的 lint 问题。这个 job 很好的帮助我们控制提交的代码规范。
  • test
  • check_metadata: 会处理一些检查工作,比如检查是否有 Demo 被标注为 only (开发时使用的调试标记)等等。
  • compile & dist: 将代码进行编译 和 打包。这个 job 可以帮助我们排除一些 typescript 的定义错误(比如本地的 ts 和 @types/react 版本没有更新而它们其实做了一些不兼容的变更,这个 job 就会帮我们发现)。
  • tests: 其余的 job 则是针对不同的场景进行的测试用例测试。antd 打包会产出 umd、ems 等模块支持文件。每种类型的文件,我们都会运行一遍测试以确保它们会产出相同的执行效果。

当这些 CI 全部跑过后,我们能确保当前的代码不会和原本的逻辑产生冲突。

而与之相配的,会产出一份测试用例的覆盖报告,用于告知代码变更是否有未覆盖到的分支。一般而言,我们总是会要求 commiter 提供代码变更对应的测试用例:

Bundle Size

在 v4 版本,我们增加了诸多功能而整体包尺寸减少了 56%。为了保持这份战果,我们也同步更新了 Bundle Size 的监控。

这个 CI 一般总是绿的,但是一旦报错。作为维护者就会去排查一下是什么导致了总体包大小的变化。一般而言,包大小变化往往聚焦在额外的依赖或者是多版本的依赖问题上。

Site Preview

最后,也是我个人最喜欢的一个 CI。它会基于当前 PR 的代码进行构建,并提供站点预览。从而我们不需要 checkout 到 PR branch 就可以看到 PR 对样式修改的效果。

说到此处,不得不提这有个有趣的历史故事。我们最初引入站点预览使用的是 Netlify 的 CI 构建。Netlify 为开源项目提供了免费的 1000 分钟构建时长,它的配置非常便捷只要关联项目,设置有 PR 时自动构建预览即可:

然而好景不长,作为 UI 库会有大量的预览构建,导致轻而易举的就超出了开源项目的限制。不同于 Now 的策略,超出免费时长后,它仍然会构建,但是到下个月则会要求支付账单。根据历史构建预测,我们发现按照开源项目的运作方式,社区捐赠完全无法覆盖这部分费用。我们发了个推:

由于 Netlify 的服务费非常昂贵,在没有额外赞助的情况下。我们有考虑过是否直接自己租个服务器来跑 CI(是的,两个月的账单足够租个阿里云包年了)。随后,收到 NG-ZORRO 的同学 @谢亚东 建议。我们转而尝试将预览迁移到 Azure pipline + surge 上。

当然,如果你的构建并不多(或者没有预算问题)。推荐尝试 Netlify 的预览构建,体验相当的好。

拥抱社区

就如上面提到的,我们希望尽可能按照社区的方式来运作,所以也尽可能使用开源友好的服务。Azure Pipline 是一个好同志,它支持 Github hook 来进行 PR commit 的构建触发。只是不同于 Netlify,你需要自行构建脚本(但是并不难)。在完成配置后,它便会按照你的设置一步步将预览站点构建出来:

在构建完成后,通过 surge.sh/ 提供的免费的静态站点部署服务将构建产物发布上去。就完成了一个简单版本的 “Netlify 预览”。

如果你也想让你的项目支持 PR 预览,可以参考我们的配置:azure-pipelines.yml

由于脚本都是自行实现的,我们也获得了更多自定义的能力。因而我们也为 PR 添加了个性化的预览状态提示:

预览构建中
构建成功
构建失败

差不多了~

嗯,再次到了尾声。这篇文章主要讲了 CI 相关的内容。还有一些零碎的 CI 没有提及,如果你感兴趣可以到我们的 Github 的 PR 里看看还有哪些。此外,如果你也想尝试开发一些开源项目,也推荐你构建自己的 CI 配置,CI 可以让志愿者更好的参与进来。同时也减少人工参与的重复劳动。让你的项目锦上添花~

发布于 03-16

文章被以下专栏收录