How do you guys upgrade the DDL of your apps?

Question

This is to start a brainstorming discussion, just like the one you would have between DBAs and developers around the watercooler...
I am considering revamping the way DDL upgrades are done in-house.  I was wondering how you guys go about doing that, whether you are an Independent Software Vendor or the developer for an in-house application.
if you're an ISV, how do you supply and implement new versions of your DDL to your customers?
if you are responsible for the development/maintenance of an in-house application, how do you carry out your DDL upgrades?
I would like your responses to be around the methods and the tools you use to upgrade the SQL code (mainly the DDL) of your applications.
Looking forward to everyone's input.

Answer 1

In a modern application, a developer should seriously consider Edition Based Redefinition (EBR) - a feature (comes with the database)  every customer has since 11g R2.  With EBR, have the ability to install new versions of your code (plsql, triggers, views, synonyms -etc) in the database without impacting (blocking, locking, overwriting) the existing version.  So you can install version 2 of your application while version 1 is still running.
Additionally - taking it a step further - if you put editioning views in place (a special kind of view that allows you to only select from a single table, no where clause, just a select list - sort of like a synonym with a select list), you can achieve many online DDL upgrades as well.
for example, let's say you wanted to add a new index to a table, change the format of an existing column from number to varchar2 (to allow for alpha-numeric values in the future) and drop an existing column that is no longer needed - you could (assuming the editioning views are in place):
a) create a new edition as a child of an existing edition.  It'll be as if you copied all of your code/synonyms/etc - you haven't, but it will feel like it
b) add a new column of type varchar2. (this column will NOT be visible to version 1 at all in any way)
c) put in place a forward edition trigger that will take any modification of the existing number column and reflect it in the new varchar2 column
d) use dbms_parallel_execute to update the existing number column to itself ,this update can commit every 100 rows or so (no locking issues really) and will cause the new varchar2 column to be populated for all existing rows.  any new rows added by version 1 of the application will automagically be reflected
e) in version 2, create a new editioning view that selects out the right columns from the table (don't select the number, select the varchar2 and alias it as the old column name if you want)
f) put your new plsql/synonyms/grants whatever in place in version2
g) create an invisible index on the table you wanted to index - you can do this online.  the index will be invisible so it won't affect ANY existing query plans (you haven't tested the old sql with it - you just know that version 2 likes having it)
Now version 1 is running and version 2 is ready to go.  Easiest way to roll out would be to schedule a tiny maintenance window - alter the databases default edition to version 2, make the index visible and restart your app servers.  the are now running version 2
a) drop/set unused the old number column
b) get rid of the forward edition trigger
if you'd like to read more about this:
A Closer Look at the New Edition
Ask Tom: Edition-Based Redefinition, Part 2
Ask Tom: Looking at Edition-Based Redefinition, Part 3
and of course
http://docs.oracle.com/database/121/ADFNS/adfns_editions.htm#ADFNS020
tom kyte