Automating "Done Done“ in the Team Workflows with Microsoft Visual Studio Ultimate and Team Foundation Server 2010Jamie CoolProgram ManagerMicrosoft

FT05

Brian A. RandellSenior ConsultantMCW Technologies

Agenda> What does it really mean to be “Done” > Going from “It Builds” to “Done” in < an

hour> Automated Builds> Gated Checkins> Automated Tests> Test Lab Deployment

An Unfortunately Common Scenario Achieving Done only at the End> Dev writes code> Dev makes sure his component compiles> Dev checks in code> Repeat x15 devs for 4 weeks> Dev lead does a build of all components> App is installed in test environment> Test tries to test it> App doesn’t work> Dev blames test

Working in Cycles> Different cycles have their own “Done”> “Done” earlier is better than “Done” later

Check In

Daily Build Testable

Story

Iteration

Product

The Tradeoffs> Deferring “Done” has costs

> Low build quality during development> Finding issues late> Not knowing how much you really have left

> Achieving “Done” ASAP has costs> Manual verification is expensive & error prone> Automated verification requires huge

investments – often hard to win support for

> Deferring “Done” is often the default choice

The “Done” Sweet Spotwith VS Ultimate & TFS 2010

> Automate “Done”> Provides the infrastructure for you > Focus on what’s unique for your

app> Adopt one step at a time

> Enforce “Done” for each cycle> Check-in Policy> Gated Check-in> Continuous Integrations

> Know when you’re “Done”> Test reports > Project data reports

Source Control

Builds

Validate Layering

DeployBuild

Execute Tests

Work Items

TFS

Our Scenario…> What we have…

> An app> The App project builds in VS> A fully configured VS Ultimate & TFS 2010 environment

> What we don’t have… > Any things else (builds, tests, setup packages)

> What we are going to achieve in < an hour...> Automated builds> Validated Checkins> Automated unit & acceptance tests> Automated deployment & acceptance test verification> Reporting of “Done” metrics

Step 1: Automated Build> Automated builds are the pillar of “Done”

> No engineering improvement gives more back> You build it all at the end, so why not build it all

early

> VS & TFS makes automated builds simple> Automated builds don’t have to be scary &

complicated> Any project that builds in VS can have an

automated build in seconds

> Fully extensible > Integrated Windows Workflow engine> From a single build machine to a build lab

executing a build across many machines

Automated Build

demo

Step 2: Continuous Integration (CI)No more build breaks with Gated Checkin> CI let’s you continually check for regressions

> Constantly run builds & assess your “Done” level> Identify problems soon after they are introduced

> VS & TFS has built in support for CI> No special work required> You just need the build machine cycles

> Gated Checkin guarantees no more build breaks> TFS runs a build before each check-in

(synchronous CI)> Never hear “It worked on my machine” again> Guarantees no code ever gets in that doesn’t

meet at least some “Done” criteria

Gated Checkin

demo

Step 3: Automated Testing> Automated tests lets you stay “Done”

> Don’t just get “Done”; stay “Done”> Generally the more you can automate the better> Cost of automation often means it doesn’t

happen> VS lowers the barrier & cost to test

automation> From unit tests to automated UI tests> Test support was a key VS 2010 investment

> Integrate tests & build> Ensure your tests pass as early as possible> Get test status with every build

Automated Testing

demo

Step 4: Test Lab Deployment> Being able to run the app is key to being

“Done”> It’s hard to know if you’re done if you can’t use

the app> Going from build to deployed app is often a

barrier> Doing it for every build is a major barrier

> 2010 includes virtualized lab management> Automatically spin up / tear down of lab

environments> Manage machines as a group> Network isolation

> Integrate builds and lab deployment> Automatically deploy builds & run tests> The app is then available for any kind of further

testing

Traditional Workflow

Compile Code

Reimage Machines

Deploy App

Run Tests

Automated WorkflowCompile

Code

Restore Environ-

ment

Deploy App

Take Snapshot

Run Tests

Test Lab Deployment

demo

Knowing your “Done”

demo

Summary> “Done” in less than an hour!> Adopt one step at a time

> You don’t need to do all of this at once> You’ll see immediate payback from each step

> Learn more> Try out Beta 2!> http://www.microsoft.com/visualstudio/

Automated Build

Gated Checkin

Dashboards & Reporting

Lab Management

Automated Testing

YOUR FEEDBACK IS IMPORTANT TO US! Please fill out session evaluation

forms online atMicrosoftPDC.com

Learn More On Channel 9> Expand your PDC experience through

Channel 9

> Explore videos, hands-on labs, sample code and demos through the new Channel 9 training courses

channel9.msdn.com/learnBuilt by Developers for Developers….

© 2009 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Backup

When is Software Done?When…> the code is written (code complete)?> the code builds?> unit tests pass?> acceptance tests pass?> all of the code in the bugs are fixed?> the customer says it’s done?

A Desirable Development ModelAchieving Done Early & Maintaining it> Dev writes code & unit tests> Dev is only able to check in if his code builds

& core tests pass> Regular automated builds happen for the

entire product> Build is automatically deployed to test

environment> Acceptance tests validate product quality

e2e

Step 5: Knowing your “Done”> Know your “Done” state at any given

time> State of your builds> Test results> What user stories are complete> How many bugs remain