1

我们公司目前使用 TFS 进行源代码控制和构建服务器。我们的大部分项目都是用 C/C++ 编写的，但我们也有一些 .NET 项目，如果将来需要使用其他语言，我们不希望受到限制。

我们想使用 Git 进行源代码控制，并且我们正在尝试了解构建服务器的最佳选择。我们已经开始研究 TeamCity，但我们遇到的一些问题可能与我们选择的构建服务器有关：

  1. 构建依赖项——我们希望能够控制每个<project, branch>. 例如，有<MyProj, feature_branch>依赖于<InfraProj1, feature_branch>和<InfraProj2, master>。根据我们所见，要做到这一点，我们可能需要使用 Gradle 或类似的东西来构建我们的项目，而不是普通的 MSBuild。这个对吗？有没有更简单的方法来实现这一点？
  2. 本地构建- 显然我们也希望能够在本地构建项目。当引入项目依赖项时，这会成为一个问题，因为我们需要一种方法来引用这些资源或将它们复制到本地以使构建成功。这通常是如何解决的？

我将不胜感激，但涵盖这些问题的示例设置也将有很大帮助。

4

1 回答 1

1

恕我直言，您提到的两个问题实际上都属于配置管理类别，因此，正如您所说，与构建服务器的选择无关。

项目构建的工作区（无论是集中式还是本地式）应该真正包含构建所需的所有资源。

你怎么能做到这一点？拥有一个项目“元数据” git repo，其中包含一个“内容”文件，其中包含所有项目组件及其依赖项（每个都有自己的 git/other repo）及其确切版本 - 有效地将它们连贯地联系在一起（你可能会发现存储它很有用该组件中的其他元数据也将在未来使用，例如组件特定的 SCM 信息（如果在整个工作区中混合使用 SCM）。

工作区拉包装脚本将首先拉出此元数据git 存储库，解析内容文件，然后根据内容文件信息拉出所有其他项目组件及其依赖项。此类工作空间中的任何构建都将具有所需的所有部分。

当需要修改项目组件中的代码或其中一个依赖项的版本时，您还需要更新元数据git存储库中的此内容文件以反映更新并提交它 - 这就是您的项目取得进展的方式连贯地，作为一个整体。

当然，实际管理依赖是另一回事。那里有很多意见，有些甚至是相互矛盾的。

于 2015-05-29T12:51:52.867 回答