何时应该“释放”我的建筑？ [英] When should I "Release" my builds?

问题描述

我们刚刚开始在我们的一个项目中使用Visual Studio版本管理，我们已经对我们的工作有些问题。

我们创建了一个单一的发布阶段，它负责将构建工件部署到专用虚拟机进行测试。我们打算使用这台机器来运行我们的集成测试。

现在，我们有一个gated checkin构建过程：每个checkin触发所有的单元测试，释放触发器也发生在这个build上。起初，似乎可行的是，在每次签入之后，项目被部署并且集成测试被执行。我们注意到所有发布的版本都在版本管理上污染了控制台，并且所有版本都被标记为无限保留，并且我们的文件夹位置正在快速增长（看到这之后，工具自动执行此操作是有道理的，因为可以将任何构建提升到另一个阶段，并且工件需要持久化）。

问题是：我们做错了什么？我一直在想这个，它真的没有任何意义，释放每一个签到。我们应该可以在sprint结束时开始这个发布过程，这个点可以被认为是发布候选者。

如果我们这样做，我们运行自动化集成测试？我的意思是，需要一个部署过程来运行我们的情况下，如果我们尝试使用其他方法来实现（如LabTemplate构建过程），我们将最终重复部署代码。

这里最好的方法是什么？

解决方案

。在MS发行管理（RM）中，创建发布不一定意味着您将这个代码交付给您的客户，即使它有质量迁出开发。它只意味着你在你的版本路径上放置一个版本的代码。这个版本/版本可以在第一阶段停止，这是确定。

假设您有一个由Dev，QA，Prod组成的发布路径。在一个月的时间内，您最多可以在Dev中发布100次，但在质量检查中只能发布5次，而在Prod中只能发布100次。

- 在部署和集成测试。如果测试需要很长时间，则只需要在（门控或非门控）检入期间（例如，单元测试+部署）执行最小操作，而在释放路径的第二阶段（其应在第一阶段完成后自动触发） ）。没关系，如果第二阶段需要很长时间。作为一个开发，签入，一旦构建成功完成（和第一阶段），期望其余的顺利进行，继续下一个任务。 （注意，只有第一阶段的结果影响您的TFS构建）。

大多数时候，部署和休息将运行良好，因此不会有任何影响到开发。每一次，你将在第一阶段失败，现在开发人员将打断他的新工作，得到一个解决方案asap。

至于每个构建无限期保存，暂时，这是RM的副作用。当前客户需要手动进行清理（或脚本）。在即将发布的版本中，将推出针对版本/版本的新保留策略以改进此功能。这还没有工作，但目的是，例如，指示RM保留所有发布到Prod，只保留最后5，去QA，只保留最后2，去Dev。 / p>

We just started using Visual Studio Release Management for one of our projects, and we're already having some problems with how we are doing things.

For now, we've created a single release stage, which is responsible for deploying our build artifacts to a dedicated virtual machine for testing. We intend to use this machine to run our integration tests later on.

Right now, we have a gated checkin build process: each checkin fires all the unit tests and we configured the release trigger to happen on this build also. At first, it seemed plausible that, after each checkin, the project was deployed and the integration tests were executed. We noticed that all released builds were polluting the console on Release Management, and that all builds were being marked as "Retain Indefinitely" and our drop folder location was growing fast (after seeing that, it makes sense that the tool automatically does this, since one could promote any build to another stage and the artifacts need to be persisted).

The question then is: what are we doing wrong? I've been thinking about this and it really does not make any sense to "release" every checkin. We should probably be starting this release process when a sprint ends, a point that can be considered a "release candidate".

If we do that though, how and when would we run our automated integration tests? I mean, a deployment process is required for running those in our case, and if we try to use other means to achieve that (like the LabTemplate build process) we will end up duplicating deployment code.

What is the best approach here?

解决方案

Don't get tripped up on the 'Release' word. In MS Release Management (RM), creating a Release does not necessarily mean you will have this code delivered to your customers / not even that it has the quality to move out of dev. It only means you are putting a version of the code on your Release Path. This version/release can stop right in the first stage and that is ok.

Let's say you have a Release Path consisting of Dev, QA, Prod. In the course of a month, you may end up releasing 100 times in Dev, but only 5 times in QA and once in Prod.

You should drive to get each check-in deployed and integration tested. If tests takes a long time, only do the minimal during (gated or not) check-in (for example, unit tests + deployment), and the rest in your second stage of Release Path (which should be automatically triggered after first stage completes). It does not matter if second stage takes a long time. As a dev, check-in, once build completes successfully (and first stage), expect the rest to go smoothly and continue on your next task. (Note that only result of the first stage impacts your TFS build).

Most of the time, deployment and rest will run fine and so there won't be any impact to dev. Every now and then, you will have a failure in first stage, now the dev will interrupt his new work and get a resolution asap.

As for the issue that every build is kept indefinitely, for the time being, that is a side effect of RM. Current customers need to do the clean up manually (or script it). In the coming releases, a new retention policy for releases/builds will be put in place to improve this. This has not been worked on yet, but the intention would be to, for example, instruct RM to keep all releases that went to Prod, keep only the last 5 that went to QA and keep only the last 2 that went to Dev.

这篇关于何时应该“释放”我的建筑？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！