主页

前面的文章介绍了我主导负责的公司内部研发管理平台(使用人数约为210人)前端项目的技术选型以及架构体系,其采用了BFF架构,有 Node 服务作为中间层以及普遍意义上的 Web 层两个微应用。也介绍了该项目常规情况下的交付部署。 但是常规的交付部署过程繁琐,所以下面的文章介绍了在生产实践中如何便捷持续地交付项目给运维部署升级,基本概念是使用 Docker 镜像以及 Docker Compose 编排镜像,达到一键升级与部署的效果,希望对你有所帮助或启发。

本文介绍了我主导负责的公司内部研发管理平台(使用人数约为210人)前端项目的持续交付部署优化与实践,该项目采用了BFF架构,有 Node 服务作为中间层以及普遍意义上的 Web 层两个微应用,与常规的前端项目有异,交付也有所差别。 在这个过程中如何更便捷地交付运维部署升级,以及该过程不会对开发同事进行开发有所妨碍是主要的优化重心,下面的文章详细介绍了在结合公司实际业务的场景下,BFF架构项目的持续交付部署的优化与实践过程,希望对你有所帮助或启发。

公司的用户反馈处理业务使用了环信工单系统,主要业务流程是: 客服在环信工单后台收到用户反馈,生成技术工单; 技术工单同步到技术管理台; 技术人员在技术管理台收到工单提醒,在技术管理台处理工单; 然后技术人员还需把处理操作额外回填到环信工单后台(因环信通过 api 回填是额外增值服务,未采购)。 从上面的流程总结,技术人员处理一次工单,需要在 技术管理台 与 环信工单后台 进行两次重复操作,使用技术手段实现自动化操作,解放操作人员,为工作赋能是我们技术人员的基本能力,因此有这次的使用 Puppeteer 的自动化网页操作实践。

在团队开发的代码分支实践中,团队成员经常需要提出 PR 来合并代码到主分支或开发分支,而对于开发分支来说并不需要代码合并权限人员来手动 Code Rreview ,只需要检查代码是否落后于目标分支,若无就直接批准合并。 该过程是一个重复的过程，那么我们是否可以自动检查需要合并的代码是否落后，然后自动进行批准、拒绝合并操作呢。查阅了资料发现 git rev-list 命令可以进行源代码与目标代码版本的比对,那么我们就展开讲讲这个命令与它的使用方法。

前面3篇文章，我们介绍了静态代码扫描在团队的重要性以及在实际团队实践中如何使用Gitlab CI/CD配合静态代码扫描实现让团队成员低感知地遵守代码规范。而在之前我们的实践中仅仅是使用了 ktlint 实现了Kotlind的官方代码风格规范检查，但在实际开发过程中，我们还会有更多团队中的代码规范，如日志打印方法的统一、每个activity文件必须要有注释等。 因此，作为Android静态代码扫描实践的收官文章，我将带着大家如何使用 ktlint 写出自定义规则。

在前面的文章讲解了实际实践中如何配合 GitLab CI/CD 落实团队代码风格规范的统一，而其中 GitLab CI/CD 流程需要有 GitLab Runner 工具配套来跑对应项目要执行的流水线job。 当然，配置 GitLab Runner 这件事你可以花10块钱请运维小哥哥喝杯蜜雪冰城，然后让他帮忙。如果你还想对于配置 GitLab Runner 与编写 .gitlab-ci.yml 有所了解，请继续阅读。

前文讲解了为何要进行静态代码扫描以及使用ktlint对项目代码进行扫描检查是否符合Kotlind的官方代码风格规范，在实践中要如何限制团队成员必须遵守规范，毕竟不可能强行要求团队成员每次都使用gradle命令检查代码，我们团队使用的是与GitLab CI/CD流程相结合。

随着技术团队的扩大与开发人员的增长，软件开发必然要实现工程化，因此用静态扫描实现的代码规范管理以及与Gitlab分支管理结合的实践流程就出现了。