On 4 December 2015 at 11:19, Christopher Schultz < ch...@christopherschultz.net> wrote:
> Kevin, > > On 12/3/15 2:21 PM, Kevin Hale Boyes wrote: > > Thanks for this link to the presentation. > > How do you all deal with some of the other dependencies that the web > > application has? > > > > For example, if v2 of my application needs new database columns or > worse, a > > change to an existing column how can I have v1 and v2 running at the same > > time? We use Oracle as our database though the problem exists for many > > database servers. > > That's not a deployment problem. That's a design problem. > > In short, you need to make sure that your web application is both > forward-compatible and backward-compatible at the same time. > > That's rubbish, or course. Here's a more concrete suggestion, and it > requires a LOT of work, but it's worth it. > > First of all, you can't think of a release as a single event any more. > Instead, there are 4 events. > We already do this sort of development when needed. In particular, when we have database changes that will take a long time like back populating new columns or creating new indexes on large tables, we run then in a pre-release phase against live production. We time the activities to finish just before our release window. Sometimes we also have post-release database activities as well that follow shortly after our release outage. I guess I hadn't extended my thoughts far enough and seen the full potential of the idea so thanks. One drawback for us when we use this mechanism is related to our release schedule. We release on a quarterly basis so having a process that spans four releases pushes it out for an entire year. But that's our problem and we're making headway there too. Thanks Christopher Kevin.
