There are existing blogs that cover this but I thought I’d finally get around to including architectural validation in a build on one of my projects. I have a solution (it’s actually a custom check-in policy for TFS 2010, I’ll probably blog about it in the near future) that consists of a number of projects:
I’ve added a very simple architecture layer diagram and simply associated the relevant layers with the relevant projects by dragging and dropping the projects from the Solution Explorer, so that the Policy layer = HaikuCheckInPolicy, User Interface = HaikuCheckInPolicyUI and so on. Note that you can be much more sophisticated and use namespaces and/or individual elements if you want:
I also have a build definition (it’s a Gated Check-In, again, I’ll walk through what this is and why I’d use it in a later post). In the build definition parameters, I’ve simply added the following MSBuild argument to the MS Build Arguments parameter in the Advanced node:
Now I run my build (check-in or queue a build) and in my case the code does not comply with the architectural rules defined in the architecture layer diagram – in other words I’ve not complied with the intended architecture. Note that the code compiles and indeed runs fine, this is checking whether the architecture is as intended. if the architecture has been invalidated by my code I then see a failed build and the following build log information:
This is telling me that there is an invalid dependency between the HaikuCheckInPolicy and the HaikuCheckInPolicyUI, according to my architectural rules. I can go back to the code but if I’d like to visualise this then I can open my Architecture Layer diagram and select Generate Dependencies:
After which the real dependencies are drawn onto to the diagram:
So, now I can see clearly that there is a dependency, at the code level, between the Policy and User Interface layers. If I fix this (either in the code or by accepting that this dependency is actually correct), then the next build log will be a happy one (other than the fact that only half of my code is covered by unit tests):
The combination of Gated Check-In and Architectural Validation in the build means that I cannot check-in code that either breaks the build or doesn’t follow whatever architectural guidelines have been defined.