At the recent SharePoint Saturday Austin, I spoke with a peer who was working with a client that didn’t have a development environment, only a production environment.
“No,” I said. “If they don’t have a separate development environment from their production environment, they don’t have a production environment, there is only a development environment.”
A very common way to design a SharePoint ecosystem that protects end users from harmful alterations or interruptions to access to their data is to have three SharePoint farms – Development, Staging and Production. Changes are made to the development environment, moved into the staging for validation to make sure it won’t cause problems before ever being allowed into the production environment. Another common configuration has only two farms, with both development and testing in one farm, and production in another. This requires less maintenance and hardware, but can result in a testing environment that may be a poor match for the production environment (though it beats not having a production environment!).
But the nature of SharePoint is a collaboration platform. This means that changes are being made to production environment by end users. End users often have the rights to change page layouts, add and remove web parts, and do many other things that make alterations to the production environment. While there are built-in features to provide data stability, such as document versioning, approval workflows, and publishing processes, it does point up the slippery slope of what counts as “development” and what doesn’t.
Here is one of the approaches I have used to keep some control of the kinds of changes that can be made directly in production without prior validation, and what needs to go through a defined testing and promotion process.
Things that can be created in production, without going through the defined testing and promotion process:
- New pages.
- New documents and list items.
- Modification to pages involving addition, reorganization and removal of web parts, or the editing of content.
- Changes using approved templates, such as lists, libraries and sites.
Things that are required to go through the defined process:
- New web parts.
- Custom development.
- Changes to master pages, CSS and other design elements.
- Changes to templates.
- Patches to operating system and SharePoint.
The Defined Testing and Promotion Process:
- Changes are made to a development environment.
- If the development environment is a single-server farm (for instance, a local virtual machine) and the ecosystem also had a multi-server development farm, the developer must push the changes to the multi-server development farm and verify the solution before given approval to promote to the Staging Farm.
- Approved changes in the development environment are promoted to the staging farm for User Acceptance Testing
- Approved changes in the staging farm are promoted to the production farm in a manner consistent with minimizing impact to users.
Does your environment have a defined testing and promotion process? Do you allow some of the things I have identified as “development” to occur in your production environment? Are you more restrictive than the guidelines I have set? Do you even have a production environment?
What is your experience?
Get Notified! Scroll to the bottom of the page to get notified when new posts are added to the site!