No Downtime Deployments

Question

No Downtime Deployments

Steve Jones - SSC Editor

SSC Guru

Points: 734459
More actions
July 25, 2015 at 11:29 am

#302797

Comments posted to this topic are about the item No Downtime Deployments

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply

Jeff Moden SSC Guru Points: 1003867 More actions · Answer 1

WWWWWHHHHUUUUUTTTTT?!?!?!?! You mean to tell me that ORMS don't auto-magically handle all of this? :-P;-)

And the final comments in that article are only partially correct. If the process allows for "temporary fixes", then the process is wrong. If the process allows for "old code" in production, then the process is wrong. There are processes to allow for "urgent" fixes to quickly make it to production but the need for such urgencies also means that the original process for promoting code is also flawed.

And, any "process" that doesn't include "people" is also inherently flawed. Yes, people can make mistakes but if you really want to gum up the works quicker and more broadly than humanly possible, you need computer driven processes that don't involve people. 😉

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Steve Jones - SSC Editor SSC Guru Points: 734459 More actions · Answer 2

I'm not sure the process is wrong if bugs or issues get into production. It could be as simple as a bug not caught. However the first thing that should happen in quick fixes is that you write a test of some sort to catch the bug. Then code a fix and test it to see if the test passes.

Promotion of the code quickly only works well if you are in fact testing. The whole idea here is all the old tests run as well, so you try and prevent regression bugs.

Gary Varga SSC Guru Points: 82166 More actions · Answer 3

Steve Jones - SSC Editor (7/27/2015)
...Some of these changes are due to the inherent design of a database system. If I change a large amount of data, that takes a physical amount of time, which can slow down, or prevent access to, a table. If I want to provide a forward and backward compatible system, I may end up with triggers and copies of data that are maintained in multiple places. This could make an deployment quicker, but at the expense of more resources needed for my workload every day...

There is current thinking that deployment is a one shot job. I tend to disagree. Sometimes it is appropriate to have a multiple staged deployment. Sometimes these stages can be some time apart. Sometimes it may require an application to be upgraded before the next stage occurs. Duplicate data and functionality should not exist (in an ideal world - maybe that is the issue) and should be resolved over time and not a lot of it.

Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!

Steve Jones - SSC Editor SSC Guru Points: 734459 More actions · Answer 4

I agree with you, Gary. So many people want this simple, and it's not. Many of the complex migrations in Oracle (column splits, drop column, etc), often have triggers to move data and then a reminder to remove the trigger at a later date, perhaps even a year later.