learn - 项目架构演变-05（代码迁移篇）

创作背景

我在负责一个技术团队孵化项目，在初期投入市场，效果颇佳。

随后批复各种资源，比如服务器、存储、域名等都不再是借用临时使用。

其中代码都仓库转移以及代码依赖库引用调整也是其中一个重要的部分。

老板们都喜欢这么说：这个不紧急，但重要‼️

目标

• 完成代码库的代码迁移事项。
• 完成依赖性调整。
• 验证可行性。

行动

代码迁移过程

项目导出过程：在旧的GitLab实例中，您需要登录并访问您想要迁移的项目。在项目页面上，找到并点击“Settings(设置) > General（通用）”，滚动到“Advanced”部分，点击“Export project”。GitLab将开始打包项目数据，并在完成后通过邮件发送下载链接。

项目导出过程：在新的GitLab实例中，登录您的账户后点击“New project”，选择“Import project”，然后点击“GitLab export”选项，上传之前导出的项目文件，并开始导入。导入完成后，GitLab会创建一个新的项目，并尽可能复原旧项目的状态。

依赖包引用方式修改

1. 配置~/.ssh/id_rsa.pub 的内容到“个人偏好 > SSH密钥”授权

2. 尝试 git clone 代码，http（https） 和git 地址的都要尝试下。

   克隆项目http地址，需要填写账户和密码，可以永久存储，执行命令：

   git config --global credential.helper store

3. 修改其他项目依赖性

   go.mod

   module wangfuyu
      
   go 1.22.10
      
   require (
   	gitlab01.360club.com/xiaoyu/core v1.10.5
   	....
   )
      
      
   replace (
   	gitlab01.360club.com/xiaoyu/core v1.10.5 => gitlab02.360club.com/wangfuyu/core v1.3.4
      
   )
      
   

   其他业务逻辑代码可以 不动一兵一卒 ,能快速完成切换。

4. 部署机器亦可按照此方式。

结果

1. 验证构建过程是否正常。
2. 验证程序运行过程是否平稳。
3. 收回旧的仓库地址账号权限。

总结

通过实际操作，确认项目业务未受到影响，纯粹开发人员和运维同学一起参与调整，代码改动小（只有go.mod）。

误区：有开发同学会把整个包名也一起改掉，然后让引用改包的项目也要一起调整代码引入。

个人认为可改可不改，如果时间充裕，可以调整，避免新人加入时，对包名产生困惑。