Team Foundation ServerDeployment Plan Template

Developer Tools Deployment Planning Services

Page iTeam Foundation Server Deployment Plan Template, Version 3, 10.2013

Table of Contents

1 Getting the Most from Your Deployment Plan.............................................................2

1.1 Give Microsoft Feedback.......................................................................................................2

2 Executive Summary.....................................................................................................3

2.1 Existing Best Practices..........................................................................................................3

2.2 Key Areas for Improvement...................................................................................................42.2.1 Current State – Urgent Issues...........................................................................................42.2.2 Current State - Additional Issues.......................................................................................5

2.3 Maturity level......................................................................................................................... 5

3 Roadmap.....................................................................................................................9

4 Detailed Findings.......................................................................................................12

5 Architecture...............................................................................................................16

6 Resources..................................................................................................................20

7 Conclusion.................................................................................................................22

Page iiTeam Foundation Server Deployment Plan Template, Version 3, 10.2013

1 Getting the Most from Your Deployment Plan

Our recommendations for optimizing the deployment of Team Foundation Server (TFS) in your environment are detailed within this document. Please take your time to review the findings and ask any follow-up questions necessary. Depending on the capabilities of your IT team, you may select to keep the deployment in house or contract with an outside consultant. In either case, this plan should be given to the party responsible for the work and used as an implementation guide.

1.1 Give Microsoft Feedback This Planning Service has been provided as part of your Microsoft Software Assurance benefits. Please use the link below to tell Microsoft about your experience with the engagement and any improvements you would like to see made to it. The results of the survey will only be viewed by the Planning Services team at Microsoft.

http://www.surveymonkey.com/s/5DS9JXP

Page iiiTeam Foundation Server Deployment Plan Template, Version 3, 10.2013

Guidance: This template includes guidance blocks and wording examples. Prior to handing over the document, remove the guidance blocks (like this one) and replace any highlighted sample text (in green text) with your findings and recommendations.

2 Executive Summary

At the request of <Customer Name>, <Partner name> conducted the Team Foundation Server Deployment Planning Service with the following objectives:

Document existing Application Lifecycle Management (ALM) topology Create a baseline measurement of the current development capability Surface existing best practices Uncover opportunities for improvement Identify the most impactful areas to the business Document ideal end-state for a Team Foundation Server (TFS) 201x deployment. Generate and present a roadmap to <implement> <upgrade> Team Foundation Server 201x

The Application Lifecycle Management (ALM) model was used as a framework to develop a vision and sustainable approach by which <Customer Name> can prioritize IT investments that fuel business growth. The engagement focused on understanding existing development processes and recommending process improvements. Technology and people/knowledge requirements were then identified to support the process.

The following issues with the current development capability were articulated at the start of the assessment.

Quality issues No visibility into project status Projects delivered late

The following business priorities were articulated at the start of the assessment.

Improve quality Improve customer satisfaction

2.1 Existing Best Practices

Our interviews surfaced the following Best Practices that are being used by teams at <Customer Name> today. These practices are:

Page ivTeam Foundation Server Deployment Plan Template, Version 3, 10.2013

Guidance: This list can come from the RANGERS Application Lifecycle Management Assessment

Guidance: This list can come from the RANGERS Application Lifecycle Management Assessment

Guidance: The audience for this section will be interested in being able to read and digest this quickly. Keep the text in this section concise.

The Functional Testing/QA group is clearly an organizational asset- they have been able to take the amount of work which was originally six (6) to eight (8) weeks for ten resources and automate the running of the regression bed to four (4) days. This provides immediate measurable benefit to the development as a whole, mainly because of the weight that is put on this group to ensure quality. This group is implementing practices that will continue to move the organization to a TDD (Test Driven Development) approach

There are many emerging capabilities relative to requirements management. The ongoing progress resulting from the implementation of formal Requirements Management at the User Interface level will serve the organization well as a starting point for future development and implementation of process in this space. Additionally, in sharing the product roadmap with the user community, the stage is being set to stave off the reactive demand for priority fixes through simple expectation setting.

The commitment to and movement of the production environment to an Active/Active model - this will immediately address the challenges with the deployment of new builds and the subsequent impact of bringing the system down when installing new builds

The build group is successfully employing (build) automation to minimize the impact of manual error in the core build process.

<Customer Name> is a highly customer focused organization and despite the challenges resulting from a lack of process discipline, they continue to provide a high level of support to their clients (especially those clients with custom configurations). Understandably, the organizational culture also resonates a strong delivery focus to dates

We recommend that these practices continue to be employed and are continuously evaluated and improved in order to promote process optimization.

2.2 Key Areas for Improvement

2.2.1 Current State – Urgent Issues

During our onsite interviews, we uncovered the following practices that should be considered critical and essential to improving the development capability in relation to their impact on the business. These practices were:

Development o Code Writing/Unit Testing - Test driven development implemented via a unit

testing framework including data generation.o “End Game” Process and Code Reviews – Code reviews are always a good practice,

but for <Customer Name> this is critical to late cycle changes.o Developer On-boarding – We uncovered a lack of clear coding guidelines and clear

training materials for new developers Quality

o Defect/Bug Tracking - One unified and integrated process for defect management from its inception to re-release into production

o Metrics Capture and Improvement - Development of a metrics strategy and ongoing refinement to improve predictability and quality

Page vTeam Foundation Server Deployment Plan Template, Version 3, 10.2013

o Project management of Non-Charter Projects - Introduction of a disciplined triage process with one point of accountability driving resolution

o Feedback – Continuous, easy feedback from all parties involved in the software process (including product owners, user acceptance testers, end users, etc.).

Release Managemento Code Promotion - Defined branching and merging process to ensure continuous

integration o Priority Triage - Elimination of randomization in the priority process and

implementation of a predictable and measurable approach o Build Management - Ongoing refinement of automated build process and increased

automation to minimize risk of human error Operations Management

o Deployment environment (brute force deployment of .NET) apps- Definition and automation of deployments which leverage the features of the .NET framework to reduce complexity

o Service level management - Creation and management of a 24/7 environment to minimize accessibility outages

o Production Monitoring – Being able to monitor and easily reproduce production defects, bugs, exceptions, etc.

2.2.2 Current State - Additional Issues

During the course of the assessment, we were able to identify additional issues that we believe are having a material impact on Application Lifecycle Management within <Customer Name>. These include:

Defect Management Process Automation - The current tool’s lack of integration is creating an unnecessary level of complexity and duplication of work within the processes associated to bug tracking and defect management/ resolution. Additionally, the minimal automated traceability and validation associated to fixes for compliance/ reporting purposes further complicate any impact analysis or compliance considerations

Lack of Predictability and Ownership of Builds - The absence of a governing body to control scope and drive the implementation of builds has created an uncontrollable work cue as well as resourcing challenges. Equally this prevents a true understanding a capacity for effective sourcing as well as any defence against scope control.

The need for agile methods – The current SCRUM efforts will ultimately promote higher quality and delivery frequency if implemented properly. The existing behaviours such as borrowing resources during sprints will not promote that. There needs to be a level commitment established for this and all parties involved must understand the process

Low Developer Morale – The current inward spiral created by the PTF process is having a demoralizing effect on the developers who are constantly being pulled to resolve one issue after another. Worse is that this process seems to have no end and continue to promote a sense of malaise among the developers

2.3 Maturity levelDuring the interview process, <Partner name> established a maturity level for the development process. The Rangers ALM Assessment Tool was used to measure and to create the maturity model.

Page viTeam Foundation Server Deployment Plan Template, Version 3, 10.2013

The key elements of the Basic level are shown below. In the Basic level, most of the practices are manual and untraceable. This state has a large amount of waste, poor value flow, and little transparency.

Basic (Current State) The Development team has adopted home-grown ways of performing practices Practices are performed in an ad-hoc, informal manner Practices are undocumented Little to no transparency exists across teams Inconsistency in some of the key roles being performed (QA)

The Standardized level is the desired state for software teams to achieve with TFS and improved practices. At that level, better workflow and transparency start to emerge. The teams begin to see the value flow and reduction of waste in manual tasks, such as email tracking, clear definition of done, priorities, and requirements.

Standardized (Desired State) ALM best practices (Agile, Lean, etc..) begin to be adopted Tools used are starting to become connected and integrated Team capacity planning starts to emerge Requirements and workflow are entered into the TFS system Builds and deployment cycles start to become automated Reporting data becomes available

The Advanced and Dynamic State can be achieved once the foundation and solid practices are in place. We have seen that after the key practices and tools are in place, it is a natural progression to move toward a more mature level to improve the quality and cycle time.

In the Advanced and Dynamic states, the team begins to fully utilize the ALM tools and Agile consensus patterns (Transparency, Reduction of Waste, and Flow of Value). Automation and quick feedback loops are the norm. Clear requirements and business direction are piped into a prioritized backlog. Teams and stakeholders understand expectation of delivery and priorities. Trusted forecasting on complex initiatives are completed.

Advanced (Achievable in 6 – 18 mo.) Use of practices and tools across teams Requirements are well defined and delivered to the Backlog Agile practices are used to break down the complex work into deliverable iterations Testing is done during all cycles (Unit, Functional and UAT) Automation of builds and tests Fast feedback loops in all phases Bug tracking and traceability Architectural practices and tools are being used Documentation is formally maintained Fully integrated portfolio management tools & process

Page viiTeam Foundation Server Deployment Plan Template, Version 3, 10.2013

Ability to track requirements and use impact analysis reports for change requests Using Helpdesk quality metrics on turnaround time, cost of maintenance, and identification

of error

Dynamic (The North Star State) Continuous delivery practices in place Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD) practices

are established Optimizing cycle-time to learn from customers Systems are architected with continuous deployment in mind, supporting patterns such as

dark launching to decouple deployment from release All new requirements describe how the value of the feature will be measured

In the standardized state, all of the ALM disciplines are coved equally. While this is the desired goal, the reality is there will be areas that advance more than others.

Equal maturity progression across all areas

Progressing of the maturity in 1 – 18 months

Page viiiTeam Foundation Server Deployment Plan Template, Version 3, 10.2013

A more realistic view of maturity progression

Growth in just one area is not a healthy progression. An evolution in each area is a much healthier growth rate and direction that provides a solid foundation to improve upon.

The eventual roll out of process and tools to address the opportunities mentioned in this assessment should follow a tight metrics driven approach to improvement. While we recognize that change takes time and reinforce that change requires commitment, it is important to create both a strategic and tactical plan for addressing these challenges, as well as answering the questions of where do we want to be in three, six twelve months and how will we quantify our success.

The implementation approach defined later in this document is built on the four key themes identified earlier (Development, Quality, Operations, and Release Management). We believe that by improving capability in these areas, we can address the current challenges experienced at <Customer Name>.

Key Areas for Improvement

Our interviews revealed multiple areas for improvement. These were rated by impact to the business (High, Medium or Low) across the maturity levels. These are shown in the Impact Map.

The x-axis defines the maturity level of the service area. The categories are:

Basic - processes are implemented in an ad-hoc, undocumented and potentially inconsistent manner.

Page ixTeam Foundation Server Deployment Plan Template, Version 3, 10.2013

Standard - a process has been defined and is generally followed. Tools are used in some cases to assist, but may not be integrated and used throughout the organization.

Advanced - usage of tools to drive the process is in wide use and usage guidelines are documented and understood.

Dynamic - the organization is bringing new and innovative methodologies to the practice area and may setting industry standards.

The y-axis defines the relative gain that would be obtained from improving the practice.

MATURITYIMPACT Basic Standard Advanced Dynamic

High

Urgent Improve Enhance Maintain Code Writing/Unit

Testing

Code Reviews

Quality Metrics

Collaborative Development

Version Control Repository

Release Management

Environment Management

Deployment

Test Planning

Build Management

Medium

Improve Improve Enhance Maintain Elicitation

Requirements Analysis

Traceability

Code Analysis

Project Monitoring and Control

Stakeholder Communications

Test Types

Low Enhance Enhance Maintain Maintain Analysis & Design Architecture

Page xTeam Foundation Server Deployment Plan Template, Version 3, 10.2013

Database Modeling

Framework

Page xiTeam Foundation Server Deployment Plan Template, Version 3, 10.2013

3 Roadmap

Based on our observations and discussions, we recommend that the following iterative roadmap be implemented in order to better align the development capability with the business, and enable development efforts to drive increased value to <Customer Name>.

Please note that the areas for improvement mentioned in the prior section which are marked as urgent may not be addressed immediately. In some cases, the foundation for improving a particular service area will not be in place in the first or second iteration.

IterationsIteration 1 – Plan & Prepare

Iteration 2 – Install TFS 201x

Iteration 3 – Verify Installation and Onboard Team

Dates ##/##/#### - ##/##/#### ##/##/#### - ##/##/#### ##/##/#### - ##/##/####

Initiative Title Plan & Prepare Install TFS 201x Verify Installation and Onboard Teams

Capabilities

Initiative Title Developer Onboarding Training

Capabilities

Initiative Title (Optional) Capture Process Improvements Metrics

Capabilities

The date ranges for each iteration are placeholders. Planning and estimation sessions will be necessary to determine the achievable dates.

When embarking on an effort to optimize the development capability we recommend that:

Strong leadership sponsorship is secured Overall goals are clearly communicated to all stakeholders Clear metrics and milestones are established and agreed to

Page xiiTeam Foundation Server Deployment Plan Template, Version 3, 10.2013

Iteration Details

Iteration 1: From: ##/##/#### To: ##/##/####Plan & PrepareIteration Goals: By Implementing Team Foundation Server for Source Control and Code

Promotion, we will unify the source code from both .NET development and Cold Fusion development into one source control solution. By leveraging the branching and merging capabilities of Team Foundation Server, we will simplify the current code promotion process which will enable a consistent promotion process with clear understanding of which stage code is in and direct ties to the testing environments.

Iteration Activities: Review the Planning Checklist Review the System Requirements Verify hardware availability Verify Process Template and considerations for customization Review reporting requirements Verify branching strategy Verify build strategy Verify resource availability

Iteration Cross References:Impacted Capabilities:

Iteration 2: From: ##/##/#### To: ##/##/####<upgrade> <install> Team Foundation Server 201xIteration Goals: Following the guidance as laid out in the DPS TFS Deployment

Assessment, <upgrade> <install> and configure TFS.Iteration Activities: Setup Team Foundation Server

Development Operational Guidance to ensure system stability Develop Security Access Plan Develop Branching and Merging Design Migrate Source Code Training Development Teams and Release Management Teams Migrate Cruise Control Build Solution to Team Build

Iteration Cross References:Impacted Capabilities:

Iteration 3: From: ##/##/#### To: ##/##/####Verify Installation and Onboard TeamsIteration Goals: Leverage automated build and test capabilities to provide a consistent

quality measure including code analysis and automated unit testing. During the first iteration, the build solution was moved to TFS and this phase makes further investment to enable a much richer testing harness. At the competition of this initiative, code quality will be measurable by simply building the solution.

Page xiiiTeam Foundation Server Deployment Plan Template, Version 3, 10.2013

Iteration Activities: Verify installation and configuration Install client tools and verify connectivity to TFS (Optional – if applicable) Verify remote connectivity Verify end-to-end work flow by building a solution (Optional) Train users (development, test, PM, etc.) on how to

connect to and use TFS 201x.Iteration Cross References:Impacted Capabilities:

Developer Onboarding TrainingIteration Goals: Create or acquire developer onboarding training materials to reduce

the time and resources necessary to bring new developers into the team.

Iteration Activities: Develop Sample Applications that outlines the key "How-To" points of the application architecture.Refresh coding standards and providing training to all development staff on existence.

Iteration Cross References:Impacted Capabilities:

(Optional) Capture Process Improvement MetricsIteration Goals: Understanding the components of the process that represent the best

opportunity for improvement is critical to investing in the right changes. The following the recommended items to collect

Number of known issues that become priority fixes. You want to confirm that the prioritization process is learning from the past and is not based on gut feel. By collecting this metric, one can measure the effectiveness and number of categorize fixes that were missed and can use this information during the prioritization process moving forward.

Bugs by major system component- If there is a specific area of the code that is buggy, it is valuable to be able to analyze the code base including code complexity to determine if rewriting the entire section would improve overall stability.

Iteration Activities: Use current systems to track metric as best as possible.Iteration Cross References:Impacted Capabilities:

Page xivTeam Foundation Server Deployment Plan Template, Version 3, 10.2013

4 Detailed Findings

Detailed Findings

Requirements Engineering & User Experience Summary :Elicitation  Maturity Level

Rating:Basic

  Impact Level Rating: MediumRequirements Analysis  Maturity

Observations:The proficiencies relative to any formal requirements analysis are minimal but seemingly evolving. As the requirements group matures and moves from a UI driven approach to more comprehensive approach to requirements management, this should continue to improve

  Maturity Level Rating:

Basic

  Impact Level Rating: Medium  Best Practices: There are many emerging capabilities relative to this

capability as the resulting of the implementation of this new group and although the requirements efforts are focused on elicitation, the feasibility to implement this practice is well positioned for successful adoption

Traceability  Maturity

Observations:There is minimal traceability present within the development lifecycle. The QA group has established an initial level of traceability, but the drivers of this should be clear so any commitment to this should be value added for both the business and IT.

  Maturity Level Rating:

Basic

  Impact Level Rating: MediumDevelopment Summary :Code Writing  Maturity

Observations:Coding standards and naming standards exist, but are not well known and not used by the team. Unit testing has been attempted, but was not successful. This combined with the inherent challenges with the two separate environments (cold fusion/.NET) will further complicate this practice

  Maturity Level Rating:

Basic

  Impact Level Rating: High  Impact

Observations:Developer on boarding is impacted by the lack of known published standards and training programs. The result is the best developers spend more than 50% of their time to onboard a new developer.

Lack of unit testing is impacting the ability to truly measure code quality in development and through-out the lifecycle.

Page xvTeam Foundation Server Deployment Plan Template, Version 3, 10.2013

  Best Practices: Team are highly encouraged to take secure coding training as well as employ formal code reviews during the development cycle

  Impact Benefits: Building Repeatability into the on boarding process will enabling you to more easily flex development team to meet demand and will enable your best developers to focus on the solution architecture and developing new features.

Unit testing will enable development to have an automated reliable measure of code quality before QA cycle are spent testing it.

Code Analysis  Maturity

Observations:There was minimal discovery of formal code analysis- The implementation of more formal practices in this space would positively impact additional areas such as design, testing as well as the overall capabilities relative to traceability

  Maturity Level Rating:

Basic

  Impact Level Rating: MediumCode Reuse  Maturity

Observations:Process areas concerning the following are paramount to reuse:1) Reusable asset identification – Each project team needs to have time allocated with their enterprise architecture to review (continuously) their technical solution for assets that qualify as enterprise reusable (shareable) to the entire organization. There are simple procedures to put in place that assist in enforcing this practice.2) Reusable asset harvesting-Each asset, once identified as reusable, needs a team of resources that have time allocated to scrub the asset and incorporate it via development and further description (the OMG has rules for this) into their own reusable asset library (Wojtek Kozaczynski, working for Microsoft was one of the original authors of the OMG’s reusable asset specification) 3) Reusable Asset Management- The library (and its owners) need to write rules for adding assets to the library as well as how they are stored and indexed for search.4) Reusable Asset Consumption- The library needs to make sure that requests can be made proactively. This means that a typical team does not know that the assets exist, and it’s the library management team’s responsibility to engage with teams at the architectural level to ensure that assets are requested and consumed.

None of these are currently in place  Maturity Level

Rating:Basic

  Impact Level Rating: Medium  Impact Benefits: With the ongoing migration of the Net teller app to

the .NET platform from cold fusion, the reusability of core assets is appealing. There will need to be additional capacities and considerations to attain this level of maturity, but through commitment, this should deliver real benefits

Code Reviews

Page xviTeam Foundation Server Deployment Plan Template, Version 3, 10.2013

  Maturity Observations:

This requisite practice is done sparingly and is relatively in formal; nonetheless the seemingly cultural impact to a more formal structured approach may not be as impacting as other process best practices implementations.

  Maturity Level Rating:

Basic

  Impact Level Rating: High  Impact Benefits: The ability to scale the .NET team as well as the

development organization as a whole is dependent on the implementation of repeatable best practices. This simple practice has the inherent ability to reflect the ability of the organization to implement such seemingly simple practices

Quality Metrics  Maturity Level

Rating:Basic

  Impact Level Rating: HighSoftware Configuration Management Summary :Collaborative Development  Maturity

Observations:Collaborative Development is accomplished today by a complex set of labels in the branching solution. Although concurrent development is recommended, it usually is associated with a cost and a learning curve.

  Maturity Level Rating:

Basic

  Impact Level Rating: High  Impact

Observations:Currently the customer is suffering; They are manually promoting code from one environment to the next. To enable concurrent development they have used a complex label process. Fixing this process will have impact across the board in the release process.

  Impact Benefits: By simplify how concurrent development is accomplish, <Customer name> can simplify the life of development and allow Release Management more time to monitor highly valued aspects of the release process

Version Control Repository  Maturity

Observations:Labels are currently being employed as a branching approach. This is further complicated by the multiple and various CM systems (Version Manager and VSS) The build management is done in source safe and it is transferred via zip file to the VM system.

  Maturity Level Rating:

Basic

  Impact Level Rating: High  Impact

Observations:There is a significant opportunity to be attained in this area. These manual processes can be improved through automation through the implementation of TFS.

  Impact Benefits: Unified version control with a code promotion process supported by the tools will ultimately deliver significant value to the team. This includes time saved in the day to day process and few mistakes that impact the entire team.

Page xviiTeam Foundation Server Deployment Plan Template, Version 3, 10.2013

Release Management  Maturity

Observations:A root cause analysis of the many quality challenges can be traced to the manual involvement of the release process. Mistakes are known to occur between labeling and the release of the code. This combined with the lack of formal ownership of the release itself can create potential chaos. No one person appears to be accountable for the management of the release

  Maturity Level Rating:

Basic

  Impact Level Rating: HighBuild Management  Maturity Level

Rating:Standard

  Impact Level Rating: HighDeployment & Operations Summary :Deployment  Maturity

Observations:There are apparent gaps that further put quality at risk within the deployment space. This is ever present with the management of the custom application code. Practices such as not applying formal QA to custom code or the practice of a custom team folding code back over a code baseline significantly compromises quality.

The QA and Production environment do not use the same deployment mechanism and therefore testing is not actually testing deployment

  Maturity Level Rating:

Standard

  Impact Level Rating: High  Impact

Observations:Allowing the deployment process to be tested in the natural course of testing with provide further assurance that deployment will be a smooth process.

  Impact Benefits: Reduced the deployment errors found in production by testing the deployment process in QA.

Environment Management  Maturity

Observations:The multiple environments are managed through heroic efforts. The testing and staging environments are not automatically synchronized, and this creates risk in bug definition and tracking. Equally it creates significant challenges in the management of the numerous PTF's

  Maturity Level Rating:

Basic

  Impact Level Rating: HighProject Planning & Management Summary :Project Monitoring and Control  Maturity

Observations:With the reactive management of the ongoing PTF fixes as well as the seemingly lack of ownership of a release, there appears to be strong opportunity to improve the project control of these efforts. The introduction of formalized and

Page xviiiTeam Foundation Server Deployment Plan Template, Version 3, 10.2013

standardized reporting should be a start to the significant changes requisite for improvement

  Maturity Level Rating:

Basic

  Impact Level Rating: Medium

Page xixTeam Foundation Server Deployment Plan Template, Version 3, 10.2013

5 ArchitectureBased on the size of <Customer Name>’s development teams, a single server implementation of TFS would more than satisfy their needs. The single server implementation can easily be scaled out to a multi-server configuration if needed to support growth or if immediate fault tolerance becomes an area of major concern. The advantages of a multi-server fault tolerant solution are the ability to take a single application server offline for maintenance as well as provide load-balanced redundant service to all team members.

A single server implementation is less expensive and easier to implement, but it does not provide any fault tolerance. While a single server implementation is recommended, nothing precludes <Customer Name> from starting with a single-server implementation and expanding on it, if and when the need arises.

Single Server Configuration

Page xxTeam Foundation Server Deployment Plan Template, Version 3, 10.2013

The environment consists of a single server for the core TFS services:

TFS-App01 Windows Server 201x Standard

16 GB Memory 2 – 4 CPU (cores) 512 GB – 1 TB disk space across 2 volumes (not including system drive)

SQL Server 201x Standard Database Engine Analysis Services Reporting Services

Team Foundation Server 201x SharePoint Server 201x

To support the recommended automated build environment, a TFS build configuration is required:

TFS-Build Windows Server 201x Standard

4 - 8 GB Memory 2 CPU (cores) 100 GB disk space

Team Foundation Server 201x Build Services

TFS-BldAgent01/02… Operating System to support applicable build

2- 4 GB Memory 1 - 2 CPU (cores) 100 GB disk space

Team Foundation Server 201x Build Services

To support the recommended automated test environment, a TFS test configuration is required: TFS-Test

Windows Server 201x Standard 4 - 8 GB Memory 2 CPU (cores) 100 GB disk space

Team Foundation Server 201x Test Controller Services

TFS-TstAgent01/02… Operating System to support applicable build

2- 4 GB Memory 1 - 2 CPU (cores) 100 GB disk space

Team Foundation Server 201x Test Agents

Page xxiTeam Foundation Server Deployment Plan Template, Version 3, 10.2013

Architecture – Fault Tolerant Configuration

As an example of how a possible multi-server fault tolerant environment might be configured, the following example is provided:

Page xxiiTeam Foundation Server Deployment Plan Template, Version 3, 10.2013

The fault tolerant environment consists of several assets:

TFS-SQL Windows Server 201x Standard

16 GB Memory 2 – 4 CPU (cores) 512 GB – 1 TB disk space across 2 volumes (not including system drive)

SQL Server 201x Standard Database Engine Analysis Services

TFS-SSRS Windows Server 201x Standard

4 - 8 GB Memory 2 CPU (cores) 100 GB disk space

SQL Server 201x Standard Reporting Services

TFS-App01/App02 Windows Server 201x Standard

4 - 8 GB Memory 2 CPU (cores) 100 GB disk space

Team Foundation Server 201x TFS-Build

Windows Server 201x Standard 4 - 8 GB Memory 2 CPU (cores) 100 GB disk space

Team Foundation Server 201x Build Services (Controller) TFS-Agent01/02…

Operating System to support applicable build 2- 4 GB Memory 1 - 2 CPU (cores) 100 GB disk space

Team Foundation Server 201x Build Services (Agent) SharePoint

SharePoint Farm

Page xxiiiTeam Foundation Server Deployment Plan Template, Version 3, 10.2013

6 ResourcesThe following is a list of very useful resources readily available to deepen knowledge and understanding of Team Foundation Server:

Testing with Visual Studio and TFS

ALM Rangers Guide – Test Release Management: http://vsartestreleaseguide.codeplex.com/

This Visual Studio ALM Ranger project has the primary goal of delivering scenario based and hands-on guidance for managing Microsoft Test Manager Test plans.

ALM Rangers Guide – Visual Studio Test Tooling Guidance: http://vsartesttoolingguide.codeplex.com/

This umbrella project delivers a range of practical and scenario based guidance for Visual Studio test features, such as Coded UI, Microsoft Test Manager, IntelliTrace, and Microsoft Fakes.

Branching and Merging

Visual Studio Team Foundation Server Branching and Merging Guide: http://vsarbranchingguide.codeplex.com/

The purpose of this project is to build some insightful and practical guidance around branching and merging with Visual Studio Team Foundation Server.

TFS and Project Server Integration

Team Foundation Server and Project Server Integration Virtual Machine and Hands-on-Labs:http://blogs.msdn.com/b/briankel/archive/2013/04/12/team-foundation-server-2012-and-project-server-2013-integration-virtual-machine-and-hands-on-labs-demo-scripts.aspx

This Hyper-V virtual machine and associated hands-on labs do a great job of introducing the possible used of the TFS Project integration.

Enable Data Flow Between Team Foundation Server and Microsoft Project Server:http://msdn.microsoft.com/en-us/library/gg455680.aspx

This MSDN article describes the steps necessary to configure Project Server to work with TFS.

Automated Build-Deploy-Test

Setting Up Automated Build-Deploy-Test Workflows:http://msdn.microsoft.com/en-us/library/hh191495.aspx

You can use a build-deploy-test workflow to deploy and test your application when you run a build. This lets you schedule and run the build, deployment, and testing of your application with

Page xxivTeam Foundation Server Deployment Plan Template, Version 3, 10.2013

one build process. Build-deploy-test workflows work with Lab Management to deploy your applications to a lab environment and run tests on them as part of the build process.

Visual Studio Team Foundation Build Customization Guidance:http://vsarbuildguide.codeplex.com/

This Visual Studio ALM Ranger project has the primary goal of delivering scenario based and hands-on lab guidance for the customization and deployment of Team Foundation Build.

Miscellaneous ALM Resources

Getting started with Application Lifecycle Management: http://msdn.microsoft.com/en-us/library/dd286491.aspx.

Team Foundation Server on MSDN:http://msdn.microsoft.com/en-us/vstudio/ff637362.

Microsoft Visual Studio Virtual Labs:http://msdn.microsoft.com/en-US/vstudio/ff640662.

Team Foundation Server Migration and Integration Solutions:http://msdn.microsoft.com/en-us/vstudio/bb840033.

Brian Keller: Microsoft Sr. Technical Evangelist for Visual Studio ALM:http://blogs.msdn.com/b/briankel.

Visual Studio Team Foundation Server Planning Guide:http://vsarplanningguide.codeplex.com/.

Visual Studio ALM + Team Foundation Server Blog: http://blogs.msdn.com/b/visualstudioalm/.

Brian Harry’s Blog: Everything you want to know about Visual Studio ALMhttp://blogs.msdn.com/b/bharry/.

Page xxvTeam Foundation Server Deployment Plan Template, Version 3, 10.2013

7 Conclusion

We recommend that the implementation of the practices outlined in this document be validated during the initial deployment and as projects and teams are brought on board the system. The flexibility the TFS platform includes allows many changes to be made after initial deployment to compensate for needed changes to the configuration, either initially or later due to changes in needs.

To encompass all of the recommendations in this document, a schedule for all of the relevant tasks should be created. Complete implementation and customization should be done by <Customer Name> operations staff.

Page xxviTeam Foundation Server Deployment Plan Template, Version 3, 10.2013