通过持续集成构建依赖关系和本地构建

Question

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

我们想使用Git作为源代码控制，我们正在努力了解什么是构建服务器的最佳选择。我们已经开始研究TeamCity，但是我们遇到了一些问题，无论我们选择哪种构建服务器，这些问题都可能是相关的：

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

我很感激任何输入，但是涵盖这些问题的示例设置也将是一个很大的帮助。

Answer 1

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

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

你怎么能实现这一目标？有一个项目“元数据” git repo带有“content”文件，其中包含所有项目组件及其依赖项（每个都有自己的git / other repo）及其确切版本 - 有效地将它们连贯地捆绑在一起（您可能会发现将其他元数据存储在此组件中非常有用，例如，如果在工作区中混合使用SCM，则可以使用特定于组件的SCM信息）。

工作区提取包装器脚本首先会提取此元数据 git repo，解析内容文件，然后根据内容文件信息。在这样的工作空间中的任何构建都将拥有它所需的所有部分。

如果要修改项目组件中的代码或其中一个依赖项的版本，您还需要更新元数据中的内容文件git repo反映更新并提交它 - 这就是你的项目整体上连贯一致的方式。

当然，实际管理依赖关系是另一回事。有很多意见，有些甚至是冲突的。