I am trying to analyze blue green deployment strategy to provide zero downtime upgrades for our customers. We have an enterprise java based monolithic web application that uses Oracle as the data store. There are a few challenges that I would like to get expert inputs

  1. With every database object types (procedures, tables, indexes, constraints etc) we need special handling, most of them are stated here. This ultimately requires fine code handling for each and every use case.

  2. With blue green deployments, how do we handle active user web sessions? Do we detect session close events?

The implementation effort for such an approach needs time (approximately an year as the post suggests) and fine care to make sure we get it right. Are there simpler and better alternatives to this?


  • 4
    Looking at the first link, your real question #1 is: "there is a procedure for RG deployment for MS SQL. Is there an easier one for Oracle?" Honestly, that is a question you should better ask on dba.stackexchange.com, there are the experts for such DBMS specific questions. But make sure you don't crosspost, so I would recommend to edit your first part out of the this question and keep the second one here, before you ask the DBAs.
    – Doc Brown
    Commented Dec 22, 2018 at 7:08
  • I get your point. I wasn't clear in my question. I wanted to ask for better alternatives to the overall approach. I have now re-framed the question. Commented Dec 24, 2018 at 4:04

1 Answer 1


Load Balancer

For the second point, use a suitable load balancer. You can shift a portion of the traffic across, first to prove the new deployment, then to slowly ramp it up. It also allows a quick backout strategy.

Database versioning

There are two ways to go about this:

  1. Make the Authoritive Data-form (the SQL schema) backward compatible between Green/Blue versions (any older version of the schema/procs/etc can be ditched/deleted/dumped).
  2. Move the Authoritative source of the data elsewhere, and treat the SQL schema as a dynamically updated view. Simply rebuild that view on each deployment with all procs/schema/etc have a version prefix of some kind.

In the first method, it might make sense to distance your application from the data-representation and move all data transfer via the stored procedures. This ensures a clean interface that can be ported forward. This allows the migration path to be like:

  1. Create new types/tables, and add-only new columns to current tables, perform any cleanup of the old version.
  2. Deploy stored-procedures that can handle new and old data structures. Read all, write new.
  3. Perform data migration and massaging essential to the new deployment.
  4. Swap traffic to freshly deployed application.
  5. Perform any extra data migration and massaging to port to the new data structure.
  6. Either wait for a newer deployment, or deploy stored-procedures that can handle the new data structures only.
  7. if not waiting perform cleanup of old data, stored procs, tables, etc...

If this sounds too complex, or performs manipulation on live data is too dangerous then moving the definition of what is authoritive to another data source may be what you need. With this it no longer matters what is in the sql data store (unless it is storing the event log in which case except that part). Deployment now looks like:

  1. Create new schema, stored procs, types, etc under new namespace or with a prefix.
  2. Scan the event log from the earliest record, update the schema as is relevant.
  3. Once mostly caught up, slowly switch traffic to the new deployment.
    • users on the old deployment can still interact with users on the new deployment, both are reading the event log and receiving updates.
  4. When happy that everyone is on the new deployment, and no rollback is required, stop the old system.
  5. delete the old schema, procs, etc...

Your application will have to double enter the data, first on the event log, then it will need to read the event log and update the associated table data. On the plus side this will allow several versions of the product to work together for a time at the cost of extra work.

  • If I understand it correctly, the first approach is same (or similar) to the one I mentioned in the original post, right? I don't understand the second approach - "dynamically updated view". Do we need to maintain two schemas and synchronize them some how through event logs? Commented Dec 24, 2018 at 9:35
  • @Andy Dufresne Essentially yes. But pedantically you are updating any given schema with the state-change/event log so that anyone browsing the log could answer the same query by looking at the schema, only faster. This way you can have N schemas for however many different version of the program you wish to maintain. As no version of the program can contain data not present in the log, you can abandon any given schema at any time. The caveat is that for a state change to occur, the program must first add a log message, then each running variant must update its own schema with that change.
    – Kain0_0
    Commented Dec 26, 2018 at 22:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.