在封闭的企业环境中使用 Git 进行目标平台版本控制

Question

上下文

我们开发了许多插件，这些插件被组装到 Eclipse RCP 3.X 应用程序中。我们使用基于 P2 存储库的单一目标平台，因为这是 Tycho 支持的唯一版本。

目标平台 VS SCM

我们的互联网访问受到很大限制。我们无法访问公开可用的 P2 存储库，即使我们配置代理。 因此，我们下载 P2 存储库 zip 并将它们放入源代码控制中，以便团队可以共享它们并进行版本控制。 但是，我们认为在 SCM 下包含二进制内容通常是一种不好的做法。

我们正准备从 ClearCase 迁移到 Git。在这样做的同时，我们正在考虑更好地改变我们管理目标平台的方式。 我们已经考虑过不同的场景，但我们缺乏经验来衡量它们的优缺点。 以下是我们思考的第一个结果：

场景 1：为目标平台使用单独的 Git 存储库

• 优点：
  • 插件共享
  • 我们稍后可以回到目标平台的“物理”先前版本
  • 更改目标平台就像操作文件一样简单
• 缺点：
  • SCM 中的二进制文件
  • 每个存储库实例都使用大量磁盘来保存目标平台的整个历史记录

场景 2：将 Nexus 与插件一起用于 P2 存储库管理

• 优点：
  • 插件共享
  • 轻量级存储库：只需要对 foo.target 文件进行版本控制
• 缺点：
  • 我们以前从未使用过 Nexus
  • 更改目标平台内容更复杂
  • 我们需要手动保存目标平台内容的每个版本的存档副本

问题

您如何在封闭的公司网络中使用 Git 处理目标平台版本控制？ 您如何看待上述情况及其各自的优缺点？ 您能否提出其他解决方案？

Answer 1

使用 Nexus 和 Nexus Unzip Plugin，有一个非常好的解决方案可以满足您拥有可重现目标平台和独立于 Internet 访问构建的需求：

• 设置 Nexus，并确保您有一个可以部署到的 m2 存储库，例如deploy-file。
• 将您需要的 p2 存储库下载为 zip 存档（如果这些 zip 存档不提供下载，您也可以自行创建）。
• 使用非 SNAPSHOT 版本将压缩的 p2 存储库部署到 Nexus m2 存储库。 Nexus 中的非 SNAPSHOT 工件是不可变的，因此当您通过 Nexus 上的 URL 引用 p2 存储库时，您将始终获得相同的内容。
• 安装Nexus Unzip Plugin 并将其配置为“影子”/提供您已部署到的存储库中的内容。通过这种方式，压缩后的 p2 存储库会获得一个“解压缩” URL，使它们看起来像 Eclipse 和/或 Tycho 的常规 p2 存储库。
• 最后，在您的 Nexus 中创建一个仅引用 p2 存储库的目标定义文件，并将该文件放入您的 git 存储库。

我们已经在公司环境中成功使用此设置已有一段时间了，因此我建议您也尝试这种方法。

这与您的解决方案 2 类似，但使用了不同的 Nexus 插件。对于所描述的解决方案，您不需要任何插件来明确“p2 存储库支持”。此外，您无需对目标平台内容进行任何额外的归档。

---

免责声明：Nexus Unzip 插件由 Tycho 项目提供，我是该项目的提交者。