How many steps do you need to perform to release a new version of your software? Do you even know?
Releasing frequently requires the release process to be as streamlined as possible. A good way to get started is to write a step-by-step instruction that explicitly state everything that needs be performed for an installation or upgrade.
Then get to work cleaning it up:
- Make sure you can build and package everything that’s needed for the installation with a single command
- Does the installation or upgrade require several files to be installed? Bundle them in a ZIP-file, MSI-installer or RPM. If you’re installing to an application server, find out how to script deployment to your particular server.
- Does the installation require files to be copied, moved, linked or otherwise managed? Provide a script that automatically executes the necessary actions
- Are there dependencies that you assume are already installed in the environment? State these explicitly, or even better, internalize them, to reduce variation
- Does changing the database schema require a separate step? Why not bundle database changes in the application and execute them as part of the startup-procedure? (see my blogpost on database migrations)
Most projects can get down to upgrading the system safely by executing a single command. But as long as upgrading is a manual and complicated procedure, it is risky to release frequently. Clean up your release process to make it foolproof.
Good post, especially when combined with the database migration post.
The more I think of it, the less I like automatic schema upgrades. The safety (/security) implementations are, eh, no good. For instance, it requires the applications to have schema modification privileges in the database, which is not a good thing (ref http://xkcd.com/327/ ).
Automated upgrades would, however, be a huge benefit, especially if integrated with the general management of the application. I think the following scenario describes what I would like:
$> ./install.sh com.mycompany.sales sales-app 1.3
…. downloading…..unzipping…..installing….OK!
$> ./operate.sh restart
…stopping….OK
…starting….
…blah-blah-blah……
ERROR: Wrong schema version ‘1.2’ : expected 1.3
$>./operate.sh upgrade
…upgrading schema from 1.2 to 1.3
… please provide db user name for upgrade [sales_app_schema_owner] >
… please provide db user password for upgrade [sales_app_schema_owner]>
…..upgrading schema ….
$> ./operate.sh start
(starts successfully)
Thanks for your comments, Eirik.
As your “upgrade” command implies, the “system” knows the username/password needed to modify the schema, even when another user is executes the business logic. You could, of course, do the same with automatic schema upgrades.
To your larger point: I think automated schema upgrades makes a lot of sense in some settings and controlled upgrades makes a lot of sense in others. Smaller projects where little money is a stake probably want automatic updates. Larger projects dealing with large monetary values may tend towards controlled upgrades.