What are the challenges you face when working across database platforms? Take the survey

Load Balanced environment - release strategy

Mike PullinMike Pullin Posts: 3
edited April 18, 2016 11:26AM in DLM Automation
Does anybody have a process/strategy for upgrading applications or databases in a load balanced environment please?
I am looking for a 'best practice' strategy in order to create an internal company high level process which details the order to complete the tasks required...for example: update databases before applications, roll-back actions, backups etc etc...


  • Options
    Hi Mike,

    It basically depends on what your requirements are. Assuming that you don't want any downtime and you don't want any breaking changes, then you release process would probably be something like this...
    • You have v1.0.0 of your application running as multiple instances and you are ready to release v1.1.0.
    • Firstly release the database changes that are compatible with v1.0.0 of your application so that it keeps functioning.
    • Deploy v1.1.0 into a staging environment, preferably a staging instance per each production instance.
    • When all staging instances for v1.1.0 are up and running, flip the switch on your load balancer (e.g. like HAProxy: http://www.haproxy.org/ or AWS ELB: https://aws.amazon.com/elasticloadbalancing/) to direct traffic to the staging instances. This is basically promoting staging to be production. Note that you don't kill v1.0.0 instances immediately here as you want the on-flight requests to be drained there. Here's a useful article on this concept: http://docs.aws.amazon.com/ElasticLoadB ... drain.html
    • When you are ready to release v1.2.0 you can clean up your database a bit to remove things that you kept around to make v1.0.0 happy, as it no longer runs.

    This deployment strategy can get more complicated if you have different needs such as canary releases, A/B testing, etc. So there is no generic approach that you can apply - it all depends on what you want to do. In terms of database deployment, you are doing so called fast-forward changes which doesn't break existing deployments. Changes such as dropping a column, dropping a table, etc. are not what you would want at all.

    You can also make this work for rollback scenarios. Here's an example: If you have just released v1.1.0 and it is not working as you expected, you can roll it back to v1.0.0 as it will work with the new database changes. 99.9% of the time you won't want to roll back the database changes unless you are OK with data loss.

    Here are some good resources on the topic -

    Additionally you might want to ask on the SQLServerCentral.com forums to see if anyone there has experience of what you are trying to do.

    I hope this helps.
    Software Engineer
    Redgate Software
  • Options
    Many thanks for taking the time to provide such an informative response. Your strategy looks to be something that we would look to implement, as it makes perfect sense to our SW Engineering Team.

    Thanks again for your help

    Mike Pullin
    Business Analyst
Sign In or Register to comment.