Re: Application "deployment" tool?

> With multiple databases (all Oracle 10gR2) and a single version of
> application code (pl/sql plus css, images etc - it is a web
> application)) can anyone suggest any good tools for managing the release
> and "build" of each database we have to upgrade? Ideally somthing that
> ties in with SVN would be fantastic.
>
> If not can anyone point me to any good resources for "best practise" in
> managing software upgrades?
>
> Many thanks
> jeremy

There isn't a 'one size fits all' answer to this one. It depends on your environment and how things are managed. However, a few points which may be worth consideration -

1. Keep it simple. Too often, I've come across complex approaches that just fail because people forget or are just too lazy and don't do what they should. If new developers can't get up to speed and start being productive in the first week, then things are probably too complex.
2. I've found best results having at least three environments - a dev environment, a UAt/QA/testing environment and the production environment. No code should make it into the production environment that has not been tested in the dev and uat environments. Testing should be documented and signed-off on. The documentation should be reviewed when bugs are found so that testing procedures can be improved. We have found peer review extremely useful and productive. For this reason, we don't allow any code to be promoted into production that has not been peer reviewed and we try to make sure that different people handle the promotion between the different environments - this helps to ensure knowledge regarding how things hang together is spread amongst multiple people and not just invested in one key person and it helps to ensure the documentation and instructions are clear.
3. Have an efficient and reliable mechanism for doing a 'backwards refresh', that is, be able to take a snapshot of your production environment and refresh your dev/uat environment so that it is an exact snapshot with only those things that must be changed, such as db links, passwords etc changed. Depending on your environment, privacy issues etc, it may be necessary to 'scramble' some of the data, but only do this if there is a proven business case.
4. Definitely use some sort of version control. Subversion is fine, but pretty much anything will be better than nothing. We use sub version and create a release tag when new code is bundled up for promotion to uat and then production. If you find a bug in the code once released into production, create a new branch from the tag, fix the bugs and promote that into uat then production. Later, merge the branch back into the trunk. This allows you to fix bugs in released code, but at the same time allows developers to continue working on new features etc.
5. Use a bug/feature request system. Many are available and many provide integration with svn. We currently use products from Atlasian (a wiki and a bug tracking tool - the wiki is used for documentation).
6. Have a standardised way of promoting new code into production. Originally, we just had a few scripts and a web front-end that created a build script that would check out a particular version from svn (based on the release tag) and run a basic install script. However, as we have moved to more java based applicaitons, we have adopted an 'ant/maven' approach to this, which appears to be working well - essentially, its a Makefile on steroids with lots of XML bloat - not really my cup of tea, but all the java fans seem to like it and its not just good for managing java code. As it gets the job done and seems to cross all the t's and dot all the i's and most importantly, the developers we currently have seem happy to use it, then I'm happy. having a dedicated and standardised way to handle code promotes also facilitates documentation and hence tracking of changes - we can see who did what over a long period of time and this can be very useful - it is especially useful when reasons for certain decisions have been forgotten or you have had enough staff turn-over that sufficient corporate knowledge has been lost that nobody knows for certain why some decisions were made etc. Note however, don't get too caught up on a flashy all singing and dancing automated promotion system. Requirements are likely to evolve faster than you can maintain a dedicated promote application - to some extent, you need to find that middle ground where you have something very flexible and stright-forward, but doesn't become a maintenance overhead in and of itself. Keep it simple and add features only when there is a proven case.
7. If your application and environment lends itself to it, I would recommend having a dedicated nightly build system - currently, for the app I'm developing, I've got an old linux box running 10gR2 and a set of perl, SQL and sh scripts that do a complete build of the database, packages etec every night. The code is all checked out of SVN from the trunk. This does mean that we will frequently get build failures as the trunk code is the dev code, but it also means that we are less likely to miss something important which is configured on the developers desktop or in their dev envrionment and which has not been put into SVN. We have found this is also really useful when it comes to adding new people to the team - everything they need is on this little server, so all we need to do is clone it and they have an environment to start working in. Its also a handy semi-neutral envrionment where we can test OS upgrades and even some Oracle patches etc and as I have complete control over this box, I can often test/try things faster as I don't need resources from the data centre or DBAs. The server isn't even server grade hardware - its an old DELL desktop, but this is fine for small little experiments and for checking that everything the system needs has been correctly put into svn etc. As its small, dedicated and cheap, I don't have to worry about it being pinched for temporary 'critical' business needs, battle for funding to maintain it or even justify it - it just sits int he corner and most forget its there.

HTH Tim

-- 
tcross (at) rapttech dot com dot au