Team-Based Development in SharePoint Server 2007

Summary: Learn to properly conduct team-environment development of Microsoft Office SharePoint Server 2007 sites and assemblies (Web Parts, site templates, custom list templates), as well as develop Microsoft Office SharePoint Designer artifacts (master pages, workflows, CSS sheets). (13 printed pages)

Eric Charran, Microsoft Corporation

April 2007

Applies to: Microsoft Office SharePoint Server 2007, Microsoft Office SharePoint Designer 2007

Contents

• Overview of Team Development in SharePoint Server 2007

• Anatomy of a SharePoint Server Solution

• Conclusion

• Additional Resources

Overview of Team Development in SharePoint Server 2007

Organizations that select Microsoft Office SharePoint Server 2007 to meet the needs of collaboration and Web presentation business solutions often must supplement the built-in functionality of SharePoint Server. These modifications can take the form of feature enhancements and can include development of Web Parts, custom workflows (designed using Microsoft Visual Studio and based on Windows Workflow Foundation), Web controls, and custom list and site templates. Alternatively, other types of modifications can include branding—a process by which the organization changes the visual appearance of the SharePoint Server Web application and implements custom navigation, modified look and feel elements (by using custom master page design and style sheets), and images—and integration with back-end line-of-business (LOB) applications, and implementation of custom workflows designed by using Microsoft Office SharePoint Designer 2007. These two types of development tasks are differentiated by classifying the former as assembly-based development and the latter as artifact-based development; however, the method a single developer uses to approach his or her development is much different from the approach a team takes to collaborate and develop a SharePoint Server solution.

Similar to traditional ASP.NET or Windows Forms development, a single developer often has the flexibility to control all aspects of the project. While a single developer can employ source control as a best practice, the team dimension of development is not present. When attempting to conduct team development, however, you require a valid source control system, along with coping and an understanding of locking, versioning, workspaces, and other concepts related to shared development. Enterprise source control products, such as Microsoft Visual Studio Team System and Microsoft Visual Studio 2005 Team Foundation Server, provide an excellent and scalable environment that allows for the holistic coordination of team development efforts.

However, with solution development in SharePoint Server, the aforementioned types of development often are outside the normal considerations for a team's traditional application development. Enterprises must consider and attempt to construct a team-environment model that accommodates the requirements for SharePoint Server application development.

Anatomy of a SharePoint Server Solution

To construct a valid team model for development using the SharePoint Server platform, you must understand the types of SharePoint development that team members share. SharePoint Server includes both assembly development and artifact development. As shown in Figures 1 and 2, assembly and artifact development contain separate types of entities, outputs, and actions. As such, each demands a different approach to development, especially for a successful collaborative team development effort.

Figure 1. Assembly development

Figure 2. Artifact development

The use cases for assembly development and artifact development begin with the types of outputs generated by their respective design environments, and govern how the team addresses them during solution construction.

Assembly Development

Assembly development for SharePoint Server is similar to traditional application development. In this branch of solution development, developers use Visual Studio 2005 to create various assemblies that are registered with the SharePoint Server Web application (and alternatively placed into the global assembly cache). These assemblies function as an extension to a Web application. Assemblies can take the form of Web Parts (essentially, ASP.NET 2.0 Web Parts) or other shared libraries that can service other assemblies. Assembly development encompasses solutions built using the Visual Studio 2005 Extensions for Windows SharePoint Services and includes custom list definitions, site definitions, and a specific SharePoint Web Part project type. For more information about the Visual Studio 2005 Extensions for Windows SharePoint Services, see the download for Windows SharePoint Services 3.0 Tools: Visual Studio 2005 Extensions.

Assembly development for SharePoint Server is directly compatible with traditional models of team development. Recently, team development for the Microsoft .NET Framework and other Microsoft technologies has migrated toward a model that supports collaboration and development by using isolated development environments. Developer code changes are combined through a common source control repository and build process. For more information about the team models for software development, see Microsoft Solutions Framework Team Model and Team System.

While the concept of team modeling and roles are beyond the scope of this article, the specifics of outlining a typical team member’s working environment and the overall assembly development process for SharePoint Server are shown in the following figure.

Figure 3. Recommended assembly development environment configuration

Individual Development Environment

The diagram in Figure 3 outlines the proposed configuration for individual assembly development on the SharePoint Server platform. Conforming to the team model of collaborative development controlled through island workspaces, the developer’s local computer environment uses virtualization technology to facilitate development against an authentic SharePoint Server instance. In this configuration, the developer actually conducts solution development within the Microsoft Virtual PC running SharePoint Server 2007. Developers must have their own virtual computers running SharePoint Server 2007 to use during application development.

The interaction between the development environment and the source code repository takes place from the within the virtual computer. For the purposes of this article, Microsoft Visual Studio 2005 Team Foundation Server is regarded as the source control product of choice for the development process, but can easily be replaced conceptually with Microsoft Visual SourceSafe.

