在源代码控制下创建构建答案

【问题标题】：Creating build under source control在源代码控制下创建构建
【发布时间】：2011-10-10 02:31:25
【问题描述】：

我正在尝试克服我的基本结构来管理采用 alm 实践。

首先，我已经对我的源文件夹结构进行了结构化，在我的主分支下，我确实将文件夹作为构建。我打算将我的构建（ci、nigthly、手动）存储在每个分支下。然而，当我创建一个新的构建定义时，我坚持使用一个字段。

谢谢。

【问题讨论】：

【解决方案1】：

将构建输出存储在版本控制中没有任何好处，但如果您的流程要求这样做，则没有什么可以阻止您这样做。作为自动构建的一部分，您需要自定义构建过程模板以实现此目的。开箱即用的每个构建都会创建一个源标签（可针对多种工作项类型访问），并且假设一切设置正确，您可以从构建服务器上的放置位置提取此构建的副本。

构建服务器将拥有自己的工作区定义，$SourceDir 将映射到顶层目录，在该目录中源代码将从版本控制中提取。 Drop 文件夹是放置最终构建输出的位置。它可以是运行构建的帐户可以访问的任何本地或 UNC 文件共享。

Drop 文件夹与您的或构建服务器的本地工作区文件夹无关，因此即使您将其设置为 drop 文件夹，它也不会被添加到版本控制中。请记住，您的本地工作区只是为服务器上的版本控制结构的物理结构提供了一个抽象级别。简单地将它们在本地一对一映射无论如何都不会导致添加到本地的工件自动添加到服务器。

希望这是有道理的。

【讨论】：

首先感谢您的意见和澄清。这是另一个幼稚的问题。我尝试坚持推荐的任何内容，所以我主要看到人们将构建文件夹置于源代码控制之下。他们是保存构建类型还是构建输出。我尝试保存我的构建类型，但找不到提供路径的方法，它总是在不同的地方出现。
请告诉我们您曾在哪里看到有人将构建文件夹置于源代码控制之下。我从未见过这样做，因为它没有任何意义。
John 这里它已经放在其他地方了，你必须忽略或者这个帖子是多余的stackoverflow.com/...。 hinsh 先生有一系列关于分支和构建的文章。 blog.mrhinsh..。如果侵犯了智慧的空间，那我又不好了。相信我，这对我来说有点晦涩难懂。书籍非常简短，因为它们涵盖了 600 页范围内的很多主题。