Building the Avanade Software Lifecycle Platform using Visual Studio 2005 Team System

Integrating technological and delivery management aspects of software development using Visual Studio Team System

Visual Studio 2005 Team System is an extensible lifecycle tools platform that helps software teams collaborate to reduce the complexity of delivering solutions. The purpose of this paper is to describe how Avanade is building a value-added software lifecycle platform using Visual Studio Team System. The intended audience for this paper is software developers and project managers.

Introduction

Why build a Software Development Lifecycle solution based on Visual Studio Team System?

Avanade has over 2500 solution developers worldwide focused on the .NET platform that work with customers to integrate Microsoft technologies in heterogeneous enterprise IT environments. As we execute large and complex projects, building mission-critical applications with geographically distributed teams, we have little room for error - the success of the project depends on how accurately we can estimate and deliver on the engagement. To this end, we are constantly looking for ways to improve consistency and repeatability of our development process and thus increase the productivity of our project teams. In other words, our project execution must be industrialized. Industrialization is about being predictable, repeatable, consistent, and high-quality.

The goals for the Avanade Software Lifecycle Platform (SLP) can be summarized as follows:

• Provide an easy to provision consistent development environment that facilitates execution of projects across a geographically distributed team.
• Integrate the development methodology into the development environment.
• Integrate project management tools with the development environment.
• Customize the development environment and enact Avanade prescriptive guidance in the development toolset.

Visual Studio Team System (VSTS) offers a rich environment for project execution that can be customized to meet the goals outlined above. VSTS provides integrated version control, reporting, work item tracking, process guidance, and automated build capabilities. Our approach is to use VSTS as the foundation upon which to build the Avande software development lifecycle asset.

Figure 1 - An overview of the Avanade Software Lifecycle Platform.

The following sections describe how Avanade is building upon VSTS to realize the SLP goals.

SLP Business Goal

The business goal for SLP is to provide a consistent team development environment that when coupled with the Avanade development methodology and project management tools such as Microsoft Project Server industrializes project execution.

Industrialization is about being predictable, repeatable, consistent, and high-quality. Success based on heroic efforts is not sustainable, nor is it scalable.

Development Environment

For the Avanade SLP, the development environment must have the following characteristics:

• It must be consistent across the team and must be easy to provision
• It must support distributed team development

Provisioning a consistent development environment

Provisioning a development environment is and has always been a very lengthy process. Every project goes through it and in most cases this is a manual step. It requires a lot of attention from both Solution Developers and Systems Engineers. The latest service packs need to be installed, development IDE and tool tweaks have to be present. In most cases, one wants a development environment that is very similar to the production environment to eliminate technical issues arising from inconsistent environments.

Some leading edge projects have recently adopted a Virtualized Development Environment – i.e. an environment that is hosted on the developer’s machine. A base development image can be created and distributed amongst the developers. This means that all developers start off with a same development environment – no more service pack differences that might lead to phantom operating system related bugs. But having a base development image alone does not solve all problems faced in today’s hugely complex environments. First of all, copying multi-gigabyte images around on the network is not practical. Second, developers can still change their image as the project progresses. Third, Visual Studio Team System involves the creation of very complex development setups – i.e. at least 3 images are required for a developer to work in a distributed Team System enabled environment. It is therefore necessary to be able to provision these complex images in a dynamic manner.

The Avanade Automated Build Framework (ABF) allows the creation of such scripts – ranging from a simple Visual Studio.NET 2003 single development setup to a Visual Studio Team System multi-server development setup. The scripts allow the unattended installation of the host operating system, the development IDE and much more (e.g. development tools, MSDN help, ACA®.NET & Microsoft Enterprise Library foundations etc.). Building these images on a daily basis (during the night for example) on each development workstation enhances consistency and makes sure all workstations are up-to-date with service releases and planned tool updates.

