我们很高兴地宣布，Software Heritage的开发和操作现在由我们自己完成GitLab实例。它将改进我们的工作流程，并使所有对保存软件历史感兴趣的人都能更容易地做出贡献。感谢我们的系统管理员团队的努力开放技术战略，我们能够从以前的系统平稳过渡。
从制造者到GitLab
Software Heritage于2015年开始，只有几个开发人员和基本的存档功能。与现在几乎所有的软件项目一样，我们必须选择一个工具来协调开发、共享源代码和改进。这些俗称“伪造品”。当时，预制器被认为是最尖端的，所以它被用于软件遗产锻造。
多年来，越来越多的贡献者和团队成员改进了软件遗产。随着新服务的添加，其代码和基础设施变得更大、更复杂。Phalibor基本上忠实地为项目服务，但对于临时贡献者来说，这是一个不寻常的工具，它开启了关于迁移到另一个工具的机会的讨论，这将简化为Software Heritage贡献的过程。在决定迁移的同时，Phalibor背后的公司宣布在2021年停止支持，这加快了迁移的速度。
GitLab公司似乎是最相关的解决方案。它的界面、特性和被鼓励的开发实践（“以Git为中心的分叉和合并请求”）更符合大多数开发人员的期望。就像Phaubritor，GitLab社区版是自由软件。因此，我们可以继续在自己的基础设施上托管和维护开发平台。
2023年1月6日，我们的预制锻件已“冻结”，成功迁移后GitLab软件遗产锻造2023年1月9日正式上台。
这是一段漫长的旅程，我们可以依靠开放技术战略（OTS）创建了一个强大的工具来伪造迁移，称为福盖里.
在这篇博客文章的其余部分，我们想分享一下关于这个漫长而关键但令人兴奋的迁移过程的经验。
一般时间表
- 2019年：决定离开Phalibor
- 2020年：选择GitLab+首次与OTS联系
- 2020-05年：开始与OTS合作，迁移过程设计迭代
- 2021-01：Phalibor/GitLab迁移的首个Forgerie原型
- 2021-02至2022-05：Forgerie和反馈的迭代演示
- 2022-05：首次交付现成脚本
- 2022-05至2022-09：SWH方面的迭代，生成阶段和生产基础设施
- 2022-09:迁移开始
- 2022-10-15:Sysadmin项目在生产中迁移
- 2023-01-09：锻造厂的其余部分在生产中迁移
目标范围
迁移包括锻造的以下项目：
- 任务管理
- 代码存储库
- 代码审查
- 项目管理
- 粘贴（代码段）
其他信息将通过旧伪造网页的“冻结”副本保存，以供历史参考。
对于我们的持续集成（CI），我们选择按原样继续使用Jenkins。我们只需要更新存储库URL。
阶段1：与OTS/Forgerie合作
开放技术战略开发了一个名为福盖里自动将软件项目从一个锻造厂迁移到另一个。
该工具是通用的，使用中间表示法对数据进行建模，可供许多社区使用，无论是从哪个社区迁移到哪个社区。我们选择与OTS签约，以从他们的专业知识中受益，并改进我们认为对面临相同情况的每个软件项目都有用的工具。安对经验的叙述可以在他们的博客上阅读。
阶段2：忘记脚本基准测试和调优
2022年5月至9月，Software Heritage系统管理员团队领导了一系列迭代迁移测试Forgerie脚本的额外开发，以便将迁移过程微调为我们预期的未来GitLab工作流。
映射
我们的一个要求是保持将原始Phalibor任务与迁移问题链接的可能性，如果可能的话，将Phalibtor任务ID与GitLab问题ID映射。
使用开放技术策略，我们还必须决定如何将一些Phalibor概念映射到GitLab实体中。
下面是我们使用的映射列表
| 预制器 |
吉特拉布 |
评论 |
| 任务 |
问题 |
|
| 差异 |
合并请求 |
Forgerie只迁移最新版本的Diff（重点是当前的WIP） |
| 存储库 |
项目 |
|
| 项目 |
标签 |
一些附加到存储库的Phaubritor项目被标记为«Primary projects»，并用于决定在哪些GitLab项目中分配了问题 |
| 粘贴 |
代码段 |
|
| 注释（针对任务或差异） |
注意 |
|
| 内联审核意见（带代码建议） |
讨论 |
|
增量迁移功能
我们需要能够分批执行迁移，以便能够在不同阶段迁移项目组。
阶段3：基础设施项目的第一次迁移冲刺
我们最初专注于迁移与基础设施相关的项目（部署清单等），以此迫使自己“吃自己的狗粮”：负责GitLab迁移的基础设施团队可以开始真正使用GitLab工作流，同时最大限度地减少对团队其他成员的影响。
阶段4：在分段和团队冲刺中完成迁移
在成功迁移基础设施项目和工作流之后，我们在一个完整的暂存GitLab实例中执行了完整的迁移过程（作为实时GitLab数据之上的增量）。这使团队的其他成员能够开始熟悉GitLab，迭代迁移数据的最终形状，并对基于GitLab的开发工作流程进行实验。
2022年最后几周，我们在团队范围内的冲刺中集中了这项实验工作，目标是在2023年第一周（-年底）实现真正的迁移。在这次冲刺中，我们做出了几个非常结构化的决定：
组/权限策略
Phalibor有一个平面模型，并使用Projects作为标记来组织所有实体，而GitLab是在组和子组的层次结构中组织的。我们为Forgerie介绍了一种创建GitLab组层次结构的方法，并根据Phalibor项目“标记”和其他启发将Phalibtor存储库映射到该组层次结构中。
由于Phalibor和GitLab中的权限模型相距甚远，而且我们自己的权限结构也非常简单，因此我们决定在迁移后手动处理GitLab组成员身份和项目权限，利用我们新的嵌套组结构和调用GitLabAPI的简单脚本。Forgerie仅用于在迁移时设置迁移存储库的可见性（公共或私有）和问题的机密性标志。
贡献过程
外部贡献将通过常见的fork-and-merge-request工作流进行：将存储库分叉到您自己的用户名称空间，将您的更改推送到分支，并通过合并请求请求对主项目进行审查。
我们决定对团队成员使用相同的工作流，以保持文档的一致性。
更新的贡献文档将很快在上提供https://docs.softwareheritage.org/devel网站/
项目组织机构
在最后的迭代中，我们意识到将所有Software Heritage工程项目（基础设施和开发）放在一个主要组下将通过利用共享的问题标签和里程碑简化团队工作流。因此，我们修改了Forgerie以直接在顶级组中创建标签。
阶段5：最终迁移
对登台实例的状态感到满意，我们将Phalibor变为只读，并在2023年1月6日的周末执行了到生产实例的迁移。在修复了一个阻止某些任务迁移的单字符拼写错误后，该过程于1月8日星期日晚上完成。GitLab在1月9日如期完成了最后的迁移后步骤。
该团队在接下来的几天里举行了一次全员会议，执行了一些迁移后问题分类操作，并更新了所有自动化（CI和其余部署），以使用GitLab而不是Phalibor。
所有现有的Pharmibor任务都已被锁定，并有一个指向相应GitLab问题的链接，并且已经为通过https的git签出设置了重定向，以最大限度地减少对第三方工作流的中断。推倒https（https）和ssh公司到Phalibor的存储库已被阻止。
接下来的步骤
- 为GitLab中存在的功能设置更多远离Pharmibor的重定向。
- 将剩余的Phalibor数据，尤其是历史代码审查，转换为静态页面（利用Mercurial社区完成的一些工作）。
- 改进CI集成。由于詹金斯大学的一些限制，我们正在考虑迁移到Gitlab CI。
结论
由于仔细且长期的规划、开放技术战略在多次迭代中的高质量贡献以及整个团队的反馈，迁移得以顺利执行。
Forgerie提供的迁移数据的全面性允许保存所有问题历史和大多数代码评审的内容。这使我们能够以最小的中断恢复工作，至少考虑到变化的规模。
我们将Phalibor实例保持为只读模式，以便在需要访问“历史”信息时可以引用它，并且我们将其转换为静态页面，以便能够长期保存此信息。
几周后，我们似乎很少需要在Phalibor中直接查找信息，这证实了对移民的成功和全面报道。
我们相信GitLab将在项目的各个方面为我们不断增加的贡献者改进经验，就像它已经为我们的团队所做的那样。
