Team Development Overview

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

In many small to medium-sized organizations, small teams of SharePoint developers simultaneously work on the same application. In addition, many small teams can be concurrently working on different applications that have interdependencies. Organizations must find the appropriate levels of overhead and control that keep their SharePoint application environments stable and maintainable while also keeping their teams productive. These goals can be achieved in a variety of ways, depending on the governance requirements.

This topic discusses how the Training Management application was developed with a small team of three developers and three testers. The initial investment, both in time and money, to create stable development and test environments benefitted the project in the long term. The team used an agile approach to develop the application. They used Visual Studio Team System for source control, performing builds, testing, and work item management.

For information about end-to-end flow of an application from development to production, see Deploying and Upgrading SharePoint Applications. This topic discusses the process that the development and test teams use to develop and build the SharePoint solution package that is then deployed to the testing, staging, and production environments.

Figure 1 illustrates the development and build environments.

Figure 1
Development and build environments

The following describes the development and build environments:

• Stand-alone development environment. Each developer uses a stand-alone workstation. Each development workstation includes a running instance of SharePoint that is installed either directly on the workstation or on a virtual computer. This allows the code to be locally deployed and tested before checking it into source control.
• Source control system. The source control system manages and versions all files that are used in the development process, including source code, XML files, and resources.
• Continuous integration server. The Continuous Integration (CI) server performs builds on a frequent basis (the builds can be either time-based or event-based) and runs unit tests against the build. Unit tests run independently of SharePoint.
• Build verification test server. The build verification test (BVT) server performs builds and runs a suite of tests that exercise the application while running under SharePoint. It establishes that the application's basic functionality is correct. BVTs run less frequently than CI tests.

The Development Environment

The development team works locally to develop application logic and structures, as well as unit test cases. (The use of unit testing by developers is strongly encouraged.) Developers should synchronize their code with all the application items that are not checked out and ensure that all the unit test cases pass before they check in their code. After they are satisfied with their changes and additions, developers check in their changes to source control. For more information about setting up a local SharePoint development environment, see Creating a Development Environment.

Depending on your experience and approach to software development, how you define unit testing may vary. The agile development community considers unit tests to be isolated tests of code that have no system dependencies. The patterns & practices SharePoint Guidance team replaced SharePoint dependencies with objects that return the specific set of responses that are required by the unit tests. These replacement objects are named mock objects. The mock objects were developed with a third-party tool named Typemock Isolator. For more information, see the Typemock Isolator Web site.

Mock objects eliminate any dependencies on SharePoint for developing and running unit tests. The Training Management application includes the unit tests, which require Typemock Isolator to run, as an optional part of the guidance. For more information about unit testing with mock objects, see Unit Testing.

An alternative to mock objects is to write stubs, but this requires a significant effort for a complex object model such as SharePoint.

The Source Control and Build/Continuous Integration Environments

Source control is a necessity for any software development environment. It provides the integration point for versioning and for building the SharePoint solution between development and the succeeding environments. Often, build processes label the code to ensure reproducibility. The patterns & practices SharePoint Guidance team runs builds on both the CI and BVT servers. Both build processes label the code that is being built.

Although many organizations use a manual build and verification process, an automated CI environment is preferable. CI is popular with the agile development community. In conjunction with unit tests, it provides a rapid check on the quality of the code. The patterns & practices SharePoint Guidance team's CI process automatically builds the code when it is checked in and executes all of the unit tests against the build. In this example, SharePoint is not installed on the CI server. It has only the SharePoint assemblies that are necessary to compile the application. CI ensures that the checked-in code does not conflict with any changes made by other team members. It also reveals conflicts that occur because of unsuspected interdependencies that can exist between different projects. Continuous integration can also run on a timed basis, depending on your needs.

Although setting up the source control and CI environments requires an initial investment of time and money, there are clear benefits to using them. In particular, build and integration issues are quickly discovered and resolved. There are tools available to help set up a continuous integration environment. The patterns & practices SharePoint Guidance team uses Microsoft Visual Studio Team System 2008 Team Foundation Server Team Build. For more information about how the team uses continuous integration, see Using Continuous Integration. For information about Team Foundation Server Team Build, see Team Foundation Build Overview on MSDN.

The Build Verification Test Server

The patterns & practices SharePoint Guidance team builds and runs the BVTs on a separate server. Build verification tests exercise the application that is running under SharePoint and ensure that the baseline functionality works correctly before deploying the application to the next environment. BVTs can be automated or manual. Ideally, at least some automation is in place, although automating some areas such as user experience design can be costly. Like the continuous integration server, the BVT server uses the code in the source control system and builds the application. However, BVTs run less frequently than CI builds and they take longer to execute. The BVT process creates the SharePoint WSP, deploys it to a local SharePoint installation, and executes a set of automated tests.

The patterns & practices SharePoint Guidance team's automated verification tests are built using an open source tool named WatiN that runs browser sessions. (An alternative approach is to use Visual Studio Team System Web application tests.) If all the automated verification tests pass, the WSP is copied to a share for use by other environments, such as staging and production. Because BVTs run against the real application, they typically take longer to execute than unit tests. The Training Management application's BVTs take approximately 30 minutes to run. This is in contrast to the unit tests, which take only a few minutes. BVTs can easily take several hours with more complex systems. Because the team wanted timely feedback from the continuous integration process, they kept the CI server and the BVT server separate. For more information about creating an automated build environment, see How to: Create an Automated Build and Deployment Solution with Team Foundation Server Team Build.

Possible Alternatives