ABF has been successfully used on several projects. ABF scripts have also been created to aid the installation of the VSTS server stack. To extend its commitment to automation Avanade is also developing a new tool called the ACA® Dynamic Systems Framework, which includes a new approach to storing and deploying Avanade’s Assets that promotes the reuse of existing solutions. At its core, ACA® DSF will encapsulate Avanade’s intellectual property regarding the design, configuration, implementation, testing, and operations of all of Avanade’s Solutions; examples include Microsoft Exchange, Microsoft® Active Directory® or even VSTS. ACA® DSF will also be aligned with Microsoft's Dynamic Systems Initiative - specifically around the development of Microsoft's deployment and operations technologies, to ensure that our efforts are aligned and properly leverage Microsoft's investments.

Supporting distributed team development

Several Avanade project teams span multiple geographical locations as well as organizational boundaries. Therefore, enabling distributed development is a key requirement for the Avande SLP. SLP will leverage the source code control system in VSTS since it is designed to support distributed team development. The source code control system in VSTS supports web-based protocols (http and https). Team Foundation Server (TFS) includes a caching proxy that caches file content on the remote location, thereby providing a much better user experience to the remote development team. Further, the source control is optimized for high-latency and low-bandwidth scenarios. Often times the teams on either side of the geographical boundary are on different corporate domains. The RTM version of TFS is expected to support the scenario where the source control proxy and the source code control server reside on different Windows domains.

Development Methodology Integration

VSTS enables integration of an organization’s methodology and standard processes through the use of Process Templates that provision the methodology within the Visual Studio IDE. VSTS comes with two process templates out of the box, namely the MSF for Agile Software Development and MSF for CMMI® Process Improvement. We are leveraging the extensibility model of VSTS to create a VSTS process template to host Avanade Connected Methods™ (ACM) for .NET, which is Avanade’s methodology for executing .NET Projects.

The ACM for .NET process template for Visual Studio will include support for the following ACM phases:

• Envisioning
• Planning
• Executing
• Stabilizing
• Deployment

The ACM process template for VSTS targets the following components:

Process Guidance

The process guidance describes the methodology in detail. It includes an overview, a definition of roles, work item types, and work streams and activities.

Security Groups and Permissions

TFS provides role-based security. We will define security groups and permission for each of the different roles i.e. Architect, Solution Developer, Systems Engineer, Tester, and Project Manager.

Source Control Settings and Permissions

The process template also defines which check-in notes are used for a new team project, and if the new team project uses exclusive check-out. Also, the process template defines default permissions for source control.

Work Item Types

A work-item type is a database record which Visual Studio Team Foundation uses to track the assignment and state of work. We will define a set of work item types that are applicable to ACM. Some examples of work item types in ACM might be Requirement, Issue, and Defect.

Default Work Items

A process template creates default work items when a new team project is created. For example, a process template can create a default set of task work items that must be completed by team members to begin the team project. We will define the complete list of initial tasks as prescribed by ACM and create them a team project is created with the ACM process template.

Work Item Queries

We will define the default set of public work item queries for a team project

Reports

We will define the default set of reports to be used by team members on the new team project

Deliverables

When a new team project is created using the ACM process template, a set of document templates for the work-products identified by ACM as deliverables will be created in the document repository for the project.

Areas and Iterations

A process template defines Areas to capture the partition of features on the project. Iterations determine how many times the team will repeat a particular set of major activities (such as plan, develop, test). ACM does not partition the project in this manner. Instead, in ACM, activities are grouped by the project phase. We will map Areas and Iterations to the corresponding elements in ACM.

Click to enlarge

Figure 2 - Screenshots of the ACM process template in the Visual Studio IDE.

Customizations to the Team Project Portal

The process template also provisions the Windows Sharepoint Services (WSS) Team Project site. The ACM for .NET process template will provision the Team Site with ACM specific content.