This configuration provides the developer with a SharePoint Server 2007 server to conduct development, deployment, and testing of assemblies (such as Web Parts, SharePoint Server object definitions, and so on), without interrupting or infringing upon the efforts of other developers working on the overall solution. An alternative configuration is to maintain a SharePoint Server 2007 virtual computer and conduct coding within the developer’s physical computer (the host with respect to the guest SharePoint Server 2007 virtual computer). Developers can then choose to deploy to their own SharePoint Server 2007 virtual computers. This configuration requires that the SharePoint Server 2007 virtual computers maintain network access. Additionally, in the depicted configuration, the virtual computers must have the Visual Studio Team System Team Client installed and be able to connect to the Team Foundation Server.

After the development environment is established, Team Foundation Server workspaces are created locally and collaborative development can begin using Team Foundation Server as the centralized source control and work item tracking platform. The development team can collaboratively engage in test-driven development, implement agile Microsoft Solutions Framework methodologies, and work toward developing a common set of assemblies for SharePoint Server solutions while preserving the integrity of its own isolated development environment. This configuration allows for maximum independent productivity while preserving a single code base using Team Foundation Server.

Assembly Deployment Model for SharePoint Server

The assembly deployment model for SharePoint Server is based on taking assemblies from a build environment, packaging those assemblies into a release vehicle (Microsoft Installer or SharePoint Server solution), and installing them on an integration environment where the various bits are tested. The following figure outlines a process in which the release manager takes a build of the assemblies and migrates them to the integration environment.

Figure 4. Integration server deployment process

The integration environment is one in which the SharePoint Server structure and taxonomy ideally mirrors the configuration of the developer’s environment. The release manager installs the assemblies into the shared integration environment. This environment provides a place for integration and systems testing. In this environment, each assembly is tested to ensure that it not only passes the required unit tests, but also integrates correctly with other assemblies developed as part of the SharePoint Server solution, and operates as expected within the SharePoint Server environment.

The strength of SharePoint Server solutions as a deployment vehicle is the fact that they can be installed on a server farm and then deployed automatically to other farm front-end Web servers. A SharePoint Server solution is cleanly installed and managed (uninstalled, deactivated, and so on) using Central Administration. However, you can capitalize on Microsoft Installer (.msi) files to provide custom installer actions and process wizards that can address very complex installation requirements.

The diagram in Figure 5 shows the migration of code directly from a developer’s SharePoint Server 2007 environment. In this diagram, there is no build server to pull code from and the assumption is that the developer’s SharePoint Server 2007 environment is the release manager’s workstation. This diagram assumes that the release manager pulled the documents from source control against a label, and is using his or her local computer as a manual build and package environment.

In a more refined and process-driven team development environment, Team Foundation Server can be used to conduct the check-out and build process, as depicted in the following diagram.

Figure 5. Integration server deployment process using a build server

In the model in Figure 5, following the check-in of the assembly code into Team Foundation Server from the developer’s virtual MOSS environment, a lead developer or other team member reviews the check-in and labels the project.

During a nightly build (or continuous integration) process, the source code is checked out, compiled using the Team Foundation Server build server capability, and deposited in a network share that is available to the release manager. Optionally, during each build process, the build server can execute a specified set of tests established during the build server configuration for this team project. At this point, the release manager can choose to package the build output using the desired vehicle and deploy it to the integration environment for testing.

Artifact Development

The development of items relating to the look and feel of a SharePoint site often relate directly to the development of items such as master pages and style sheets. These objects are considered artifacts in that they are not typically compiled and deployed as assemblies. These artifacts are characterized as content items that fit into the SharePoint site structure and that are applied at run time for the SharePoint Server site. The primary tool to create and manage these artifacts is Microsoft Office SharePoint Designer 2007. While Visual Studio has capabilities to assist developers in the creation and modification of these items, Office SharePoint Designer has new design-time tools and capabilities to help in the authoring and rendering of the artifacts so that their appearance during design time is extremely similar with the way the items will look after they are published and deployed.

The challenge with these Office SharePoint Designer artifacts is to determine the best method to conduct team development, testing, and deployment. To address this challenge, you need an understanding of the development model for SharePoint Designer and the differences between artifact and assembly development.

Differences between Assembly and Artifact Development

One of the primary differences between assembly development and artifact development is that SharePoint Server contains a facility for built-in source control as part of its Web publication and approval functionality. In contrast, assembly development relies on an external, server-based source control environment. The functionality in SharePoint Server provides source control-like functions that allow content approvers to visually inspect a site and its changes before they become visible to the user community. This functionality is considered traditional content development.

It is critical to understand that content development is very different from traditional development. While content development contains changes to pages, styles, master pages, and layouts, as well as changes to site content itself, the place in which these changes are made actually should be construed as a production environment. The organization provides the ability to conduct content or artifact development within its live environment and approve or reject changes, or the organization specifies whether an authoring environment is provided that sends content to a production environment. In both cases, the hardware and environments in which content is developed is considered production (that is, production content development environments for business users to develop and deploy content and a production content rendering environment).

For SharePoint artifacts, these items are considered content. They are stored within the SharePoint Server content database and are subject to publication and approval. Because these items are considered content instead of programmable assemblies, you can make observations about the team development process with regard to items designed by using SharePoint Designer. The following diagram depicts some of the differences between content or artifact and assembly development.

Figure 6. Assembly and artifact development process distinctions

Figure 6 shows the two-dimensional process of overall solution development for SharePoint Server. The vertical assembly deployment process is depicted by the movement of code (assemblies developed in an isolated environment according to the process of team development) as it is compiled, packaged, and deployed between development, integration, and production environments. The horizontal process outlines how the production of content occurs on production-classified hardware. Where assembly development is literal environment migration between specified server environment boundaries (physical development, integration, and production servers), the development of content is more logical and can even take place within a single production SharePoint Server environment.

In Figure 6, content developers, using SharePoint Designer, create master pages, alter and create style sheets, develop site content, and even create new pages. Because this is all content authoring, the draft and finalization of the changes (the development) go through the SharePoint Server Web content publication process. This process can occur within a single production environment. Alternatively, and as shown in Figure 6, the approved and published content and SharePoint Designer artifacts can then be deployed automatically to a view-only production environment via a content management path established between the two environments.

Based on these differences, the following guidance can assist in the organization of team development regarding SharePoint Designer artifacts and other content.

During the SharePoint Server solution development process, establish an authoring environment where the following is possible:

• Content developers can use SharePoint Designer to create and modify content (master pages, custom pages, style sheets, and so on) within a mirrored site collection that actually represents the production environment.

• Authoring activities make use of SharePoint source control and publication features.

• Content developers have the ability to modify the existing production environment and conduct publication using a content management path to the production Web farm.

• A production-class environment is provided by the authoring environment, such that all assemblies, Web Parts, SharePoint Server solutions, and structural changes that are deployed to the production Web farm are also deployed to the authoring environment.

• The authoring environment can exist within the production environment as the SharePoint Server Web content publication feature provides a level of abstraction between proposed changes to content and approved changes.

• From a team perspective, the shared authoring environment is more effective than individually separate authoring environments.

• SharePoint Designer artifacts do not need to be integrated with enterprise source control.

• Enterprise source control (such as Team Foundation Server) should be used strictly for assembly development in a team environment, while the effort to integrate content management items into source control is not a supported process.

• Attempts to integrate items into enterprise source control that are considered SharePoint Designer content items and part of content development require extensive workarounds involving manual processes and procedures.

• Items built into SharePoint Designer as content are subject to the Web publication process of source control, approval, and publication.

Use content management paths to publish SharePoint Designer changes to production environments.

Make content management paths the primary vehicle of choice to send content designed with SharePoint Designer between authoring environments and their content counterparts.

While import and export of site content to .fwp packages from SharePoint Designer achieve the same function, ensure that content management paths present a less procedural and more reliable method of moving content between SharePoint Server environments.

A significant difference between assembly and artifact development relates directly to how the physical coordination of multiple developers conducting simultaneous content development is achieved. The guidance to establish a single authoring environment for multiple content developers is particularly significant. The reasoning behind this concept is that the migration and merging of master pages, style sheets, and other content objects can be extremely problematic. SharePoint Server does not have a direct method of conducting merges between these objects, as they are considered content, not code. Additionally, moving these items among multiple authoring environments is extremely difficult to manage and coordinate for multiple team members. Thus, a single authoring environment where multiple content developers can use SharePoint Designer to create and publish content simplifies time spent in migrating content artifacts from separate environments into a production environment.

The direction to avoid integrating content artifacts with enterprise source control is a significant departure from assembly development as well. The requirements of accommodating these items by extracting them from the SharePoint Server content database through SharePoint Designer and including them in source control would be overly procedural and subject to error. Manually compiling the items in source control though inclusion in a Visual Studio project requires intensive procedural planning and discipline to follow, and does not represent the intended design-time experience for SharePoint Designer content development.

Conclusion

This article describes how organizations that invest in Microsoft Office SharePoint Server 2007 often require the ability to develop and deploy highly customized Web presentation and collaboration solutions for internal and external presentation. These solutions can require much new functionality in the form of Web Parts, custom lists, and site templates, as well as a significant level of branding and integration with back-end LOB applications. Organizations must consider several issues when approaching development of these solutions in a team-based environment to ensure that development happens properly. By understanding the differences between the types of development that teams use to produce a customized experience for SharePoint Server 2007, you and your organization can take advantage of team development patterns and practices for the best in productivity and quality. Understanding the specific set of patterns around assembly-based development can allow team members to capitalize on the existing techniques around source control, builds, deployments and other traditional application development techniques. For content design and publication, a single authoring environment—in which multiple content developers can use SharePoint Designer to create and publish content—can simplify time spent in migrating content artifacts from separate environments into a production environment.

Additional Resources

• Microsoft Office SharePoint Server 2007 Developer Portal

• Microsoft Solutions Framework Team Model and Team System