Re: Application "deployment" tool?
- From: Tim X <timx@xxxxxxxxxxxxxxx>
- Date: Wed, 07 Jan 2009 11:07:33 +1100
Jeremy <jeremy0505@xxxxxxxxx> writes:
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
.
- References:
- Application "deployment" tool?
- From: Jeremy
- Application "deployment" tool?
- Prev by Date: Re: index skip scan
- Next by Date: Re: When should one rebuild an index?
- Previous by thread: Re: Application "deployment" tool?
- Next by thread: The duration of one single oracle job
- Index(es):
Relevant Pages
|