The ACM Process Template started off as a proof-of- concept (PoC) done in collaboration with a Microsoft partner that involved a few ACM methods being implemented in the process template to prove that this can be done. SLP will leverage the work done for the PoC and complete the port of ACM for .NET to VSTS.

Project Management Integration

Visual Studio Team System provides the following features for project management:

• A work item database.
• The ability to link code check-ins, defects, and builds to work items.
• Exit criteria for tasks that must be completed before exiting an activity or milestone.
• Support for a methodology via a process template as described in the preceding section.
• Tracking metrics based on the data collected in the work item database.
• Out of the box reports for code quality, schedule progress, stability, and test effectiveness.
• Integration with MS Project and MS Excel.

While Visual Studio Team System does not provide an Enterprise Project Management (EPM) solution out of the box, it provides a platform on top of which an EPM solution can be built. There is a wealth of metrics that can be captured in the Team Foundation Server (TFS) data warehouse, especially during the execution phase of the project. The goal for SLP is to capture these metrics, flow them to EPM tools, and provide a consolidated view of the data in order to enable project stakeholders to track the status of one or multiple projects. In order to effectively manage and track large projects, the use of an EPM solution such as Microsoft Project Server is a necessity.

Based on code provided to Avanade by Microsoft as the starting point, SLP will include a connector to integrate VSTS with Project Server that provides the following features:

• Close to real time synchronization between:

• Enterprise Resources and VSTS user groups
• Enterprise Projects and VS Team Projects
• Assignments and VSTS Work Items

• Consolidated Reporting
• Open Architecture that should work with other development methodologies and EPM tools
• Supports linking multiple VSTS Servers to a single Microsoft Project Server instance

Click to enlarge

Figure 3 - The connector architecture for integrating VSTS with MS Project Server.

In this architecture, Team Foundation Server (TFS) is the primary data source for recording project metrics. The development team will record hours against work-items from within the VS.NET IDE. With a simple mapping between VSTS work item and Project Server fields; we expect to be able to capture actuals on a project with high accuracy. Since this data is synchronized with Project Server, it makes it possible to utilize Project Server to manage the project rather than doing it in VSTS. This allows Project Managers to work in Project Server and the Team Project Portal rather than forcing them to work within the Visual Studio IDE.

Customizing VSTS and incorporating Avanade Prescriptive Guidance

The Visual Studio (Team System Extensibility) SDK provides documentation and samples needed to extend:

• WorkItemTracking system
• Source Control system
• Team Build system
• Test Tool system
• Warehouse and Reporting system

Based on input from the field and Avanade’s customers, SLP targets the following enhancements:

• Continuous Integration: When a developer checks-in source code, a notification mechanism will trigger a build.
• Custom Check-in policies: When a developer checks-in source code, we can validate that the check-in meets the pre-conditions for code check-ins and policies set forth by the project team have been adhered to.
• Daily Automated build cycle (platform integration): Allow for complete rebuild of (VM) the development machines and initiate a build of the current workspace (e.g. every night at 2 am). This enhancement uses the bits developed in the ACA DSF based VSTS deployment kit as described earlier.

Continuous Integration

The fundamental benefit of Continuous Integration (CI) is that it removes sessions where developers spend time hunting bugs where one developer's work has stepped on someone else's work without either developers realizing what happened. These bugs are hard to find because the problem is not in one developer's area, it is in the interaction between two pieces of work (code). This problem is exacerbated by time. Often integration bugs can be inserted weeks or months before they first manifest themselves.

With Continuous Integration the vast majority of such bugs manifest themselves the same day they were introduced. Furthermore it's immediately obvious where at least half of the interaction lies. This greatly reduces the scope of the search for the bug. The net result of all this is increased productivity by reducing the time spent chasing down integration bugs.

There's a fundamental counter-intuitive effect at the center of Continuous Integration. It is that it is better to integrate often than to integrate rarely. If you integrate only occasionally, such as less than daily, then integration is a painful exercise, one that takes a lot of time and energy.

