How many RedPrairie environments should we have?

This is a common issue that we have to deal with for any project. There are no absolutely right answers but there are some wrong ones:

• Having a single production environment
• Having multiple environments for WMS-online but a single archive environment.
• Having multiple environments for WMS-online but a single parcel environment

So as long as you have separated production environments, that is better than nothing. A good start may be:

• Development
• QA
• Production

And do not take the secondary environments like archive and parcel lightly. You should have a parallel environment for these as well.
There is need for additional environments but before I discuss that I want to clear one myth that a RedPrairie environment is hard to setup! Given that you have an installation, for example dev environment; setting up an additional environment from same code-base is trivial. Exact steps will be:

1. Copy the database to the new environment
If you have kept the database free of environment-specific data then this can be completely scripted.
2. Thats it - because code will already be the same as the other

With that myth busted, now we can consider some additional environments which will come in handy:

Environment	Use code from	Purpose
Test	Development	The development database is generally not a good place for testing the code for even the developers. So this environment will offer them a place where they will have good data to test with. If you have only a few developers you probably do not need this.
Train	QA or Production	Before go-live you probably want this based off QA but after that to train the workforce you want this based on Production source code. This environment will typically have pre-configured exercises and data.
Debug	Depends	The important part is that production database is exported and imported to another place nightly. This will help in diagnosing hard to reproduce issues. Then based on specific needs you may point it from development code, QA code, or production code.

Conclusion

Development, test, and production is a good start but if we understand that if we setup the database free of environment specific entries and understand that new environments can be created very easily from existing environments then these other environments can come in handy. These additional environments do not need to be permanent rather you can bring them online on as-needed basis.