Share via

Walk the walk that you talk - PART 1

  • Article

So many times you hear "Don't do this in production!  Do this in your Dev or Test environment".  More times than not, the "Dev" or "Test" environment is the developer's laptop or some spare machine that they have lying around the office.  This might be OK if you are testing the functionality of code, but that is about it.  If you plan on deploying these things you should have an environment that closely mirrors or at least mimics your production environment.  Here's two reasons why:

A) What you deploy may act differently in production because of components that don't exist in your "Dev" or "Test" environment

B) What you deploy may act differently in production because of infrastructure constraints or design that do not exit in your "Dev" or "Test" environment

Talking about developing or testing in a "Dev" or "Test" environment (henceforth and forever called PPE (for Pre-Production)), is a little like riding in an airplane and listening to the safety message that the flight attendants give.  Everyone knows the rules, everyone understands, but how many really do it?

We all know that it is Best Practices to have a PPE, yet many (indeed, probably MOST) do not.  There are a myriad of excuses as to why a PPE does not exist in one's environment: costs for additional hardware, labor costs in maintaining the environment, space constraints, lack of expertise in setting up an environment...the list goes on.  In this first of two segments, I will address what it takes to set up a fully functional and robust PPE.  I will address an overall design, and its goals (the what and why).  In the second segment I will address the technical details (the how, where).

PART I

The current process for developing and launching custom solutions for the SharePoint platform is extremely inflexible. Developers are limited in their ability to test custom solutions in an environment that looks and feels like production. Instead, they test in an isolated environment built and maintained on their own platforms, are subject to an inflexible release cycle that doesn’t allow for quick corrections, and may be required to wait an extended period of time to for their solutions to be installed to production due to maintenance windows. All these items can lead to sub-standard code deliverables, introduction of risk to production, and an expensive and timely process. One step to mitigate these issues is to create a Pre-Production Environment (PPE).

The PPE provides an environment mirrors production without actually hitting production and introducing risk.  You should ensure that this environment meets the same standards as production and has the same network connectivity as production.  This environment, in essence, is the last quality gate prior to deploying any solutions to production by allowing the developer to:

  • Validate functionality
  • Verify solutions with simulated production data and data connections to ensure proper communication
  • Providing actual users access to custom solutions
  • Verify compatibility with their own existing custom solutions

This environment could be configured or supported for the actual development of customized code or the undertaking of functional testing, or it could be used for performance, scalability or stress testing.

When creating a PPE, you should come up with a design that answers the following questions:

  • What are the goals/non-goals?
  • How does the PPE get managed and by whom?
  • Who will document its use?
  • Who will maintain and monitor the PPE?
  • Will the PPE scale?

Creating a Design document for your PPE is a good start.  It puts a plan on paper (or at least virtual paper) that can be followed.  We architects are notorious for not documenting...(what's wrong with us?)  The document should outline the answers to the questions above and the method in which they will be answered.  In the next segment I will include a sample of a document that outlines a design.

The first thing you need is an understanding of the importance of having a PPE.

The next thing you need is the documentation on how it will look and behave and how it will be managed.

The next thing is what we will talk about in PART II..."How to set it up" and the process of moving from PPE to Production.

Comments

  • Anonymous
    January 01, 2003
    Using SAN replication and Code and Content Deployment when things go to UAT (User Acceptance Testing) are great ways to keep things in sync.

  • Anonymous
    January 01, 2003
    Ah...and the cost? Remember, cost was one of the reasons people don't do PPE.  If cost was not an issue, all datacenters would be twice as large as they would simply double hardware footprint. In my next segment, we talk about options (SCVMM is one) and how to implement them.

  • Anonymous
    March 16, 2008
    Why not use the P2V wizard in SCVMM to make virtual machine copies of all your production machines and run the PPE as VMs?

  • Anonymous
    August 16, 2009
    All good points Rick. I call mine "staging" and find average people relate to that word well.   The matching we try to do on both hardware and software as close as possible and make environment comparison part of our quarterly engineering review (along with security, performance, and capacity). The trouble I've had is software deployment.  We're trying to require scripts for all changes.   It takes time and requires developer staff time but helps us matching and even support (anyone can deploy now). They'll never be 100% for the simple fact they are independent systems but we should all strive to get continually closer.   =)