TFS Builds – Part 1

Before we get into the nitty gritty of how to set up TFS Builds, a quick reminder of why we want to use TFS Builds.

In agile projects , Definition of Done is defining what done means so you can get to that working software.
The hard way is doing it manually where someone has to go and actually check, verify all the items in your DoD and verify that you’ve met them, and you’re going to do this for each and every Sprint from now until the end of time. Then there is the easy way, which is via automation, and what you’re going to do in this case is you’re going to automate whatever you can automate and minimize all the stuff that has to be done manually.

There are lots of things you can automate in TFS.

An example of a good definition of Done is:

• All Code is written with unit tests first
• Unit Tests have a minimum of 80% code coverage
• Code compiles and unit tests pass when run as part of automated build
• Database Schema objects are checked into TFS
• Database upgrade script is written and stored in TFS
• Code is reviewed by someone other than the coder
• QA Test Plan
• The user story has been fully tested according to the acceptance criteria
• The user story has been deployed and tested in Staging
• Automated integration tests have been written and passed
• There are no severity 1 or 2 bugs
• The user story has been reviewed by the Product Owner
• There is a known deployment & rollback plan
• Deployment plan has been reviewed by Ops
• Database changes have been reviewed by DBAs
• Performance testing has been conducted ( if applicable)
• The user story has been deployed to Production

In my experience, a lot of teams say you should automate deployments and they say that’s nice but they never invest in automation. The usual excuse they use is that they’re too busy, they can’t actually spare the time because we’ve got to hurry up and ship that done, working software. The funny thing is that everyone knows that it’s a good idea and they just say that they don’t have time to do it, which to me seems incredibly short-sighted.

What are the big wins for automated deployments?

1) Integration – this will brings code together, check s that it compiles and version the code
2) Quality – Make sure the code actually works, measure how well it’s been tested and know what’s been tested
3) Deployment – Make sure that you can verify your code, knows what’s been deployed

So why use TFS Build?

• TFS Build will install the build service
• Create the build definition in TFS
• When the build runs, it will :

1) Get Latest
2) Label the code in version control
3) Compile the code
4) Run any unit tests
5) Copy the binaries into a ‘drop’ directory

Thanks for Reading. In Part 2, we will start using TFS Build…