Deployment strategies

Today, one of our self-developing customer, invited me to give them a helping hand on their environment and review their deployment strategy. Actually I was quite impressed by the way they are using their expertise to deploy Sitecore in a proper way. And it isn’t only Sitecore. Although just Sitecore itself is tough enough.
For example: It has dependencies to database servers. The webserver and cms-server might be splitted. With several config-files the development has become easier, but the change management did become more complex.

Anyway, the guys did a good job. Best practices I’ve seen back at their work:

  • Simplify by just numbering the steps that should be taken for a single server(For webserverXX take step 1, 3.2 and 4)
  • Provide as much screenshots as possible
  • Describe used modules independent of Sitecore

Tips I gave those guys:

  • When you write down full config-nodes, make sure your document will be shipped together with the module-files you are using. Also, write down the versionnumber.
  • Make sure the document contains links to the original installation guide(in case of you forget something) and notice the executor that the release notes of a product(both the cms as the module) can be changed.
  • Do not underestimate the installation of the modules. Several modules(for example the staging module) have very strict installation procedures, most of the time more complex then the cms’ itself’s.
  • Last but not least, provide a fallback scenario.

That’s it for today. It has been quite the past weeks because of tons of work and some days off…(Take a holiday in Spain ;), for a few days, I can recommend it!). From today, hope I’m able to do some daily blogging till the start of 2007.

One thought on “Deployment strategies”

  1. go daily blogging!

    i want to do the same, but i think my reality at the moment confines me to a one-post-per-week, right now it’s so hectic and stressed it’s mad.

    One thing to maybe add to the list of deployment guidelines could perhaps be making sure that everyone knows of any ‘known issues’, but then again, that’d also fall within a ‘fallback scenario’ to know how to fix/rollback/re-deploy..

    personally i believe the biggest problem in a deployment is validating the entire installation/deployment. for many it can be a rushed job where deadlines are breathing down their necks, and at times i’ve seen people make the mistake of validating on the development environment and then pushing it live without fully testing it..

    but hey, we all live and learn, and i can’t say i’ve never ever done that myself 🙂

    P.

Comments are closed.