Go to page: 1 2 3  Printer Friendly Version

Partial Migration

Depending upon the environment size, the amount of testing resources, the type of content, and the sensitivity of the content, it may be impractical or impossible to migrate all of the production data back to QA. However, in other environments QA must precisely mirror the production environment all the way down to the data that's in use. Whether you choose to do a partial migration or a full migration doesn't impact the approach of migrating from production to QA - and potentially even back to Development if the information isn't sensitive. The rule is primarily that nothing moves to production. If you want to allow your QA environment to get out of sync with production data you can do that.

Required Configuration

Once of the most vocal arguments against this strategy is the problem of code and configuration aligning. Say for instance that I have code that requires that there be a new field in a list in SharePoint. The argument becomes how you get that new field in the SharePoint list and how does that meet up with the code. In most cases, the configuration can be made in production in advance of the code getting there. In other words, the new field can be added into production, but perhaps not have it visible to most users. A new list can be created with permissions so only the site administrators can see it. A whole new site can be created and hidden from the users if necessary. There are a variety of options that are all workable ways to get the configuration into production without impacting the look and feel of production for the users.

What's more tools can be developed to make these configuration changes. Whether they take the form of an additional feature with a feature receiver or are a command line tool that the infrastructure team runs, you don't have to configure things via the user interface just because you can. These tools can then be run in the development environment, again in QA, and when the time comes in production as well.

Initial Load

There's one possible exception to the rule of always copying content back from production. That is, the initial load of the system. While it's still not recommended that you roll forward the content database from development, a roll forward of the QA environment to production for the initial load can make sense if you've been treating QA as a pseudo production while the production environment has been being built or converted.

Code Always Moves from Development through QA to Production

To someone who's been doing configuration management the idea of moving code from development to QA and then once approved to production may seem like an obvious approach, it's not necessarily that obvious to someone that hasn't done configuration management - or has been loose in their practices. In addition to a semi-rigid approval process for code which requires a stop in QA and sign off that the code is ready for production, I generally recommend that all code be delivered as a SharePoint Solution package. The SharePoint Solution package, with a .WSP extension, can be atomically deployed to an entire web farm which makes it ideal for the identical delivery of code to QA and to production. There are only two steps for deploying code with a WSP - adding it to the solution store and scheduling the deployment. The ability to avoid a large number of manual steps means that there is less chance for error when moving to production and that's a good thing.

What is Code?

Code is all of the things that you can't do from the user interface or SharePoint designer. Developing web parts is obvious, as are the development of SharePoint Features. However, there are some situations where you'll convert content into code so that it can be universally applied across site collections in the farm. For instance, master pages, content types, and page layouts used for publishing are generally published via a Feature so they're code -- even if they're initially created in the user interface. Here's a list of examples that are always code: