问题
I have a couple of apps, some WinForms published via ClickOnce and some websites that we build using the vNext build scripts and deploy as the last step of those build scripts, if everything builds and unit tests pass. We have two branches for each app, one that will build and deploy to staging area and another to production.
With the new Release management functionality in TFS, I'm assuming I'm to move the Deploy task from the build definition to the Release area. But what does that really buy me except maybe an approval button?
回答1:
Well, it depends 😀...
If you are practicing Continuous Delivery then you have one branch that is deployed directly to production. However many folks want to deploy to a staging environment first, kick the tires there, and then deploy to production.
However, doing this with branching is a mistake. It is a significant anti-pattern that can result in faults in production not detected by staging. Much of this is due to merging, but since compilers are not deterministic what you tested in staging is not the same as what you deploy in production.
You should change your model to have the same build output flow through various stages towards production. The fewer of those stages the better, ideal being one.
In a modern release flow you always "work" on a single branch and then build from that branch. When you have a build that you want to promote you create a release that tracks the progress of that build through the different stages to production with no re-compilation.
来源：https://stackoverflow.com/questions/41363167/tfs-release-management-vs-build-deploy-task-at-the-end