Visual Studio Team System helps software development teams successfully deliver complex software solutions with Microsoft Visual Studio Team System (VSTS). Discover how VSTS enables you to enforce best practices for software development. Enable communication and collaboration across the team–project managers, architects, developers and testers. Learn how VSTS enhances each of the roles in software development via project management tools, design tools, test case management, and customization. The course uses the latest version of Team System, Visual Studio Team System 2008.

You’ll get answers to these questions:

• How can I create and manage a complex software project?
  
• How can I use VSTS to design a project, generate a code framework, and build a deployment plan?
  
• How can I develop and manage test cases?
  
• How can I enforce policies and business practices across the project?
  
• How can I customize VSTS to accommodate existing development practices?
  
• How can I do a new build when a developer checks in code?
  
• How do the features of Team System support my project lifecycle?
  

Come and learn to integrate and manage all aspects of software development!

DevelopMentor’s Essential courses provide five days of instructor-led training for the experienced developer. Gain deep understanding of your development platform. Acquire skills you need to be productive today. Build a solid foundation for more advanced topics.

• Use VSTS to enforce best practices of software development
• Understand the VSTS tools and how and where they fit into the project lifecycle
• Learn how VSTS can be configured to use different software methodologies
• Use graphical modeling tools to create a system design and validate its deployment
• Employ test-driven development to produce robust code
• Harness the power of source control
• Learn how to manage testing and track bugs
• Set up a project portal to access all project documentation
• Manage databases with Visual Studio Team Edition for Database Professionals
• Schedule Builds with Team Build
• Use Team Build continuous integration features

