0

这不完全是 Gradle 问题。但更一般的构建问题。我们有一些项目结构如下：

-- A  (by team 1)
  -- build.gradle
  -- settings.gradle
-- B (by team 1,3)
  --build.gradle
-- C (by team 2)
-- D (by team 3)

它们是独立的 CVS 模块。A、B 和 D 是 java 项目，由两个团队（团队 1,3）管理。C 是由另一个团队管理的 C++ 项目 (2)。B 通过 JNI 使用 C。（C是C++这个事实并不重要，关键是它是由另一个团队开发和管理的。）有两个应用程序，A是应用程序1的入口，A->B->C；而D是应用程序2的入口点，D->B->C. 发展通常涉及所有三个层面的变化。所有三个团队坐在一起并不断交流。在实践中，我们（团队 1）可能需要对 C 中的应用程序 1 进行一些更改；团队 2 在 C 上工作并给我们一个临时副本；集成后我们可能需要进行一些进一步的更改。我们会为了一个问题来回走几轮。同样适用于应用程序 2。

目前，A、B 和 D 由各种 ant 脚本管理，C 由 make 管理。我们开始探索新工具，尤其是 Gradle。在我们的第一个剪辑中，A 将 B 作为一个子项目（在 Gradle 意义上），它们总是一起构建和发布。我们也总是使用 C 的头文件（从 windows 中的源代码自己编译或获取最新的 Jenkins 构建），当我们对构建感到满意时，我们标记所有三个项目。我们最近采用了一个内部 Artifactory 存储库。我们正在考虑如何管理依赖和版本控制。完成后，我们也会将其介绍给模块 D 的团队 3。

  1. 我们可以尝试将 C 作为 A 的子项目，然后始终从头开始为所有三个构建。同样包括 C 和 B 作为 D 的子项目。例如，应用程序名称可以在版本名称中。
  2. 或者，我们总是可以依赖存储库中固定版本的 C。

在 2 中，我们不能完全依赖 C 的头部/快照，因为这可能涉及它们的开发并且可能不稳定。但是我们需要如此频繁地更改它们，以至于为每个 C 更改都放置一个新版本似乎是不切实际的。

我们想知道这种设置的最佳实践是什么？在互联网上快速搜索不会产生太多结果。谁能给我们一些建议或指点我一些书籍或文件？

太感谢了。

4

1 回答 1

3

正如我从整个描述中看到的那样，似乎在开发期间（我想也在生产中）所有 3 个项目都非常紧密耦合。所以为了工作方便，我将使用第一个场景。我还将一起构建所有项目，将它们标记在一起并保持相同的版本控制模式 - 通常，即使它是分开的，这也是一个项目。

第一个场景可以持续到没有第 3 方（外部）应用程序/库/团队使用任何项目（我想它只能是 C 项目）。然后可能会发生向后兼容性问题/拉取请求和其他问题，并且应该将提到的项目分开。如果没有机会发生这种情况，您不应该过多打扰。但是请记住良好的（语义）版本控制，并标记存储库以始终确定哪个版本部署到哪个环境。

更新

问题更新后。

如果您有类似的依赖路径A->B->C，D->B->C我将重新组织项目结构。B应该成为两者的子项目，A或者D可能不是子项目，而是添加到这些项目的外部库。B并且C应该是一个独立的项目，B依赖于C.

所有三个项目 ( A, D, B with C) 都应该单独进行版本控制 (尤其是B with C) 因为这是客户 (A和D) 的公共部分。

现在，为了方便开发，您可以添加A和D快照库，这些库将经常在 CI 服务器上构建，然后更新到工件。这将允许您对B项目A和D. B但是（因此）的稳定发布C应该完全分开维护。

我希望我能很好地理解这个问题并帮助你一点。

PS请考虑使用gitflow- 分支模型。然后您可以在 dev 分支中使用 SNAPSHOT 版本和B在 release 中使用稳定版本。

于 2014-04-24T19:53:57.380 回答