A key for this is automation. Most of the integration can, and should, be done automatically. Getting the sources, compiling, linking, and significant testing can all be done automatically. At end you should be left with a simple indication of whether the build worked: yes or no.

Custom check-in policies

Check-in policies in Team Foundation version control provide an extensible mechanism for validating changes to files prior to submission to the repository. Team Foundation version control implements this feature with the check-in policy framework, a programmatic interface exposed by the Team Foundation version control client that allows us to provide our own validation rules for a check-in.

The check-in policy feature is designed around two particular interactions: policy definition and policy evaluation, both which are extensible.

• Policy definition: the process by which a manager or technical lead defines requirements developers must satisfy prior to check in. Users define policy through a configuration option for a team project, and policy definition is facilitated through the team project properties dialog.
• Policy evaluation: the process of determining whether a check-in satisfies a policy and occurs while a developer interacts with the IDE or the check-in process.

Team Foundation version control stores policies that developers define in a central location from which any Team Foundation version control client can retrieve the policies. These policies are also associated with particular team projects, so Team Foundation version control has a storage schema that provides a simple lookup mechanism for finding policies defined for a specific team project.

Daily automated build cycle

Software development is full of best practices which are often talked about but rarely seem to be practiced. One of the most fundamental, and valuable, of these is a fully automated and repeatable build process that allows a team to build and test their software many times a day or week.

The build and deployment processes should conform to a number of basic requirements, including the need to be completely automated and repeatable. If the system under development cannot be built directly from its source code and then deployed directly from its installation media, then it is not possible to integrate many of the key processes required for successful delivery.

There are several parts to establishing a fully automated and repeatable build:

• Maintain a single repository for all source code belonging to the project from where anyone can obtain the current sources (and previous versions).
• Automate the build process so that anyone on the project team can easily build the system from the sources.
• Automate the testing so that a complete suite of tests on the system can be run at any time.

Conclusion

VSTS provides integrated lifecycle tools to reduce the complexity of software development projects, facilitate collaboration amongst members of the team, and ensure predictability and repeatability of the development process. VSTS is also a platform that can be extended and customized. Using VSTS as the base, Avanade is building a Software Lifecycle Platform that provides the following benefits:

• The ability to quickly provision and reset the development environment in an automated fashion not only saves time for the project team upfront but it also ensures a consistent development environment across the team, which in turn can save time that would otherwise be spent in debugging issues caused by inconsistent development and test environments.
• Having the development methodology hosted in the Visual Studio IDE and incorporated into the team workflow helps the team follow a well-defined process without slowing down the team. This not only improves consistency across the team, it also allows for better tracking of progress on the project.
• Integrating VSTS with Microsoft Project Server provides a consolidated view that project stakeholders can use to track the status of the project and make decisions regarding the project.
• The ability to customize VSTS allows Avanade to enact best-practices and guidance gathered from previous projects in Visual Studio in the form of customizations to the toolset – thus reducing risk and improving repeatability of the software development process.

How Avanade SLP builds upon Microsoft VSTS

More Information

If you are interested in learning more about the Avanade Software Lifecycle Platform, please email us at slp@avanade.com

Seattle Office:

2211 Elliott Avenue

Suite 200

Seattle, Washington, 98121 seattle@avanade.com

www.avanade.com

Avanade is the leading technology integrator specializing in the Microsoft enterprise platform. Our people help customers around the world maximize their IT investment and create comprehensive solutions that drive business results. Additional information about Avanade solutions can be found at www.avanade.com/solutions.

This White Paper contains statements that may be related to the future development and direction of Avanade Inc. These statements may represent only current plans or goals of Avanade as of the date of publication and are subject to change without notice based on our technical and business judgment. Any reference to third party companies does not imply any involvement with or endorsement of or by Avanade Inc. Other company, product, and service names mentioned in this document are registered trademarks or trademarks of their respective owners.