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.

Note:
Developers can choose to run Virtual PC 2007 or Microsoft Virtual Server 2005 R2.

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.

Note:
To conduct authenticated access to Team Foundation Server resources, the virtual computer containing the individual developer’s SharePoint Server 2007 environment might need to be part of the same domain as the Team Foundation Server, or alternatively the virtual computer can belong to a special domain with trusted relationships to the domain that contains 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.

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.

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.

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.

Note:
Ideally, there is a testing and code coverage analysis review prior to labeling the team project for build and deployment.

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.

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