Question

这不是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-＆gt; B-＆gt; ;ç; D是应用程序2的入口点， D-> B-> C 。发展往往涉及所有三个层面的变化。三个团队坐在一起，不断沟通。在实践中，我们（团队1）可能需要对C中的应用程序1进行一些更改;团队2在C上工作并给我们一份临时副本;集成后我们可能需要进一步的更改。对于一个问题，我们会来回几轮。同样适用于申请2.

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

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

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

我们想知道这种设置的最佳做法是什么？在互联网上快速搜索不会产生太多结果。任何人都可以给我们一些建议或指向一些书籍或文件吗？

非常感谢你。

Answer 1

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

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

<强>更新

更新问题后。

如果你有像A->B->C和D->B->C这样的依赖路径，我会重新组织项目结构。 B应该成为A和D的子项目，或者可能不是子项目，而是添加到这些项目的外部库。 B和C应该是一个单独的项目，B依赖于C。

所有三个项目（A，D，B with C）都应单独进行版本控制（尤其是B with C），因为这是客户的常见部分（{{1} }和A）。

现在，为方便开发，您可以添加{CI}服务器上经常构建的D和A快照库，然后更新为artifactory。这样，您就可以对D引入更改，并在项目B和A中快速显示这些更改。但是D（以及B）的稳定释放应该完全单独维护。

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

P.S。请考虑使用C - 分支模型。然后您可以在dev分支中使用SNAPSHOT版本，在发布中使用稳定版本的gitflow。

使用（maven）存储库和Maven / Gradle管理多个项目的最佳实践？

1 个答案: