Developer Tools Deployment Planning Services: Team Foundation Server Deployment Plan Template

Team Foundation Server
Deployment Plan Template
Developer Tools Deployment Planning Services
Page i
Team 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 .................................................................................................... 4
2.2.1 Current State – Urgent Issues ............................................................................................ 4
2.2.2 Current State - Additional Issues ........................................................................................ 5
2.3 Maturity level ........................................................................................................................... 5
3 Roadmap ................................................................................................................. 10
4 Detailed Findings ..................................................................................................... 13
5 Architecture ............................................................................................................ 17
6 Resources ................................................................................................................ 21
7 Conclusion ............................................................................................................... 23
Page ii
1 Getting the Most from Your Deployment Plan
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.
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 ii
2 Executive Summary
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.
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.
Guidance: This list can come from the RANGERS Application Lifecycle Management Assessment
 Quality issues
 No visibility into project status
 Projects delivered late
The following business priorities were articulated at the start of the assessment.
Guidance: This list can come from the RANGERS Application Lifecycle Management 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 iii
 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 iv
oProject 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 Management
o 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 level

During 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 v
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
Page vi
 Fully integrated portfolio management tools & process
 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 vii
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.
 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.
MATURITY
IMPACT Basic Standard Advanced Dynamic
Page viii
Urgent Improve Enhance Maintain
 Code Writing/Unit  Deployment
Testing  Test Planning
 Code Reviews  Build Management
 Quality Metrics
High  Collaborative
Development
 Version Control
Repository
 Release Management
 Environment
Management
Improve Improve Enhance Maintain
 Elicitation  Test Types
 Requirements
Analysis
 Traceability
Medium  Code Analysis
 Project Monitoring
and Control
 Stakeholder
Communications
Enhance Enhance Maintain Maintain

 Analysis & Design  Architecture
Low
 Database Modeling Framework
Page ix
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.
Iterations
Iteration 1 – Plan & Iteration 2 – Install TFS Iteration 3 – Verify
Prepare 201x 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 x
Iteration Details
Iteration 1: From: ##/##/#### To: ##/##/####
Plan & Prepare
Iteration 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:

<upgrade> <install> Team Foundation Server 201x
Iteration 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

Verify Installation and Onboard Teams
Iteration 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 xi
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.
Developer Onboarding Training

Iteration 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.
(Optional) Capture Process Improvement Metrics

Iteration 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.
Page xii
4 Detailed Findings
Detailed Findings
Requirements Engineering & User Experience Summary :

Elicitation
Maturity Level Rating: Basic
Impact Level Rating: Medium
Requirements 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

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.
Development 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
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.
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
Page xiii
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
Code 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

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
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.

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
Page xiv
to reflect the ability of the organization to implement such seemingly
simple practices
Quality Metrics
Software 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.
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.
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.
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

Build Management
Maturity Level Rating: Standard
Page xv
Deployment & 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 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
Project 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 standardized reporting should be a start
to the significant changes requisite for improvement
Page xvi
5 Architecture
Based 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
TFS-App01
TFS
SQL Server
Analysis Server
Reporting Services
SharePoint
TFS-BldAgent02
TFS Build
Agent
TFS-Test01
TFS-Build01 TFS Test
TFS Build Controller
Controller
TFS-TstAgent02
TFS Build
Agent
TFS-BldAgent01
TFS Build
Agent
TFS-TstAgent01
TFS Build
Agent
Page xvii
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
 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)
 Team Foundation Server 201x Build Services
To support the recommended automated test environment, a TFS test configuration is required:
 TFS-Test
 4 - 8 GB Memory
 2 CPU (cores)
 Team Foundation Server 201x Test Controller Services
 TFS-TstAgent01/02…
 2- 4 GB Memory
 Team Foundation Server 201x Test Agents
