GitLab CI 之前端 Webpack 实践

云计算 2023-01-04 三掌柜 手机阅读

从 GitLab 8.0 开始，GitLab 开始集成 CI（持续集成） 功能。只需要在服务器上添加一个 Runner，同时在项目中添加一个 .gitlab-ci.yml 文件，就可以进行 CI。在 GitLab 搭建与配置 中笔者记录了从零开始搭建 GitLab 服务的整个流程。在 GitLab CI 持续集成 中笔者交代了 GitLab CI 的一些基本概念，并给出了一个简单的 Demo。本文主要讨论的是使用 Git 作为代码仓库时，多人开发的工作模式；在前端开发过程中，如何利用 GitLab-CI 工具，自动化编译 Webpack 项目。

1. 问题与需求

笔者从事 SaaS 开发，简单描述下目前团队项目开发的现状。SaaS 基于 PaaS 提供的框架和 CI/CD 功能进行开发、预发布、发布，使用 SVN 进行代码的管理。PaaS 提供了 SaaS 开发人员快速开发应用的能力。但是，在多人合作开发的项目中，SVN 提供的分支功能不便于管理分支、合并代码。相比较于 SVN，Git 拉取代码速度快、允许上千个并行开发的分支、完全分布式，受到大量开发人员的喜爱。多人合作开发项目时，倾向于使用 Git 来管理代码，而在准备部署时才提交到 SVN。为了缩短流程，一方面，可以推动 PaaS 提供 Git 代码托管服务；另一方面，可以通过一定的工具来自动化整个流程（Git -> SVN），节省开发部署的时间。另外一个问题是，前端团队使用的是 Webpack 模块打包管理工具，前端工程需要打包编译。针对一些复杂的项目，可能会有多人参与前端的开发工作。有时，前端人员在打包 Webpack 项目之前，没有拉取最新代码，导致其他前端人员开发的功能没有及时更新到最新的版本文件中。幸运的是，GitLab 提供 CI 的功能，能解决上面的问题。GitLab CI 提供了在服务器上执行脚本、自动化流程的能力。

2. Git 工作流

通常 Git 的工作流程，采用的是功能驱动式开发。先有需求，再有功能分支或补丁分支。完成开发后，该分支就合并到主分支，然后删除分支。广泛使用的工作流程有三种：
  • Git flow

  • Github flow
  • Gitlab flow
  • after_script定义任何 Jobs 运行完后都会执行的命令。（要求 GitLab 8.7+ 和 GitLab Runner 1.2+）
  • variables && Job.variables定义环境变量。如果定义了 Job 级别的环境变量的话，该 Job 会优先使用 Job 级别的环境变量。（要求 GitLab Runner 0.5.0+）
  • cache && Job.cache定义需要缓存的文件。每个 Job 开始的时候，Runner 都会删掉 .gitignore 里面的文件。如果有些文件 (如 node_modules/) 需要多个 Jobs 共用的话，我们只能让每个 Job 都先执行一遍 npm install。（要求 GitLab Runner 0.7.0+）
  • Job.script定义 Job 要运行的命令，必填项
  • Job.stage定义 Job 的 stage，默认为 test
  • Job.artifacts定义 Job 中生成的附件。当该 Job 运行成功后，生成的文件可以作为附件 (如生成的二进制文件) 保留下来，打包发送到 GitLab，之后我们可以在 GitLab 的项目页面下下载该附件。
  • 内存 64G
  • 硬盘 300G，10000RPM，SAS
  • https://guides.github.com/introduction/flow/index.html
  • https://www.ibm.com/developerworks/cn/java/j-lo-git-mange/index.html
  • https://docs.gitlab.com/ce/ci/variables/
  • https://gitlab.com/gitlab-org/gitlab-ce/issues/18106
  • https://hackernoon.com/setting-up-ci-cd-on-gitlab-step-by-step-guide-part-1-826385728223
  • https://www.perforce.com/perforce/r16.3/manuals/gitswarm/ci/yaml/README.html