Something that really irks me is my companies decision to clone production environments, and distribute these clones to create new environments. So, lets say a new project starts up and they want a replica of one of our databases - a request is made to the DBA, he takes a snapshot of production and puts this snapshot on the new target host. He/she then does a series of search and replaces for environment specific variables and then hands over the new environment.
You may be asking whats my problem? Well, here they are:
- When you clone, you take everything; configuration, structure and worst of all data.
- The process involves around 3/4 people and takes about a day.
- Garbage in, garbage out - whilst production is the only "truth" when you molest it with search and replaces who knows what you're getting?
So, what solution did I offer?
As we're talking about the database I shall start with that. Firstly, a database is no less important than application code and so should be version controlled. Once the source code is version controlled you can use tools such as dbdeploy to build your database in a repeatable manner. I'm a firm believer that no live data should exist outside of production or the disaster recovery. If you cant generate test data for the scenarios you will encounter then your test strategy is not sufficient.
What happens when I want to retain data?
In a data retention environment such as User Acceptance, we only ever want to apply deltas to the DB not refresh it every time - well, dbdeploy handles this very well.
Cloning isnt all bad..
I think the cloning strategy has some value - version controlling your database will not suffice in a disaster recovery scenario because the most important part - the data - will be missing. I wholeheartedly agree with the cloning strategy in this scenario.
0 comments:
Post a Comment