TFS and integration test builds from Shelvesets.

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:

a (main)
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.

Comments

Post a Comment

Popular posts from this blog

Book Review: Test Driven Development By Example (Kent Beck)

GitHub I have coded the examples and both are available in GitHub.   Money  and xUnit  Delayed... I am recalling this after a few weeks finishing the book (I should've done this immediately so my memory is hazy, but the code examples should attest to the fact I have read it, if my descriptions of the text are a little ambiguous)  I have read this book on a number of occasions previously, in reference form and once all the way through,  but hadn't worked through the examples in  a code editor.  I think, for real value, you have to  code the examples, after a while it does feel like you are actually pairing, like others who have reviewed this though, I think the humour leaves a bit to be desired but its not too distracting! I have been TDDing for a while but this was a good refresher and reminded me of the maxims and techniques "fake it till you make it",  "obvious implementation" and "triangulation". There are also some nice "red" and &quo
Read more

SSDT March 2014 Static Code Analysis Extensibility

Static Code Paralysis. Coding standards (and more latterly styles) in any organisation of any size are liable to incite religious wars and makes zealots out of even the most considered or apathetic of us.   Inconsistency and subjectivity,  lack of enforcement and heavy handedness all contribute to the contempt often leveled at them.   Sod it. I say sod all that, if you or your company aren't using static analysis tools  then you are missing out on improved code quality and productivity (borne out from a consistent approach) and reducing the most banal and mind numbing conversations and sometimes pissing contests associated with discussing the minutiae of standards.   As an aside, having a few years under my belt  in the industry  I've found that people who "really" moan most about this are usually rabble-rousing morale sappers who like to moan about everything, so it stops them doing this and maybe might lead to them getting on with work instead! Makes thin
Read more

MongoDB

Mongolicious MongoDB training, provided by MongoDB themselves, was up for grabs recently, so I put my name in the hat to get a keener insight into MongoDB and NoSQL databases, having used them only a few occasions. The training was attended by a near 50/50 split of devs and DBAs and this led to some interesting debates and reactions.   Like lots of the stuff I've been introduced to/have started looking at recently (I am late to nearly every technology party there is) they (Mongo and NoSQL) have been around for a while and have become established as a viable alternative persistence solution to the likes of MSSQL.  The main features: Its schema less Document oriented/No support for JOINs  Querying performed using JS/JSON Indexing Replication/Redundancy/High availability Scaling out via Sharding  Aggregation (unfortunately we ran out of time so this is not covered here) Authorisation (again ran out of time on this one)  Its schema less You'l
Read more