通过持续集成构建依赖项和本地构建 [英] Build dependencies and local builds with continuous integration

问题描述

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

我们希望使用Git作为源代码控制，我们正试图理解什么是构建服务器的最佳选择。我们已经开始调查TeamCity，但是有一些问题，我们遇到了麻烦，这可能是相关的，无论我们选择的构建服务器：

1. 构建依赖关系 - 我们希望能够控制每个< project，branch> 的构建依赖关系。例如，具有< MyProj，feature_branch> 取决于< InfraProj1，feature_branch> 和< InfraProj2，master> 。
   从我们所看到的，我们可能需要使用Gradle或类似的东西来构建我们的项目，而不是纯MSBuild。它是否正确？是否有更简单的方法来实现这一点？


2. 本地构建 - 显然，我们希望能够在本地构建项目。当引入项目依赖性时，这变成了一个问题，因为我们需要一种方法来引用这些资源或在本地复制它们以使构建成功。这通常是如何解决的？

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

解决方案

IMHO你提到的两个问题真的在配置管理类别，因此，正如你所说，与构建服务器无关

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

如何实现？使用包含所有项目组件及其依赖关系（每个都有自己的git /其他库）以及其精确版本的内容文件夹创建项目元数据 - 有效地将它们一致地捆绑在一起（您可能会发现，在组件中存储其他元数据也是有用的，例如，如果在整个工作空间中使用SCM的混合，就像组件特定的SCM信息一样）。

工作区拉包装脚本首先会拉这个元数据 git仓库，解析内容文件，其他项目组件及其依赖关系根据内容文件信息。在这种工作空间中的任何构建都将具有它所需要的所有部分。

当时间来修改项目组件中的代码或一个依赖项的版本时，还需要更新元数据 git repo中的内容文件，以反映更新并提交更新 - 这是项目整体的进度。 p>

当然，实际上管理依赖是另一回事。有些意见，有些甚至有冲突。

Our company currently uses TFS for source control and build server. Most of our projects are written in C/C++, but we also have some .NET projects and wouldn't want to be limited if we need to use other languages in the future.

We'd like to use Git for our source control and we're trying to understand what would be the best choice for a build server. We have started looking into TeamCity, but there are some issues we're having trouble with which will probably be relevant regardless of our choice of build server:

1. Build dependencies - We'd like to be able to control the build dependencies for each <project, branch>. For example, have <MyProj, feature_branch> depend on <InfraProj1, feature_branch> and <InfraProj2, master>. From what we’ve seen, to do that we might need to use Gradle or something similar to build our projects instead of plain MSBuild. Is this correct? Are there simpler ways of achieving this?
2. Local builds - Obviously we'd like to be able to build projects locally as well. This becomes somewhat of a problem when project dependencies are introduced, as we need a way to reference these resources or copy them locally for the build to succeed. How is this usually solved?

I'd appreciate any input, but a sample setup which covers these issues will also be a great help.

解决方案

IMHO both issues you mention fall really in the config management category, thus, as you say, unrelated to the build server choice.

A workspace for a project build (doesn't matter if centralized or local) should really contain all necessary resources for the build.

How can you achieve that? Have a project "metadata" git repo with a "content" file containing all your project components and their dependencies (each with its own git/other repo) and their exact versions - effectively tying them together coherently (you may find it useful to store other metadata in this component down the road as well, like component specific SCM info if using a mix of SCMs across the workspace).

A workspace pull wrapper script would first pull this metadata git repo, parse the content file and then pull all the other project components and their dependencies according with the content file info. Any build in such workspace would have all the parts it needs.

When time comes to modify either the code in a project component or the version of one of the dependencies you'll need to also update this content file in the metadata git repo to reflect the update and commit it - this is how your project makes progress coherently, as a whole.

Of course, actually managing dependencies is another matter. Tons of opinions out there, some even conflicting.

这篇关于通过持续集成构建依赖项和本地构建的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！