Page xviii
Architecture – Fault Tolerant Configuration
As an example of how a possible multi-server fault tolerant environment might be configured, the
following example is provided:
tfs-app.company.com
SharePoint
TFS-SSRS
SSRS
Load Balancer
TFS-SQL
OLTP/SSAS
TFS-App01
TFS-App02
TFS-BldAgent02
TFS Build
Agent
TFS-Test01
TFS Test
Controller
TFS-Build01
TFS Build
Controller
TFS-TstAgent02
TFS Build
TFS-BldAgent01 Agent
TFS Build
Agent
TFS-TstAgent01
TFS Build
Agent
Page xix
The fault tolerant environment consists of several assets:
 TFS-SQL
 16 GB Memory
 2 – 4 CPU (cores)
 512 GB – 1 TB disk space across 2 volumes (not including system drive)
 Database Engine
 Analysis Services
 TFS-SSRS
 4 - 8 GB Memory
 2 CPU (cores)
 Reporting Services
 TFS-App01/App02
 4 - 8 GB Memory
 2 CPU (cores)
 Team Foundation Server 201x
 TFS-Build
 4 - 8 GB Memory
 2 CPU (cores)
 Team Foundation Server 201x Build Services (Controller)
 TFS-Agent01/02…
 2- 4 GB Memory
 Team Foundation Server 201x Build Services (Agent)
 SharePoint
 SharePoint Farm
Page xx
6 Resources
The 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 one build
Page xxi
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 ALM
http://blogs.msdn.com/b/bharry/.
Page xxii
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 xxiii

Developer Tools Deployment Planning Services: Team Foundation Server Deployment Plan Template

Uploaded by

Copyright:

Available Formats

Developer Tools Deployment Planning Services: Team Foundation Server Deployment Plan Template

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Developer Tools Deployment Planning Services: Team Foundation Server Deployment Plan Template

Uploaded by

Copyright:

Available Formats

Team Foundation Server

Deployment Plan Template

Developer Tools Deployment Planning Services

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

4 Detailed Findings ..................................................................................................... 13

1.1 Give Microsoft Feedback

 Document existing Application Lifecycle Management (ALM) topology

2.1 Existing Best Practices

2.2 Key Areas for Improvement

2.2.2 Current State - Additional Issues

2.3 Maturity level

Basic (Current State)

Standardized (Desired State)

Advanced (Achievable in 6 – 18 mo.)

Dynamic (The North Star State)

Equal maturity progression across all areas

Progressing of the maturity in 1 – 18 months

Key Areas for Improvement

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

Enhance Enhance Maintain Maintain

Initiative Title Developer Onboarding

Initiative Title (Optional) Capture Process

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

 Strong leadership sponsorship is secured

Iteration Activities:  Review the Planning Checklist

Iteration 2: From: ##/##/#### To: ##/##/####

Iteration 3: From: ##/##/#### To: ##/##/####

Developer Onboarding Training

(Optional) Capture Process Improvement Metrics

Number of known issues that become priority fixes. You want to

Bugs by major system component- If there is a specific area of the code

Requirements Engineering & User Experience Summary :

Impact Level Rating: Medium

Impact Level Rating: Medium

Maturity Level Rating: Basic

Impact Level Rating: Medium

Impact Level Rating: High

Lack of unit testing is impacting the ability to truly measure code

Unit testing will enable development to have an automated reliable

Impact Level Rating: Medium

None of these are currently in place

Maturity Level Rating: Basic

Impact Level Rating: High

Impact Level Rating: High

Software Configuration Management Summary :

Maturity Level Rating: Basic

Impact Level Rating: High

Version Control Repository

Impact Observations: There is a significant opportunity to be attained in this area. These

Maturity Level Rating: Basic

Impact Level Rating: High

The QA and Production environment do not use the same deployment

Impact Level Rating: High

Project Planning & Management Summary :

Impact Level Rating: Medium

Single Server Configuration

Testing with Visual Studio and TFS

 ALM Rangers Guide – Visual Studio Test Tooling Guidance: