MVP
28 Apr 2009

The current version of SharePoint (Windows SharePoint Services 3 and Microsoft Office SharePoint Server 2007) delivers a powerful collaboration platform. It also offers excellent customization capabilities through configuration and custom code. This customization and configuration be done at a system level through server based installations, but also by power users through the web based site management and administration UI.

The power, ease and accessibility of customization in SharePoint encourages a quickly growing and diversifying collection of sites, through manual changes applied directly in the production environment. However this poses several big challenges for release management on SharePoint platforms, specifically:

  • How to deploy and test new functionality through DTAP (Development, Test, Acceptation, Production) environments
  • How to make new or changed functionality available on existing site instances
  • How to handle content staging

Based on Macaw’s extensive SharePoint project experience, we have developed a strategy on how to address these challenges.

Deploying new functionality through DTAP environments

The key to DTAP-enabling SharePoint is to create automatic setup packages that leverage SharePoint’s built-in deployment technologies. Standard SharePoint solution packages (.wsp files) can carry content files, XML definitions and executable files.

In the Macaw Solutions Factory new functionality is implemented using SharePoint Features and (when needed) code. The Factory then automatically generates a WSP file, which in turn is embedded in a ZIP file, together with automatic (PowerShell) installation scripts. This ZIP file is also known as a MAST package (because it is based on the Microsoft .NET Architecture Style which is at the heart of the Factory).

In the development environment these deployment packages are generated; each package contains all information needed to deploy the relevant components of the solution on any machine in any environment. No user input is required.

The same (binary) package then travels through the DTAP environments, being deployed and tested for approval at each stage:

This approach has been used for years in many projects, and has proven to effectively DTAP-enable SharePoint solutions (as well as solutions based on other Microsoft server products).

Note: there are several series of Macaw Solutions Factory posts, on multiple blogs.
You can use this feed to track all Factory posts.

Maintaining existing site instances

The above Factory approach works well for deploying new functionality for new sites. However since at its heart the Factory leverages the standard SharePoint deployment mechanisms, this approach is limited to what type of changes can be deployed through these (XML driven) mechanisms.

E.g., a key XML structure in SharePoint is the Site Definition. Through Site Definitions you can make functionality available for new sites that will be created based on that new site definition. However, once a site has been instantiated, the SharePoint XML driven mechanisms do not allow you to modify the functionality defined by that XML. Changing a Site Definition after it has been instantiated does not modify the existing site instances, and doing this is unsupported by Microsoft – even when you only want to adjust new sites that will be instantiated after the Site Definition modification.

But there is an alternative: code that accesses the SharePoint object model can change any aspect of sites that are already instantiated. The idea is that to change functionality on (selected) existing sites, you do not write new XML features and site definitions for new sites. Instead, you write a piece of code that upgrades a site instance from version N to version N + 1. Then you automatically chain together all relevant updates to make the latest functionality available on any site.

This idea follows the same pattern as the well-known Continuous Database Integration (CDI) strategy (which incidentally is also used in the Factory for SQL Databases): you write small pieces of code that bring the functionality from version N to version N + 1; the tools do the rest.

Based on this idea, Macaw created the Site Management Tool. Like the other tools in the Factory, this approach is a combination of an implementation style (write upgrade code instead of XML definitions) with tooling to manage and automatically deploy the functionality to existing sites. The nice thing is that the same approach also works for new sites, so a specific piece of functionality only needs to be implemented once – either in standard SharePoint XML if no existing sites need to be upgraded, or in upgrade code otherwise. The SMT is itself implemented as a custom site in SharePoint:

The SMT offers considerable flexibility in controlling which updates will be applied to which sites at which moment:

  • Which updates: the SMT allows you to define Update Profiles, which in essence is a set of changes grouped together. A site can be assigned multiple Update Profiles.
  • Which sites to update: the SMT allows you to specify a Site Definition, a URL start or a part of the Site Title for each Update Profile, to select which site instances will be updated. In addition you can specify advanced logic in custom code to determine which sites to upgrade. So you can do this based on type of site, the area in your intranet (e.g. for a department), the site topic (a word in the Site Title) or custom logic:
  • When to update: It is possible to have new sites, that are based on site definitions that you control, receive the relevant updates when they are created (this works with an update feature stapled to the site definition), to have updates distributed through scheduled SharePoint jobs, and on demand from the SMT site.

Schematically the SMT operates like this:

Like with CDI, this coded update approach does not allow automatic rollback or downgrade of functionality to a previous version if the data involved originates from the production environment.

However in our experience, in the rare cases that the rollback opportunities offered by standard SharePoint backups (site backups and database backups) are not sufficient, you can accomplish an downgrade by writing a specific new update to reverse the effects of the previous one.

The Site Management Tool is DTAP enabled by using the Factory to build the upgrade classes. The upgrade classes are then incorporated in the MAST package and are deployed throughout the DTAP environments, allowing the updates themselves to be tested before they are applied in production.

Content Staging

The last challenge is how to handle content staging in combination with a DTAP approach. Although not all SharePoint solutions require content staging, it is often unclear how to integrate content with the other types of changes deployed to a SharePoint solution.

Macaw’s approach to realize this is based on two choices:

  • Have a separate staging environment that is treated as a second Production environment from the DTAP perspective
  • Perform automatic content deployment from the staging environment to the production environment through the built-in SharePoint Content Deployment technology.

This effectively means that the production environment receives updates from two sources: content packages from the Staging Environment and functionality (MAST) packages via DTAP.

Conclusion

With these three major release management challenges addressed, Macaw feels confident that large SharePoint installations with a rich variety of quickly changing functionality can be effectively maintained.

 

Vincent Hoogendoorn

About the Author
Vincent Hoogendoorn is a hands-on .NET architect and a Xamarin cross-platform mobile veteran, Microsoft Most Valuable Professional in Developer Technologies, and works as lead mobile @ Workstreampeople. His areas of interest are Augmented Reality, Cross-Platform Mobile Development, Windows Azure, Solution Architecture and Software Factories.

Leave a Reply


*

captcha *