Re: pl/sql code maintenance

Tim X wrote:
>
> meinhfxGARBAGE_at_hotmail.com (tony) writes:
>
> > We have what is probably a typical development, test & production
> > set-up, ie., a separate box and database for dev, one box for both
> > test & prod each with separate databases. My question has to do with
> > how best to maintain code in all areas where there are several
> > developers / support people all working in each area. Since we can
> > retrieve the source from the databases it seems to me that there is
> > really no need to keep a current version of source thereby avoiding
> > the situation where developer a moves source from test to prod but
> > forgets to compile then developer b takes the source from prod back to
> > test to work on a bug. Pretty fundamental stuff, but how do you
> > handle pl/sql code?

your way is dangerous. Even with data base backups, you have no reliable way to get back to a known good version when a bug makes it into production! (How do you know last night's backup has the correct code? Canyou identify the code differences? not without two copies of the database you can't.)

> >
> Certainly not as relaxed as your senario seems to indicate!
>
> Actually, we are in the middle of analysis of our procedures at the
> moment. Currently, we have a similar setup - development and test box
> with different databases and a production box. When developers finish
> something, it is passed to the testers who evaluate and do qa. Once
> they are happy, the developer creates a "promote" job which specifies
> what files need to be moved to production and what scripts need to be
> run to perform the production. This job is handed to the DBA who is
> the ONLY person able to install new code into the production
> database. On a semi-regular basis, the development and testing systems
> are "refreshed" from the production system.

a good first step to a sane process.

>
> The main part missing from our process at present is some well defined
> version control processes. I've been pushing for something like CVS,
> but have been facing resistance from others who believe its not
> necessary because the code is stored in the database. My response to

[okay, you finally convince them that version control is useful.]

> We are thinking of adopting CVS with different "branches" for
> development, testing and production (possibly just
> development/production, possibly just production - not sure yet). The
> process could be something like
>
> 1. Production branch contains all code which is in production.
> 2. Development branch contains code which developers have completed
> and which is waiting for qa testing
> 3. Testing contains code which has been qa tested and is waiting for
> promotion to production.
>
> The main problem with developing good version control is making sure
> its not too complicated and that it is easily accessable to all
> developers, testers and dbas. If its too complicated or not easily
> accessibly, procedures whill break down - code not being checked in
> properly or developers/testers not working on the corect version
> etc. Possibly the only thing worse than not having some form of
> version control is working under the mistaken belief that everyone is
> using version control and the sources in the repositry are an accurate
> representation of your code.

So if you want to avoid complicated processes, why three branches? Does CVS not support some form of version labels? Development usually works on the latest code or checked out copies, QA works on versions labeled for a particular test release, and code promoted to production is labelled as such first. If you can't use labels, then a tracking table of source files and release versions that can be used to extract those versions of the code is easy enough.

 Does CVS have any way to have embedded version ID's in the code itself? (SCCS does this.) this is helpful in PL/SQL packages (and compiled executables) to include a revision ID routine which returns the package ID (name) and revision number.

The idea of three branches just looks more complicated than needed.

ED

>
> Rant over - not too hard to tell work is winding up here already :-)
>
> tim
> --
> Tim X.
> tcross (at) northnet com au

--
Ed Prochak
Magic Interface, Ltd.
440-498-3700(office)
Computer consulting, database and web services.