我们刚刚开始在我们的某个项目中使用Visual Studio Release Management，而且我们已经在处理我们的工作方式方面遇到了一些问题。
目前，我们已经创建了一个发布阶段，负责将构建工件部署到专用虚拟机进行测试。我们打算稍后使用这台机器运行我们的集成测试。
现在，我们有一个门控签入构建过程：每个签入都会触发所有单元测试，我们也在此构建中配置了释放触发器。起初，似乎有理由认为，在每次签入之后，项目已经部署并且集成测试已经执行。我们注意到所有发布的版本都在Release Management上污染了控制台，并且所有版本都被标记为“无限期保留”，并且我们的drop文件夹位置正在快速增长（看到之后，该工具会自动执行此操作，因为一个人可以将任何构建推广到另一个阶段，并且需要保留工件。）
那么问题是：我们做错了什么？我一直在考虑这个问题，“释放”每一次检查都没有任何意义。当sprint结束时，我们应该开始这个发布过程，这个点可以被认为是“候选发布者”。
如果我们这样做，我们将如何以及何时运行自动化集成测试？我的意思是，在我们的情况下运行那些需要一个部署过程，如果我们尝试使用其他方法来实现它（比如LabTemplate构建过程），我们将最终复制部署代码。
这里最好的方法是什么？
答案 0 :(得分：2)
如果没有进入你的组织内部并且看着你是如何做事的话，很难说，但我会采取刺。
首先，我通常会避免使用gated checkin构建，除非破坏版本经常出现问题。如果破碎的构建不是一个痛点，不要使用门控签入。为什么？简单：如果您的构建/测试过程需要10分钟才能运行，那么我必须等待10分钟，以便知道我是否可以继续工作，或者我是否会将我的更改推回原处我。它不鼓励小型，频繁的签到，并鼓励巨大的无环境签到。
还有10分钟，开发者B必须等待抓住开发者A的最新变化。如果开发人员B需要该签入以继续工作，那就浪费了时间。相信您的CI流程可以捕获破坏的构建，并且您的开发人员可以在极少数情况下承担责任并进行修复。
更合适（取决于您的分支策略）对您的主干进行门控签名，然后针对您的开发/功能分支构建CI。当然，这会打开整个＆＃34;当我有多个分支时，如何构建一次/部署多个？＆＃34;可以蠕虫。 ：）
如果您的集成测试速度很慢并且需要部署才能成功，那么他们可能不适合作为CI的一部分运行。有一个CI / gated checkin构建只有：
然后，进行第二次构建（计划或滚动），实际部署并运行整个测试套件。你可以根据自己的喜好安排它 - 我通常在中午（或者＃34;午餐休息时间和＃34;团队之间的任何通行证）和一个午夜时分。通过这种方式，您可以从早上的工作中获得经过测试的构建，并从下午的工作中获得一个。
使用发布默认模板，您可以将预定的构建定位到您的＆＃34; dev＆＃34; （/ test / integration /无论你怎么称呼）阶段。当您准备好实际发布版本时，您可以使用针对生产的特定版本启动新版本，并使其正常完成所有阶段。
答案 1 :(得分：2)
不要惹恼'释放'一词。在MS Release Management（RM）中，创建发布并不一定意味着您将此代码交付给您的客户/甚至不具备移出开发人员的质量。它只表示您将一个版本的代码放在Release Path上。这个版本/版本可以在第一阶段停止，这没关系。
假设您有一个由Dev，QA，Prod组成的发布路径。在一个月的过程中，你最终可能会在Dev中释放100次，但在QA中只发布5次，在Prod中发布一次。
您应该开车，以便部署每个签入和集成测试。如果测试需要很长时间，只需要在（门控或非门控）签入期间进行最小化（例如，单元测试+部署），其余部分在释放路径的第二阶段（应在第一阶段完成后自动触发） ）。如果第二阶段需要很长时间并不重要。作为开发人员，签到，一旦构建成功完成（和第一阶段），期望其余的顺利进行并继续您的下一个任务。 （请注意，只有第一阶段的结果会影响您的TFS构建。）
大多数情况下，部署和休息都会正常运行，因此不会对dev产生任何影响。时不时地，你会在第一阶段失败，现在开发人员会打断他的新工作并尽快得到解决方案。
至于每个版本都无限期保留的问题，暂时，这是RM的副作用。当前客户需要手动清理（或编写脚本）。在即将发布的版本中，将实施新的发布/构建保留策略以改进这一点。目前尚未开展此项工作，但其意图是，例如，指示RM保留所有发布到Prod的版本，仅保留最后5个转到QA并保留最后2个转发给Dev。 / p>
答案 2 :(得分：1)
这不是一个简单的问题，因此必须明确答案。
首先，您永远不会保留所有的构建版本;建筑越老，对任何人都越不感兴趣;在生产中没有部署的构建被达到该阶段的构建所取代。
团队必须就使构建有趣的标准以及保留多长时间达成一致。为生产或客户定义的构建策略：您支持多长时间？直到下一个版本，直到下一个版本，为期五年？潜在的可交付构建，仍然不在您的客户和＃39;手，被更新的取代，所以你可以使用数字或时间标准（TFS只实现第一个，因为第二个更容易出错）。通常，当您需要安全网选项并且能够从提供的池中选择（具有更易管理的错误的池）时，您可以拥有多个可交付的构建。
TFS＆＃34;无限期保留＆＃34;如果无法自动执行先前的条件，则应使用此方法，因此切换到手动实施的策略。无限期不是永远的，意味着未知的时间间隔。