A couple of weeks ago I was doing a road-show where I did demos of TFS 2012 and it’s capabilities. I do a 4 hour demo that shows an end-to-end scenario, showing capabilities such as requirements management and elicitation, work management, developer tools, quality tools, testing tools, automated builds, lab management and reporting all using TFS. I visited 9 different companies, and most of them asked, “Why should we do builds?” This is something I want to address – you need to be doing builds, and you need to understand why they are so key to successful and effective software development. Builds are no longer an optional extra!
Before I dive into doing automated builds using TFS Team Build, there are two general principles that apply to doing automated builds that I’d like to unpack: Consistency and Quality. These principles transcend the choice of build engine – be it TFS Build (or TeamBuild), Hudson, Cruise Control, Jenkins or any other engine.
How do you deploy your code into test (or for that matter, into production)? Most teams start off using the “Publish” menu option from within Visual Studio, either publishing directly to test (or even production) environments, or publishing locally and copying to the target servers. Let me be brutally honest – this is simply immature. This “deploy from Visual Studio” is really something only amateur developers and hobbyists should be using. Why? Because there is so much risk attached to doing things this way.
Some teams argue that they only do this to “test” environments and start getting “serious” only when deploying to production. I argue that you should treat even your test environments as if they were production targets, so that you get the deployment process right there before promoting to production. If you can do it right in pre-production environments, chances are you’ll be able to do it right in production.
Let’s look at some of the risks of “Publish from VS” deployments:
So what does this have to do with automated builds? Automated builds address each of the above risks. Fewer risks translates into better quality and higher productivity.
Quality is something that’s hard to measure. Let’s consider an example. If a user expects the system to save a record to the database when they click the “Save” button, and it works, then quality is high, right? Not necessarily. Perhaps the “Save” operation only works when the information is “clean” – and breaks if the data is invalid (perhaps it should warn the user that there is invalid data?).
Automated builds go some way to providing a measure of quality. How do you know that the code you are publishing from VS is good code? What measures do you have to even assess this? I argue that if you don’t have automated builds (with unit tests – something we’ll again discuss in a later post) then you’ve got no objective measure.
Let’s consider some of the advantages that automated builds bring in terms of quality:
So let’s now ask which process would let you sleep easier the night of your rollout to Production? The one where a developer claims the unit tests are passing with sufficient coverage and does a “Publish” from Visual Studio, or the one where you’ve got an automated build report showing test success and coverage, approval from testers that the build passed manual tests, and a script that’s proven itself over and over for deployment?
I’d like to end with this consideration: the “earlier” in the process you find a bug, the cheaper it is to fix. Consider finding a bug while you’re coding. You fix it then-and-there: cost to company is a couple minutes of your time, so probably a few cents. On the other end of the spectrum, consider cost to company of a bug in Production: in terms of pure development, there’s the time of the person who finds the bug – then the time of the call-centre that they call, sometimes the ops team, 2nd line support, then some developer who spends a few hours trying to reproduce the issue and eventually fix it. Then it has to go through testing etc. etc. – and that’s just in terms of “direct” costs. Bugs in Production could cause other costs such as financial costs for legal errors or even reputational cost for your company.
The bottom line is this: investing some time now to automate builds (and add unit tests) will save you lots of time and money in production and operational issues. It’s a fact.
In the next post, I’ll talk about the Team Build automation engine.
Colin Dembovsky is a senior ALM Consultant for Imaginet based in East London, South Africa. After completing an MSc in Computer Science at Rhodes University, he worked as a developer (first in Linux using C++ and moving to .NET and C#) and later systems architect. He left development work to start ALM consulting, and has been an ALM MVP since 2011. He is passionate about helping teams improve the quality of their software, and do it more efficiently. Besides consulting and training, Colin is a frequent guest speaker and regularly blogs at http://colinsalmcorner.blogspot.com. When he is not working on a TFS server somewhere, he is playing guitar or mandolin and recording in his home studio, or entertaining his wife and 2 kids.