Day 1 Introduction to VSTS This module presents an introduction to Microsoft's Visual Studio Team System, a new platform for integrating and managing all aspects of the software development process. It provides an overview of the Team System Client applications and the Team Foundation Server, discussing how and where each feature fits into the software development cycle and how it pertains to each project role. Project Lifecycle Management: Introduction to Managing Projects with VSTS This module presents an introduction to project management with Microsoft's Visual Studio Team System. In particular, this module shows how project managers can use VSTS to create and manage a software development project. It explains how to organize the team according to their roles within the project, how to set up the project methodology that best fits the way the team will work and how to configure project policies such as security policies. It also focuses on how to generate and manage tasks for other team members, how to create and manage project milestones, how to use reports to track the progress of the project and how to configure a project portal so that documents may be shared between team members. As well as discussing how to use the Team Explorer tool to manage the project, it also explores how to integrate other related tools commonly used by project managers today, such as Microsoft Excel and Microsoft Project. Project Lifecycle Management 2: Customizing Process Templates It may be that the Software Development Lifecycle process methodologies that are supported by VSTS do not fit your organization's needs. However, VSTS uses process templates to represent the core information about these methodologies and these templates can be customized. This module shows how to change the contents of an existing template or add new ones, amending such details as work items, work item queries, reports, document templates and process guidance. Source Code Control: Introduction Source code control, or revision control, is the management of revisions to pieces of information that makes up a project. Many applications make use of source code control to manage their code, documentation, project data and any other information that a project requires. VSTS introduces a new source control management system, entirely separate from Visual Source Safe (Microsoft's previous source control offering). A VSTS project will typically have one or more source control folders associated with it. Each folder is a location where project items can be stored, and are created either during project creation or at a later stage as needed. The actual data that the source control system manages is held in a SQL Server 2005 database set up during the installation of Team Foundation Server. Project members can perform various actions on the source control repository, and in this chapter we will look at the basic mechanisms involved in source control. Members can check data into and out of source control. When checked out the data is associated with a client side 'workspace'. The workspace is an area on the client that holds checkout data. A given client may have multiple workspaces, this allows the clients to checkout different parts of the repository into different workspaces allowing clients (for example) to work with multiple versions of the code. Checkins are atomic and each checkin creates a new changeset. A changeset is a snapshot of all the files in the folder at the time this change was committed, each changeset is given a number (the changeset version). Users can checkout the latest version from the repository or can checkout a specific changeset. Changesets can also be labeled and users can checkout a given labeled version of the repository, users can also check out a version that was checked in on a specific date. All the above work can be done with the Project Explorer, Microsoft also supplies a command line tool called tf.exe and in this chapter we will take a first look at that tool. Day 2 Source Code Control 2: Advanced Topics One of the features that Microsoft provides is the ability to 'branch' the source control repository. A branch is essentially a copy of the repository and branching allows a developer to work on new features without changing the current version that can still be worked on by other developers within the group. We will examine how branching is performed and how to manage branches as a user. Changes a developer makes in a branch may need to be added back into the main source control tree or indeed into another branch, this process is called merging. Microsoft has also introduced a concept that is new to source control, the idea of Shelving. The concept behind shelving is that a developer may be working on changing code and is then asked to work on something else. Rather than save the current changes locally and risk losing them, or check them back into source control when they are not finished, a developer can 'shelve' the changes. Shelves are essentially named branches that belong to a developer. They can be re-checked out by the person that created the shelve or by another user. Shelves are useful in many scenarios during the lifetime of a project and will be examined in detail. Finally, this module looks at how source control can be customized by writing and installing custom check-in policies and writing code that responds to source code control events. Modeling: The Distributed System Designers This module shows how software architects can use VSTS tools to create a system design that can be successfully deployed onto an infrastructure design. It will cover four main tools; the Logical DataCenter Designer, the Application Designer, the System Designer and the Deployment Designer. The Logical DataCenter Designer allows an infrastructure architect to define an infrastructure design - a network and datacentre onto which the system will be deployed. It allows the definition of zones and their communication paths and then clients and servers within those zones and their communication paths. The Application Designer allows the solution architect to define an application design - the applications, services and their respective communication paths. It can then be used to generate a code framework from the application design that can be used by a developer to start the implementation. The System Designer allows the definition of a system design - a particular configuration of the application design. The Deployment Designer allows a trial deployment to be defined which validates an application/system design against the infrastructure design and produces deployment reports. This module explores the usage of each of the above tools and how they relate to each other during the design phase of a software project. Test-Driven Development and Unit Testing In recent years, unit testing has become recognized as a very important part of the software development lifecycle. A new style of development, Test Driven Development (TDD), has also come to the fore. In this chapter we will examine how VSTS supports TDD. We will start by explaining unit testing and defining what a unit test actually is. We will then look at writing unit tests in VSTS in particular looking at the attributes that are used when defining a 'test case' and how to write code to determine whether or not a test has succeeded or failed. We examine how to execute and debug tests and how to view test results. We also examine other areas of the test process such as checking for exceptions and writing code to initialize the test. VSTS also allows us to generate tests for already existing code; we will look at that process and at the generated test code. We may also have a need to test private methods. VSTS can generate stub code to test private methods. This chapter will examine that code and how it should be used within the test project. When testing it is important all code is tested, but how does a developer know that all the code in a project has been exercised? VSTS offers the ability to instrument code to show which code has been executed and which has not. In this chapter we will show how to configure a test run to also execute the code coverage engine. This module will also show how testers can manage the tests they want to run by creating test lists, how they can publish the results of those tests and how reports based on those tests can be viewed. When testing a specific method you will often want to test the method with different data. For example you want to test 'edge' conditions (values such as 0, +INF or -INF when dealing with integers). While this can be done by writing multiple tests it is also possible in VSTS to do this using a 'Data Driven' test. In a data driven test the test data is stored in a database table and this table is specified during the test process, each row in the table represents a different test case. In this talk we will show how to create the database, how to specify the table and columns within that table to use and how that data is passed to the test. We will also discuss the thorny issue of how to manage this database. Day 3 Unit Testing Web Apps As well as being able to test the functionality of web applications it is also necessary to test the 'View' logic of the applications in-situ. We can do that with Visual Studio. Using the Unit Testing tools it is possible to write/generate unit tests for code in the 'App_Code' directory of an ASP.Net web application and also any code in an ASP.Net web service. To do that we also need to understand how the unit testing framework allows us to host the tests within the ASP.Net runtime, how to specify the correct URLs to use for the tests and how to specify the web server to use for the code under test. Managing and Testing Databases with Visual Studio Team Edition for Database Professionals Enterprise developers use databases constantly and these databases can become very large and often unwieldy. Visual Studio Team Edition for Database Professionals provides various mechanisms for managing and testing database definitions, data and code. Database schemas can be kept under source control and used to manage controlled updates of databases. Data can be compared across databases, for example to check that staging databases have the same data as a master database. Unit tests can be written to check that the functionality provided by your database actually does what it is supposed to. This chapter will cover each of these mechanisms. Static Code Analysis Syntactically correct code that passes all the compiler checks may still have issues that need to be resolved. If best practices weren't employed then code may not perform well, may not be scalable or may not be secure. Such code is an accident waiting to happen later on in the project lifecycle. For this reason, code needs to be reviewed. Visual Studio 2005 Team Edition for Software Developers has a rule-based code analysis tool built in that allows code to be reviewed early and often during development thus saving time and resources later on in the project lifecycle. This module shows how to effectively use code analysis, and explains how it is an integral part of the build process, how it integrates with aspects of Visual Studio Team System and how custom rules can be written and deployed to enforce the coding discipline in place for your organization. Dynamic Code Analysis Just because code compiles that doesn't necessarily mean it will perform well. As developers are notoriously bad at guessing where performance problems lie, profiling can help identify them more accurately by gathering data about an executing application and providing alternate 'views' of it to aid the detection process. This module shows how to use the code profiling tool integrated into Visual Studio 2005 Team Edition for Software Developers. It explains how to profile code in various application types, explaining how it supports the two most common profiling techniques - sampling and instrumentation - and de-mystifying the various analysis views of the profiling data in order to effectively isolate performance problems. Day 4 Functional Testing of Web Apps Many developers build web sites using ASP.Net and testing these is just as important as testing other code. Microsoft provides a tool to allow testers to create functional tests of web-sites by recording the actions the testers take. Once the script has been recorded a tester can then modify the script to test that specific 'rules' have been followed. In this chapter we will examine how to setup up the environment to perform this testing; how to record the script; how to modify the script by applying rules and how to re-execute the script to re-run the tests against the web site. We will also examine how to apply data-driven testing to web testing. Load Testing Test sites have to work well under large loads, and it is often impossible to tell from the code exactly how a web site will perform under load. VSTS provides a load testing tool that allows a tester to simulate many users running many requests against the web site. The load test can consist of unit and web tests, each being run many times by the load test tool. Load tests consist of a 'scenario'. A scenario will contain a number of users, the mix of test to run, the mix of network connections that a test should uses and a mix of browsers that the users of the site could use. A load test can also specify the test pattern so that different types of load testing can be carried out. VSTS also provides the ability to create a load test rig, this will consist of a load test 'controller' and one or more 'agents' with each agent running a number of tests. Building Code: Team Build On a large software team, it is often desirable to set up a public build environment where builds of the whole project are executed upon some trigger, such as may happen with continuous integration or with a nightly build. This module investigates how the Team Build component of Team Foundation Server manages public builds. It shows how the VSTS Team Explorer can be used to set up different build configurations on different build servers - all version controlled using the VSTS version control repository - and how builds can be executed on demand. It goes on to explain how builds can also be executed in response to a variety of triggers (e.g., source code check-in), how build configurations are integrated with MSBuild and can be tailored by normal MSBuild customization techniques and how Team Build is integrated with the rest of Team Foundation server, in particular how the results of different builds are available via VSTS reporting.