DEV303 - Visual Studio Team System: Enterprise-Class Source Control and Work Item Tracking

DEV303 - Visual Studio 2005 Team System: Enterprise-Class Source Control and Work Item Tracking

Presented by Brian Harry

Demo is busted. :(

Related Blogs: Brian Hary's Blog | Korby Parnell's Blog | Buck Hodges's Blog [UPDATED - added the links to the blogs]
Visual Studio 2005 Team System: Enterprise-Class Source Code Control and Work Item Tracking white paper
Demo Video on MSDN (covers same material Brian's demo was going to show)

Visual Studio Team System (VSTS) Overview

Overview of VSTS design goals

Reduces complexity
- applications are more complex
- team dynamics are more complex (e.g., geographic distribution)

Facilitates communication
- eliminate status meetings; automatically collect and report status information
- the ability of team to communicate is essential to project success

Enable partners
- creating a great ecosystem to extend VSTS
- enable you to customize

Microsoft has always focused on the developer to make the developer successful.
We've largely ignored the other roles.
There are a lot of different roles that are needed to make complex application projects successful.

Goal of Team Foundation is to enable communication across all of the roles (architects, developers, testers and project managers)
Key pieces of Team Foundation:
- change management
- work item
- tracking
- project site
- project management
- integration services
- build process

The new source control is totally different code base than VSS; server-based product; uses SQL Server & Windows Server 2003
VSS is appropriate for lightweight use and will continue to exist (Visual SourceSafe Roadmap)

There are a lot of work products (artifacts) to manage
- lists (bugs, requirements, work items, etc.)
- process guidance
- releases (every build, not just the final release - the end result)
- management questions (what's the status? what's the quality?)
- source code assets (any document you want to track - specs, code, test cases, etc.)
- team communication (all of the above must be communicated within and outside the team)

Team Foundation is:
+ Work Item Tracking
+ Build Automation
+ Project Site
+ Source Code Control
+ Reporting

Guiding Principles
- productive
- integrated
- extensible
- capable

Work Item Tracking
- also called defect tracking, bug tracking, issue tracking, etc.
- it's not just about bugs; it's about all of the work that you do
- work items have a life cycle of their own; the foundation of software process
- several types of work items ship with VSTS; you can also create your own
- it's the glue that holds all of the pieces together
- work items represent the goal - the work you want to get done
- integrates with the tools you already use (Visual Studio, Microsoft Excel and Microsoft Project)
- work items will show-up directly in Visual Studio and in tools that other roles use
- two-way synchronization; changes to work items update plan, changes to plan update work items
- every organization tracks information differently; you can customize
- each work item type consists of fields, forms, rules and states (work item life cycle)
- build on standard methodologies; VSTS will ship with two "flavors" of MSF (agile and formal); use as-is or customize
- can create, purchase or customize methodologies to suit your team (there's a lot you can customize)
- methodologies manage the software development life-cycle process
- MSF is based on Microsoft's internal development process

Visual Studio 2005 Team System: Microsoft Solutions Framework white paper

Source Control
- complete version control feature set
- innovative new SCC features: integrated check-in and parallel development
- strong integration with other VSTS tools (link work items to source code, fixed bugs, etc.)

integrated check-in
- combines changes, comments, work items, check-in policy and e-mail notification
- captures valuable data relationships (test cases, work items, etc.)
- customizable for your process
- one window in VSTS to manage all of the above
- check-in policies ensure check-ins follow certain rules
- shipping 3 check-in policies: assoc work item with a check-in, static analysis policy and unit test mandate
- eventing system when check-ins occur; you can create your own custom handler, we ship an e-mail handler for notification mail

parallel development
- branching/merging
-- enable stuff like promotion models: Dev -> QA -> production
-- enable merging code between branches
- workspaces
-- developer isolation; create a "sandbox" to work without impacting others
- shelving (taking all your changes and setting them aside for later retrieval without check-in that might break build)
-- interrupted work flow
-- transfer changes without check-in
-- checkpoint or share work in progress
-- transfer work in progress between machines (PC at work to laptop or to PC at home; dev in Seattle to dev in Raleigh)

Build Automation
Out-of-the-box daily build
- Good build process hard to achieve (many shops don't bother)
- Goal: make it trivial
-- reproducible builds (easy to re-create a particular build
-- VS projects built directly (dev can use same build script or subset to build)
-- scheduled builds and on-demand builds
-- centrally published build report
- Goal: tight integration with VSTS tools

Build Automation Steps
Phase 1
- build initiated from the server
- create a build ID
- document build environment (to make build reproducible)
- sync sources and tools
Phase 2
- compile and code analysis
- execute tests (Build Verification Tests)
- update work items (ensure testers test the right build to verify fixes)
Phase 3
- calculate code coverage (test effectiveness
- calculate code churn
- produce build report
- publish build

Project Site
-facilitates team communication
-- specs, discussions, announcements, lists
-- work items, reports, public builds
- lightweight access for stakeholders without rich client (Team Foundation Client)
- build on Windows SharePoint Services

Reporting
- provides system-wide data view using data warehouse
- ships with many beneficial reports
- partner tools and your tools can contribute data
-- 50 reports in the box
-- can customize and add
- built on SQL Server Reporting Services

% code churn vs % test pass vs active bugs

Remote Development
- Remote development is a reality
-- distributed teams, at-home, offshoring
- A system built for the Internet
--Web service protocols
-- Browser-based clients
-- compatible with proxies and firewalls
-- optimized for high-latency, low bandwidth networks
-- # of round trips and data sent and received are minimized

Part of the VSTS team is based in North Carolina [and Alaska - Hi, Eric!]

Extensibility
- end-user extensibility
-- work item types
-- check-in notes and policies
- third-party extensibility
-- tool integration platform - eventing, linking, and security services
-- using same platform as MSFT tools in VSTS; everyone first-class citizen
-- managed object model
-- Web service API
-Visual Studio will still support MSCCI

Some post talk Q & A:

Expect Team Foundation Server to support at least 500 users in v1.
Can't currently aggregate metrics across Team Foundation Servers.
Can aggregate metrics across a Team Foundation Server.
Can migrate from VSS to Team Foundation.
Licensing and pricing TBD
Pre-release (beta) version of client and server pieces together later this year.
MSCCI is built on top of some private interfaces; if MSCCI too constraining, can go to the lower level now.