Essential Application Lifecycle Management for Developers (ALM) Training

Visual Studio 2010 and Visual Studio Team Foundation Server 2010 help software development teams successfully deliver complex software solutions. Learn how Visual Studio and Team Foundation Server enable you to enforce best practices for software development and to develop better quality software. This course uses the latest versions of Visual Studio and Team Foundation Server.

You'll get answers to these questions:

• How can I create and manage a complex software project?
• How can I develop and manage tests?
• How do the Visual Studio visualisation tools help with source control?
• How do I test complex applications using mocking and Inversion of Control?
• How does the build server help with agile development practices?
• How can code contracts be used to improve code quality?
• How do I debug problems that arise during acceptance and quality testing?
• How do I use the Microsoft Patterns and Practices Unity IoC container?
• How can I enforce policies and business practices across the project?
• How can I automatically do a build when a developer checks in code?

• Use Team Foundation Server to enforce software development best practice
• Learn how to configure Team Foundation Server to support different software methodologies
• Employ test-driven development to produce robust code
• Harness the power of source control
• Learn how to manage testing and how to track bugs
• Design, develop and version databases with Visual Studio and Team Foundation Server
• Use Team Build to automate builds and to prevent bad code from breaking the build
• Use Team Build's continuous integration features
• Use code contracts to improve code quality
• Use IntelliTrace to debug errors that occur during testing
• Use mocking to test code that has external dependencies
• Use an IoC container to provide dependency management

Day 1
Introduction to Visual Studio and Team Foundation Server
This module presents an introduction to Microsoft's Team Foundation Server, a platform for integrating and managing all aspects of the software development process. It provides an overview of the Visual Studio client application and the Team Foundation Server, discussing how and where each feature fits into the software development lifecycle and how it pertains to each project role.

There is also an introduction to project management with Microsoft's Visual Studio. In particular, this module shows how project managers can use Team Foundation Server to create and manage a software development project. It talks briefly about project methodology and about how different methodologies are supported by Team Foundation Server. As well as discussing how to use the Team Explorer tool to manage the team project, it also explores how to integrate other related tools commonly used by project managers today, such as Microsoft Excel and Microsoft Project.

This module also talks about how Team Foundation Server uses process templates to represent the core information about these methodologies and how these process templates can be customised. 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.

Introduction to Source Control
Source code control, or version control, is the management of revisions to pieces of information that make up a project. Many applications make use of source code control to manage their source code, documentation, project data and any other information that a project requires. Team Foundation Server includes an enterprise-class source control system, entirely separate from Visual Source Safe (Microsoft's previous source control offering). A Team Foundation Server team 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 database set up during the installation of Team Foundation Server.

Project members can perform various actions on the source control repository, and in this module 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 checked out data. A given client may have multiple workspaces, this allows the clients to check out different parts of the repository into different workspaces, allowing clients (for example) to work with multiple versions of the code. Check ins are atomic and each check in creates a new changeset.

A changeset is a snapshot of all the files in the folder at the time this change was committed and each changeset is given a unique Identifier. Users are able to check out the latest version from the repository or they can check out a specific changeset. Changesets can also be labelled and users can check out a given labelled 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 Source Control Explorer, although Team Foundation Server supplies a command line tool called TF.exe, which is also discussed.

Branching, Merging and Shelving
One of the features that Team Foundation Server 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 team. 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, a process called merging. Team Foundation Server also introduces a concept that is new to source control, the idea of shelving. The concept behind shelving is that while a developer is working on changing code, they may be 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 checked out by the person that created the shelveset, or by another user. Shelves are useful in many scenarios during the lifetime of a project and will be looked at in detail. Finally, this module looks at how check in policies can be tailored by writing and installing custom check in policies.

Day 2
Team Foundation 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 Team Foundation Server Team Explorer can be used to set up different build configurations on different build servers, all version controlled using the Team Foundation Server version control repository, and how builds can be executed. This module covers how to schedule builds and how to use the continuous integration features of Visual Studio Team Build. It also explains how builds can be executed in response to a variety of triggers (for example, source code check in), how build types are defined using Windows Workflow and how they can be customised to suit the project's requirements.

Managing Databases with Team Foundation Server
Enterprise developers use databases constantly and these databases can become very large and often unwieldy. Visual Studio provides tools for designing, developing, managing and testing database definitions, data and stored procedures. 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 module will cover each of these areas.

Day 3
Test-Driven Development and Unit Testing
In recent years, unit testing has become recognised 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 module, we will examine how Visual Studio 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 Visual Studio, in particular looking at the attributes that are used when defining a test case and how to write code to determine whether 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 initialise the test. Visual Studio 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. Visual Studio can generate stub code to test private methods. This module will look at the generated code, and at how to use it within the test project. When testing it is important all code is tested, but how does a developer know that all of the code in a project has been exercised? The answer is provided in the next module!

Data-Driven Unit Testing, Code Coverage and Impact Analysis
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 Visual Studio 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 representing a different test case. In this module, we will show how to create the database, how to specify the table and the 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.

Visual Studio offers the ability to instrument code to show which code has been executed and which has not during the testing. In this module, we will show how to configure test settings to execute the code coverage engine in order to determine which areas of code need improved testing.

Related to this, Visual Studio has the ability to work out which tests have been affected when code is changed; this is called Test Impact Analysis. This module covers how to use this so that only tests that are affected are rerun, thereby significantly reducing the amount of time spent testing with no loss of test effectiveness.

Dependency Injection and Inversion of Control
Inversion of Control is a mechanism that allows components in a software system to be very loosely coupled. It is achieved by configuring components to use a dependency injection container. This is vital if you want to be able to test code effectively.

In this module, we will look at the latest version of Microsoft's Inversion of Control (IoC) container, Unity. We will examine how to best use the container through configuration and through code.

Doubles and Mocking
Sometimes when testing code you have to be able to replace complex parts of the system under test, such as a database. In this module, we will look at using Moq to help us do this. Moq supports various styles of mocking, from letting us create stubs to letting us return data and creating dynamic mocks to ensure certain calls are made. We will couple the mocking tools with an IoC container to understand how to create good unit tests.

Day 4
IntelliTrace
Applications go wrong! When you are developing code and something goes wrong, it's very easy to run the code under the debugger and to look for the error.

There are also tools that allow you to do post-mortem debugging, i.e. to help debug applications that crash or hang when actually running on a user's computer.

IntelliTrace provides a missing link. What happens when applications go wrong when being tested by your QA or acceptance test department? Those teams probably don't know how to use (and don't want to learn how to use) the Visual Studio debugger. In addition, while WinDbg and friends are great for post-mortem debugging, it would be nice if we could gather more debugging information in such a controlled environment as our test environment. This is where IntelliTrace comes in; you can run the trace on a test computer and have it gather all the data necessary to run a full debugging session after the event.

Code Analysis
Syntactically correct code that passes all of the compiler's 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 it may not be secure. Such code is an accident waiting to happen later in the project's life. To avoid these problems, code should be reviewed. Visual Studio 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's life. This module shows how to use code analysis effectively, and explains how it can become an integral part of the build process, how it integrates with Visual Studio, and how it is possible to develop custom code analysis rules that can be deployed to ensure that your coding best practices are followed.

Code Contracts
Visual Studio introduces Code Contracts to the .NET development world. Code contracts let us provide pre and post conditions for any method in our code, as well as class invariants. Code contracts can be checked at runtime, but more interestingly, they can also be checked at compile time. This provides an extra level of insurance for our code.

This module looks at how to install the tooling for code contracts, how to write code contracts to set up pre and post conditions and at how to use code contracts to their full.

Upcoming Dates & Locations