Many teams think that the CI and BVT environments are too costly. However, it is a best practice to institute some form of automation for building and validating code. It provides a way to detect integration conflicts early and ensures a minimum level of quality before sending the code to the test environment.

The patterns & practices SharePoint Guidance team performs builds using multiple build servers. Both the CI and BVT environments run their own builds. Isolating the environments from each other ensures that the CI builds can succeed without a SharePoint installation. The patterns & practices SharePoint Guidance team wanted to run CI without SharePoint as a proof point, but you can install SharePoint on your CI environment. In many cases, you may want to run all builds for all environments on one build computer.

CI relies on some form of unit testing, but there are alternatives to using mock objects or stubs. For example, you may prefer running unit tests against a live SharePoint installation. In the agile approach, tests that run against a complex system such as SharePoint are considered to be integration tests and would be considered part of build verification testing. Outside the agile community, such tests are often considered to be unit tests.

To develop tests that run against a SharePoint instance, you need to create setup and teardown logic. The setup logic creates the proper conditions on the SharePoint instance for your tests to correctly run. The teardown logic restores the SharePoint instance to a known state after the tests complete. There are both benefits and drawbacks to this approach. One benefit is that you are not anticipating SharePoint behavior with a mock object. Instead, you are testing against the actual behavior. Another benefit is that you do not require yet another software package.

One drawback is that writing robust setup and teardown logic is time consuming and difficult. Another issue is that the tests are more brittle. Finally, because the tests are complex and take longer to execute than unit tests that use mock objects or stubs, the delay between check-in and verification can be much longer.

You can consider the following simplifications to reduce the complexity of implementing a solution if you cannot invest in a complete environment:

• You can combine the CI and BVT processes on one server. In this case, be careful that the tests do not run at the same time because they may conflict. For example, if assemblies are being installed to the global assembly cache, running CI and BVT builds at the same time creates conflicts.
• If you do not implement unit tests and therefore cannot run CI, you can still set up automated builds to quickly identify when build-breaking changes that fail compilation are checked in by a developer.
• You can develop one process that integrates the roles of BVT and CI by developing integration tests (these are unit tests that run against a SharePoint instance) as part of an automated build. In the agile community, these are considered to be build verification tests.
• You should set up a build verification process, even if it is done manually. Deploying builds that are not functional can waste time and frustrate the test team with inoperable or conflicting solutions that are difficult to roll back.

Developing with Visual Studio Team System 2008

Assemblies and many types of file-based artifacts can be developed with Visual Studio 2008. Developers use Visual Studio to write code and build assemblies that are based on the Microsoft .NET Framework. These assemblies reside either in the SharePoint server Web application's bin folder or in the global assembly cache.

Solution artifacts mainly consist of assemblies and content definition files and template files. For a more complete discussion of SharePoint artifacts, see Defining Terminology in Deploying and Upgrading SharePoint Applications. Assemblies can include any of the following components:

• Web Parts
• ASPX pages
• ASCX controls
• Server controls
• Custom field types and field controls
• List event receivers
• List item receivers
• Feature event receivers
• Workflow activities
• Web services
• Timer jobs
• STSADM extensions

File-based SharePoint Solution artifacts are not compiled, and they reside in the file system. These artifacts include items that are customizable and items that are not customizable.

The following artifacts are not customizable:

• Site definitions
• Feature site template association
• Custom actions
• List template definitions
• List Instance definitions
• Web Part definitions
• Images(.jpg, .gif, .png files)
• Themes
• Client-side scripts (JavaScript or JScript)
• Field type definition
• Workflow template definition

The following artifacts are customizable and can be persisted in the content database:

• List definitions
• List template definitions(certain properties can be customized and persisted in the content database)
• Web Part pages (changes in an .aspx file through the SharePoint Designer or object model can cause files to be customized and persisted in content database)
• Master pages
• Cascading style sheets
• Content type definitions
• Site columns

Many file-based artifacts can also be developed with Visual Studio 2008 in conjunction with tools, such as Visual Studio extensions for Windows SharePoint Services version 1.2. Visual Studio extensions for Windows SharePoint Services provides useful templates for many types of artifacts such as content types definitions, list definitions, and site definitions. Including these artifacts in the Team Foundation Server source control makes them available to other members of the development team while controlling the code change and build processes.

There are other artifacts that are better suited to development outside of Visual Studio. This is particularly true of artifacts such as master pages that are considered SharePoint content. A useful tool for developing many types of artifacts related to content is the Microsoft Office SharePoint Designer.

Authored artifacts developed in SharePoint Designer can be exported to the developer's local file system. They then can be included in a Visual Studio solution (.sln file). Other types of artifacts can be authored in SharePoint by using the Web browser to access various SharePoint content. For example, after navigating to a SharePoint site, you can create custom lists by clicking Custom Lists on the Create menu. Items developed in SharePoint with the Web browser can be extracted with the SharePoint Solution Generator tool that is included as part of the Visual Studio extensions for Windows SharePoint Services installation. They then can be included in a Visual Studio solution (.sln file).

By maintaining both the assembly artifact code and file-based artifacts with Visual Studio Team System 2008, development teams have an environment that supports the entire development life cycle. This includes continuous integration and an automated build and deployment solution.

For more information about continuous integration, see Using Continuous Integration. For an example of how to create an automated build and deployment solution, see How to: Create an Automated Build and Deployment Solution with Team Foundation Server Team Build. For more information about using Visual Studio for SharePoint, see Team-Based Development in Microsoft Office SharePoint Server 2007 on MSDN.

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

To provide feedback, get assistance, or download additional, please visit the SharePoint Guidance Community Web site.

Copyright © 2008 by Microsoft Corporation. All rights reserved.