We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
互联网公司野蛮生长之初,都会诞生各种各样的内部平台和工具。开发者在开发和部署时,需要在各个平台频繁切换。这些平台维护团队不一,操作流程不一,求助途径不一,给开发者带来不少额外的心智负担。
这个时候,一般公司内部会有一个工程效率组或者基础架构组出手,通过新建一个 CICD 平台来解决多平台跳转问题。CICD,Continuous Integration and Continuous Deployment,是指持续集成和持续部署。
好了,大多数开发不用再频繁跳转页面和平台了,心智负担骤降。可惜对于前端开发来说,开发流程不见得精简很多。前端的项目多以静态页面为主,其灰度发布和回滚,都比其他项目简单得多。但使用公共的 CICD 平台时,往往被迫走很多和前端无关的流程,用起来也比较麻烦。
于是有了我们前端大组专用的 CICD 平台。它服务于公司内的百人前端团队,一站式解决前端的持续集成和部署问题。
其发展,大体可分为整合现有流程、扩展任意流程、建设特色能力三个阶段。
流程整合前,开发者需要和多个平台打交道。主要的平台是:
整合后,开发者只需要在 CICD 平台操作即可,免去了多平台跳转和多平台申请权限的麻烦。
整合方法就是通过 CICD 平台调用其他平台的 API。如果某个平台没有开放这个功能的 API,就联系该团队添加。如果某个平台已经停止维护,我们通过爬虫去做了个封装,包装成为有对外 API 的样子。
另外,和一般的 CICD 平台相比,我们平台的创建项目时做的事情更多。通过它创建的项目,是基于设定的模板 fork 出来的。它们有相同的基础配置,和自动生成的模板配置,创建之后就能运行和发布。做到了 UI 界面配置,代码开箱即用。
业务的需求是无限的。即使整合好了现有流程,业务还是会不断提出一些平台无力承载的需求。这时扩展任意流程的能力就非常必要。让业务自己开发相关需求,然后集成到 CICD 平台即可。
怎么集成呢?我们先看下业界的做法,基本都是定义一些基础的 job,然后在 pipeline 的配置文件中自由组装 job。当然不同系统的“pipeline”和“job”的用词可能不同,但都是原子任务和装配流水线的意思。感兴趣的可以进一步了解开源的 Jenkins,Gitlab,大厂自研的美团 Pipeline,字节的宇宙大系统等。
前端 CICD 平台的解决思路类似。我们不需要这么高的组装自由度,因为大多前端特有的流程,都被我们内化到平台中了。前端发布的 pipeline 在项目设置中配置,业务 job 使用 webhook 的形式接入。
界面截图如下:
接入点目前只开放发布前和发布后。流程和接口规范可以参考下图:
好了,现在平台已经整合好了现有流程,也能扩展任意流程了,是不是万事大吉了呢?如果是的话,那平台存在的意义就不大了。用不着做“前端”的 CICD 平台。平台针对前端的定制功能,是前端 CICD 平台重要的加分项。
checklist 是一种成本低,效用高的工具。上线前,我们可以使用 checklist 来确认产品验收情况、外链情况、埋点情况、配置上线情况等,从而有效避免低级错误。不同业务线的 checklist 可以配置不一样。
需求上线后,需要及时验收和观察。不是所有的问题都能通过自动监控发现,人工观测还是必要的。平台会在上线后定时推送观察提醒,减少因观察不及时导致的问题。同时,我们提供二维码生成器,方便开发者在端内打开。
在一个典型的前后端分离的项目中,有测试、灰度、生产三个环境。前端项目中包含一份代码,三份配置。产物打包时,测试环境产物是根据代码和测试环境配置生成的,它的 XHR 请求 url 应该是后端的测试域名。以此类推,灰度产物应该访问后端的灰度域名,生产产物应该访问后端的生产域名。
如果开发测试阶段,后端请求域名写在了代码,而非配置文件中呢?灰度和生产的产物,就会访问后端的测试域名了。这种错误在测试和灰度阶段可能无法发现,等上了生产,就会酿成事故。
针对这种情况,我们有一些 webpack 插件等工具可以使用。但是 webpack 插件起效需要重新安装发布,而存量项目有几百个,改造成本太大。所以需要前端 CICD 平台提供统一的产物域名扫描功能,用于兜底。
技术细节方面,我们在构建过程插入一行 shell 脚本,将特定后缀的产物都当做文本处理。通过正则规则,识别出疑似域名的字符串。字符串数组去重后,将它们发送到服务端统一汇总处理。处理结果通过公司的 IM 消息异步推送。
平台统一处理的好处是能统一管理域名黑白名单。而且能保证所有上线的项目都能有效覆盖到。
当然,平台针对前端的定制功能不止以上几点。有些实用功能是为了解决特定的历史遗留问题的,虽然对我们很重要,但不在这里展开讲述了。
这些前端特色功能规范了流程,降低了线上事故率,提升了特定场景的效率。
CICD 平台是通过提升研发效率,间接产生业务价值的平台。我们不会像一线大厂那样不计成本地卷效率,而是在人力投入与团队提效之间做了平衡。一年半以来,间断投入 1.5 人力,才建设成为今天的前端 CICD 平台。
希望我们的历程,能给正在建设平台的你一点参考。
The text was updated successfully, but these errors were encountered:
No branches or pull requests
互联网公司野蛮生长之初,都会诞生各种各样的内部平台和工具。开发者在开发和部署时,需要在各个平台频繁切换。这些平台维护团队不一,操作流程不一,求助途径不一,给开发者带来不少额外的心智负担。
这个时候,一般公司内部会有一个工程效率组或者基础架构组出手,通过新建一个 CICD 平台来解决多平台跳转问题。CICD,Continuous Integration and Continuous Deployment,是指持续集成和持续部署。
好了,大多数开发不用再频繁跳转页面和平台了,心智负担骤降。可惜对于前端开发来说,开发流程不见得精简很多。前端的项目多以静态页面为主,其灰度发布和回滚,都比其他项目简单得多。但使用公共的 CICD 平台时,往往被迫走很多和前端无关的流程,用起来也比较麻烦。
于是有了我们前端大组专用的 CICD 平台。它服务于公司内的百人前端团队,一站式解决前端的持续集成和部署问题。
其发展,大体可分为整合现有流程、扩展任意流程、建设特色能力三个阶段。
整合现有流程
流程整合前,开发者需要和多个平台打交道。主要的平台是:
整合后,开发者只需要在 CICD 平台操作即可,免去了多平台跳转和多平台申请权限的麻烦。
整合方法就是通过 CICD 平台调用其他平台的 API。如果某个平台没有开放这个功能的 API,就联系该团队添加。如果某个平台已经停止维护,我们通过爬虫去做了个封装,包装成为有对外 API 的样子。
另外,和一般的 CICD 平台相比,我们平台的创建项目时做的事情更多。通过它创建的项目,是基于设定的模板 fork 出来的。它们有相同的基础配置,和自动生成的模板配置,创建之后就能运行和发布。做到了 UI 界面配置,代码开箱即用。
扩展任意流程
业务的需求是无限的。即使整合好了现有流程,业务还是会不断提出一些平台无力承载的需求。这时扩展任意流程的能力就非常必要。让业务自己开发相关需求,然后集成到 CICD 平台即可。
怎么集成呢?我们先看下业界的做法,基本都是定义一些基础的 job,然后在 pipeline 的配置文件中自由组装 job。当然不同系统的“pipeline”和“job”的用词可能不同,但都是原子任务和装配流水线的意思。感兴趣的可以进一步了解开源的 Jenkins,Gitlab,大厂自研的美团 Pipeline,字节的宇宙大系统等。
前端 CICD 平台的解决思路类似。我们不需要这么高的组装自由度,因为大多前端特有的流程,都被我们内化到平台中了。前端发布的 pipeline 在项目设置中配置,业务 job 使用 webhook 的形式接入。
界面截图如下:
接入点目前只开放发布前和发布后。流程和接口规范可以参考下图:
建设特色能力
好了,现在平台已经整合好了现有流程,也能扩展任意流程了,是不是万事大吉了呢?如果是的话,那平台存在的意义就不大了。用不着做“前端”的 CICD 平台。平台针对前端的定制功能,是前端 CICD 平台重要的加分项。
checklist 功能
checklist 是一种成本低,效用高的工具。上线前,我们可以使用 checklist 来确认产品验收情况、外链情况、埋点情况、配置上线情况等,从而有效避免低级错误。不同业务线的 checklist 可以配置不一样。
验收观察功能
需求上线后,需要及时验收和观察。不是所有的问题都能通过自动监控发现,人工观测还是必要的。平台会在上线后定时推送观察提醒,减少因观察不及时导致的问题。同时,我们提供二维码生成器,方便开发者在端内打开。
产物域名扫描功能
在一个典型的前后端分离的项目中,有测试、灰度、生产三个环境。前端项目中包含一份代码,三份配置。产物打包时,测试环境产物是根据代码和测试环境配置生成的,它的 XHR 请求 url 应该是后端的测试域名。以此类推,灰度产物应该访问后端的灰度域名,生产产物应该访问后端的生产域名。
如果开发测试阶段,后端请求域名写在了代码,而非配置文件中呢?灰度和生产的产物,就会访问后端的测试域名了。这种错误在测试和灰度阶段可能无法发现,等上了生产,就会酿成事故。
针对这种情况,我们有一些 webpack 插件等工具可以使用。但是 webpack 插件起效需要重新安装发布,而存量项目有几百个,改造成本太大。所以需要前端 CICD 平台提供统一的产物域名扫描功能,用于兜底。
技术细节方面,我们在构建过程插入一行 shell 脚本,将特定后缀的产物都当做文本处理。通过正则规则,识别出疑似域名的字符串。字符串数组去重后,将它们发送到服务端统一汇总处理。处理结果通过公司的 IM 消息异步推送。
平台统一处理的好处是能统一管理域名黑白名单。而且能保证所有上线的项目都能有效覆盖到。
当然,平台针对前端的定制功能不止以上几点。有些实用功能是为了解决特定的历史遗留问题的,虽然对我们很重要,但不在这里展开讲述了。
这些前端特色功能规范了流程,降低了线上事故率,提升了特定场景的效率。
写在最后
CICD 平台是通过提升研发效率,间接产生业务价值的平台。我们不会像一线大厂那样不计成本地卷效率,而是在人力投入与团队提效之间做了平衡。一年半以来,间断投入 1.5 人力,才建设成为今天的前端 CICD 平台。
希望我们的历程,能给正在建设平台的你一点参考。
The text was updated successfully, but these errors were encountered: