Working with cloned instances

On a number of occasions, we’ve worked with projects where the product eventually was to be cloned and pushed out to a number of instances/sites, with differing degrees of variation.

Working with this kind of a setup introduces a number of pitfalls, with potentially hours of wasted time and frustration. This post will outline some tips for working with cloned instances and hopefully save you some time and pain.

Perfecting the prototype

Working with clones usually involves working on a prototype up until a deadline, perfecting this and getting as close to final before cloning it out to a number of instances. The object is to get the prototype as close to the individual cloned versions, so that basic elements don’t have to be redone for every instance. In other words, the aim is to save time. But if done wrong, the result could be wasted time.

Work on the prototype for as long as possible

Resist the temptation (or pressure) to deploy the instances until you are confident the master is done. The client may be in a hurry (they usually are), so be sure to communicate that pushing the prototype before it’s done will likely mean extra hours pushing and fixing individual instances.

Don’t rush changes

Avoid the tempation to push minor changes to all instances before you have the client’s final approval. You may have made an update that works and is robust, but the client may have more changes before approving the push to all instances. If you’ve rushed ahead, you’ve not only wasted time pushing to all instances, but now have to spend more time rolling those changes back.

Clarify costs to the client

Make sure the client gets two prices for all updates/changes: One price for the single update, and one price including deployment to all instances. This can make a high estimate easier to swallow, when the client sees the connection between pushing an update to multiple instances.

Don’t delay changes

Just as you shouldn’t rush the deployment of changes, you also shouldn’t delay synchronizing changes once you have final approval. A few times we were forced to put updates on hold midway, and by the time we came back to updating it was difficult to tell which instances were updated and which were not. Consider that other changes may be happening to the instances, and the push process becomes complicated accordingly. And besides, if you find yourself having to keep track of various versions of instances, then you have likely defeated most of the benefits of cloning instances!

Structure updates

Don’t underestimate pushing an update – even a simple update to 5 instances can quickly require all of your attention. Make a todo todo list, i.e. a table in word or excel with blank space at the top of each column and one instance pr row. Print this out and use for every update you push. Write the update at the top of the column and cross off each instance as you finish it. This will make it much easier to keep track of which updates are pushed to which instances.

Maintain uniformity

Push to keep each instance identical under the hood, even if it means giving an instance an update that the client doesn’t want want to pay for. You will make this up in time saved keeping track of versions.

Automate updates

If your platform allows it, consider implementing an update function that automatically pushes updates from a master site to the other instances. This can cut a lot of time and be worth it if you anticipate many updates.