Monday, 1 September 2014

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.

DDD or not to DDD? That may or may not be the question.


I've had/am involved with my first commercial experience of DDD, or at the very least, something heading that way. My team are developing their first DDD software component.  I didn't realise I was at least 10 years behind the leading edge ( the year  which Eric Evans seminal work DDD was published was the same year I started my career as an embedded software developer, which is as close to enterprise development as Pluto is to the Sun)   

DDD Quickly

After being in a few larger organizations and having dealt with a fair few types of design approaches (ranging from monolithic to typical n-tier), it seems  that DDD has finally achieved mainstream adoption in the industry and the shit kickers - I include myself here -  are just about ready to consume it, and murder it potentially :) 

I have read "DDD quickly" on InfoQ, which I would highly recommend to get a flavour for DDD in general, and have recently started reading  "Implementing DDD" by Vaughn Vernon (or Vince Vaughan - as I keep saying) .  I chose this over Eric Evans' book as it is more current and seems to have lots of practical examples. The book is well written and has so far (3 chapters in) kept me  engaged and interested. Pretty good going for quite a dry subject like DDD. 
My first impressions of the subject are that its complex,  nuanced and subjective.  When things aren't black and white and there are lots of possible ways to skin a cat,   extra attention and leaps of faith are required.  Also because of this there are lots of terms to learn and use which in turn refer to almost every other aspect of important literature in the field of enterprise 
development (P of EAA, GoF, DDD) .  I will never be able to grok it, I have too many distractions, like life.  However, I will try and learn it enough to practice it and contribute to discussion about it. 

DDD Lite

For our team's problem at hand it appears, on the surface,  we have had some of the hard work done for us and have a  bounded context with a ubiquitous language that we can play around with. Additionally  the bounded context is conveniently mapped 1-1 to a sub-domain (good practice according to Vaughn).

The lack of any analysis about what the bounded context and sub-domain are here, by our team, and also our use of just a few tactical patterns (aggregate/entity identification and the use of a repository) owe to the "DDD lite" subheading, which Vaughn says is symptomatic of a lack of strategic patterns being employed.  

That is to say our team is taking a technical approach to DDD and is not fully involved in bounded context or ubiquitous language identification at this point. (or other strategic practices). This is fortunate and unfortunate.  Fortunate that we can kick on and use tactical patterns but unfortunate in that we can't apply the strategic patterns which we will have to apply at a future point in time and thereby miss out on crucial learning in this area.

The software component was initially going to be developed  using an anaemic domain model/data model and transaction script. However, our architect saw it as a candidate for DDD, with the idea that it will prepare us for future DDD projects.

I don't believe there was anything particularly wrong with the familiar and fairly straight-forward approach (anaemic/transaction script), we were going to use, and going on some of Vince's guidelines (or Greg young agile-esque T-shirt size - Small Small estimation), the component wouldn't necessarily be a priority for DDD love, as it is not in a core domain or a particularly complex sub-domain, but I have to agree with my architect, it does seem that it is useful as a stepping stone as our team gear up for more DDD development.  

The bounded context is a little lacking though, there are no invariants,  and consistency is a fairly straightforward affair.   There is no usage of domain events, either, for example.  However, the structure of the component means it aligns to a ports and adapters type architecture, where we can plug in back ends and front ends in with ease  (for example we plug in a resilient/distributed messaging framework  to communicate with other bounded contexts).

Back to OO

Martin Fowler describes the anaemic model in less than favourable terms.  I have seen it used in my enterprise and elsewhere.  I now know where I have seen it correctly used, in simple RESTful CRUD components for example, and "wrongly" used if what you end up doing is  pulling behavior into a myriad of "domain?" services  -  which is arguably an easier way to get to work done on some data - and transposing/pivoting behavior out of  domain objects and splaying/fanning  it into "services", relying on DI to pull everything together. If your constructor has 15 dependencies maybe something is a bit smelly.

So with DDD what happens regarding anaemia?. We feed the domain model up by falling back on encapsulation, a fundamental tenet of OO, where state and behaviour - on that state - are packaged together, heping form what is known as a rich domain model. 

We are told it is a big problem that this kind of stuff has been abandoned for the skinny latte way of design, but I do wonder how bad it actually is.   

The Dilemma

So now we are developing using DDD (or "DDD lite") and this goes back to the question in this post's title.  Should we or shouldn't we? It seems that this decision shouldn't just be based on technical considerations or that the decision should just be outright rejection because of hearsay about complexity, over engineering or the absence of a highly-skilled hero team.  Vaughn states that DDD is a complex process but out of it can drop a clear and simple manifestation of a solution to a set of  business problems. 

There are a series of questions that should be asked before embarking down the DDD route which people like Greg Young and Vaughn Vernon both advocate asking.  One of those shared by them goes something like: "By embarking on DDD for your software, is this adding value to the competitive advantage of the business the software is being developed for?".  

In this instance we are adding value to the competitive advantage of the business - even if it is marginal.  We are also providing ourselves with a firmer footing for DDD work in the future, which will see further value added.  So maybe that's OK even if we are just doing "DDD Lite" for now.  

If adopting only some of the tactical patterns give us marginal improvements this is  still worthwhile and not hurting the business, and if an opportunity like this on a project you are working on presents itself - to get a leg up  with DDD without going the whole hog - then it should be considered.