Cleaning up the release process
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.
Comments:
Johannes Brodwall - Sep 23, 2010
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.
[eirikma] - Sep 22, 2010
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)