Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I think you have an impossible problem. You can make it halfway work, but then it will all the way break. And when it does, you'll have a thousand messed up machines. Good luck fixing it.

    The right place to start your question is asking how the release cycle works. Hopefully you have a development/QA/production cycle already. In that case I'd use the QA step as your useful bottleneck to make this problem tractable.

    Developers in development can do whatever they like. That includes messing up their development machines. But when they check code in, they must include unit tests for new database features, and they need to document database changes. Part of preparing a QA release is preparing the upgrade procedure that merges all of the database changes that were documented. It must be able to take an old installation and upgrade it to a machine that can pass all unit tests (and also passes QA).

    After that, then your job is to write a procedure that can take a machine down, apply the upgrade, then put it back into production.

    The nice thing about this is that now you don't need to worry about the locking issues (that's now a procedure problem), and you also can limit your worries about developers directly breaking production (they shouldn't touch it).