The Old Joel on Software Forum: Part 4 (of 5) - Multiple applications, one database. Processes?

Multiple applications, one database. Processes?

What is the best way to put things in production without affecting others that are currently in production when using the same database (oracle)?

Example:

System 1 is in production.
System 2 is also in production.

System 1 is going to promote new changes to production.

System 2 isn’t ready for production, but has made changes to oracle packages that will be included in System 1’s promotion, because they share packages.

So if System 1 goes to production, System 2’s changes will be pushed up as well, even though they are untested thoroughly.

Solutions:
** Push items to production on set days (3rd Wednesday of the month, etc.), and all changes up to that point must be tested 1 week before hand

** Use source control to house the Oracle packages once they are out of QA to push to Stage, then production

** Have developer comment out the untested changes

** Some action that I don’t even know about
** Some combination of the above

What do you think?

Surely this isn’t a unique problem

Thanks in advance.

Charley Bogwill
Wednesday, April 7, 2004

This is one solution,

You say these two applications share their database, does that mean they share the instance but have separated schemas, or do they both live in the same schema?

As I understand it, you would need to create 4 new schemas in your oracle instance:

APP1_OWNER -- App 1 specific stuff
APP2_OWNER -- App 2 specific stuff
SHARED -- New shared stuff (App 1 promoted)
OLD_SHARED -- Old App 2 packages.

Install the shared packages in the SHARED schema; and the application stuff in the respective APP schemas. Then you can use private synonyms in the private APP schemas to point out the correct version of the code.

As APP 2 gets more and more tested you can drop the private synonyms and recreate synonyms to point to the SHARED schema.

This way you can transparently (to the apps at least) have different versions of the code running at the same time.

Or am I missing something?

System 1 is going to promote new changes to production.
System 2 isn’t ready for production, but has made changes to oracle packages that will be included in System 1’s promotion, because they share packages.

So if System 1 goes to production, System 2’s changes will be pushed up as well, even though they are untested thoroughly.

Patrik
Wednesday, April 7, 2004

System 2's untested changes should not go into production. Very bad idea.

DJ
Wednesday, April 7, 2004

When you are making System 1's changes, make it so they are backward compatible with System1's existing functionality.

That's the only real answer you have. We do this all the time.

i.e. if System 1 and System 2 both reference a stored procedure X, and you need to add a parameter to stored prcedure X for System 1's changes, make another stored procedure Y. In the current release, you will have both stored prcoedure X and Y out there.

In a future release when System 2 ships, you can have it reference stored procedure Y as well.

I'm not familiar with Oracle, but I am familiar with SQL Server. Does this help at all?

Rick Watson
Wednesday, April 7, 2004

Sounds to me like App1 and App2 are not separate unless you can separate their database changes into app1's mods and app2's mods, and these don't conflict.

I reckon you need to deploy all three (apps & db) as a versioned and tested unit. Or separate the db changes, and version/test/release app1 & db-mods, then later app2 & db-mods.

If app1 is dependant on some of app2s db-mods then you've got one system (with 2 apps).

Tim H
Thursday, April 8, 2004