背景
由于政策要求我们需要把不同业务线的代码做隔离，然后把需要隔离的代码仓库迁移到新建的的 gitlab 里。
在这个过程中由于代码包依赖以及版本差异会出现一些编译问题。因此需要一个流程规范来指导这个流程。
目标
- 把特定范围的代码仓库迁移到新的gitlab, 这个特定范围的代码仓库包括：
- 需要迁移的项目的代码仓库。
- 如果需要迁移的服务依赖了原本不需要迁移的项目，这里的依赖是指在项目工程里依赖调用，这些被依赖的原本不需要迁移项目也是需要迁移的。
- 迁移到新的代码仓库后，需要在本地和 CI 上编译成功。
现状
现在的代码包主要包括需要迁移的代码包和不需要迁移的代码包，还有公共三方代码包，三者的调用关系如下：
名称解释
业务线：公司负责一个业务的技术团队。
代码仓库：gitlab 管理的某个项目的代码。
代码包：可交付的代码集合，对可编译的语言交付物就是jar包。而对于非编译语言就是代码集合。
一个代码仓库可能会有多个代码包。
这里的代码包包括两种：
- 如果是编译语言，就是编译后的文件。如，java 编译后形成的 jar 包。
- 如果是解释性语言，就是代码集合。如，js的代码集合等。
代码包管理工具：maven, gradle，nmp, webpack 等管理代码包的软件。
迁移方案
分为迁移优先级和迁移流程。
迁移优先级
- 首先，优先按业务线迁移。
- 梳理一个业务线下的所有项目，优先迁移被其它项目依赖的项目。（如一个项目的jar包经常被其它项目依赖）。
- 一个项目中，优先迁移底层被依赖的代码包。
- 如果依赖其它待迁移的代码包或不需要迁移的代码包，就在新建 的 maven（或其它管理工具） 上传正确版本的 代码包。
- 对于公共三方包，新建 的 maven会自动感知自动从远程公共包自动下载到本地。
迁移流程
-
首先，需要搭建自有的 gitlab，maven, npm,pnpm,webpack。
- Maven 用来管理后端项目。
- npm,pnpm,webpack 用来管理前端项目
-
以业务线为迁移单位，业务线需要提供项目（即gitlab 里的一个代码仓库）迁移文档，要体现业务线下的所有项目，以及每个项目下的代码包，以及代码包的迁移进度，代码包分为三类：
- 正在迁移项目自己维护的代码包。
- 其它待迁移的业务线维护的，同时是当前迁移项目需要依赖的代码包。
- 不需要迁移的业务线维护的，同时是当前迁移项目需要依赖的代码包。
- 首先在新建 gitlab，把项目代码push到gitlab。然后编译，如果编译不成功的原因是缺乏依赖，找到依赖，直到编译成功。
如果依赖是本业务线的，那么就优先处理被依赖的项目代码。
依赖外部的代码包分为两类及解决方案：
- 其它待迁移业务线维护的代码包：跟维护代码包的业务线沟通，选择一个合适版本的代码包上传代码包管理工具。
- 正在迁移项依赖的代码包，这些代码包是不需要迁移的业务线维护的。
- 编译成功后把代码包上传到代码包管理工具。
- 利用CI 再编译一次，如果失败再解决具体问题，如成功就认为这个项目完成了迁移。
对于上面的流程来说，其它待迁移业务线的代码包传到 maven 里了，但是代码还没有上传到 gitlab, 等轮到这个业务线迁移的时候再迁移代码。这时候，可能代码出现了变化，但是不考虑这个问题，只要自己的代码仓库完成迁移和编译就可以。