Go to page: 1 2 3  Printer Friendly Version

One of the most common problems that organizations that are customizing SharePoint have is how do they manage the code deployment process. Organizations typically have configuration management guidelines that help them regulate how code makes it into production whether that's internally developed code or are patches that are applied to the operating system and products being leveraged.

The problem is that SharePoint doesn't fit a nice clean model. Because so much of SharePoint is configuration and data driven, code that works in development or a test environment may not work in Prod because things are configured differently or there's different data to operate on.

So how do you manage a situation where you've got configuration information that needs to meet up with code to create a complete solution? In this article I'll tackle this problem, a generic approach, and talk about a few of the sharp edges on the strategy that you'll have to educate everyone on.

A Simple View of Environments

In order to facilitate a discussion, let's assume that we have three formal environments:

Development -- A system integration environment where developers have (or potentially have) access to the servers and to the administrative controls. Some organizations call this environment the "Wild West" because it is only lightly under configuration management. This actually a systems integration environment where all code is forced to live together with test data before moving forward.

Quality Assurance (QA)/Test -- The Quality Assurance (QA) or Test environment is where the code from development and the content or a subset of the content from production comes together. This is the place where final signoffs are received prior to going into production. There might be multiple QA environments in an organization but for our purposes here they can be considered as once since they all live in the same space of configuration management. This environment is generally well controlled and follows a change management process - however, typically with fewer sign offs than the production environment.

Production --The tightly controlled production environment where the tightest restrictions on access are and where availability, reliability, and scalability are of paramount importance. This is the final resting place for code and in at least some environments is the origin for all content.

Content and Configuration Never Moves To Production, Only Away From It

One of the challenging, and powerful aspects of SharePoint is that the configuration of the system and the content for the system are comingled into a single content database. Because of that it's difficult to extract either the content or the configuration without bringing along the other. As a result, it's too easy to accidentally overwrite production content if you try to pull up content or configuration from another environment. As a result, the hard and fast rule is that content and configuration always move from Prod backwards through the environments to QA and if necessary to Development.

This isn't all that different conceptually from how organizations approach QA environments for other systems. It's common place to migrate production data, or parts of the production data, back into a QA environment to test changes to an application and run validation suites. The key difference is that with SharePoint the code and the content can be more tightly coupled than is common for most traditional systems. This always move from production approach isn't without its limitations not the least of which is what content to migrate backwards and what to do about required configuration information which is covered in the following sections.

Go to page: 1 2 3  Printer Friendly Version