Our team have been involved in a fair bit of release activity, as of late. We are gearing up for our wagile (our previous CTO's term not mine) project's big bang release to production.
Due to the release pipeline we have been forced to release our changes with another team.
The code resides in 2 different branches, both of which are branched off of a main branch. However, in TFS terms, these are unrelated until at least one merge has taken place (a baseless merge).
Quite simply we have the following arrangement:
b (us) c (them)
It was decided that we should merge our changes in (b) into their changes in (c) and then use the build resulting from the merge to push out to an integration environment, where our testers would run any remaining manual tests (or kick off any semi automated service/integration tests)
Forgetting the fact this would actually be a baseless merge in the first instance, actually performing the merge and getting it out, would mean that we would either have to push out locally from where the merge was performed and not check-in, or - if we were prepared to rollback if anything was to fail - check in.
We took the latter option in the and it was a bit painful, as there were failures and we had to rollback.
To save this pain we took advantage of the fact that builds can be pushed out from shelvesets as well as normal changesets and latest sources.
Bearing in mind a merge still has to be performed , the merge can be checked-in, as a shelveset, and then this shelveset can be referred to in the options on the build definition like so:
Simply choose "latest sources with shelveset", in the drop down, and then the relevant shelveset and voila you have branch (c) + branch (b), without any of the baggage of a changeset (I'm sure internally shelvesets are stored in a similar manner but are surfaced differently.)
Hopefully this, "soft merging" saves someone a bit of pain and allows integration testing before fully merging 2 branches.