Re: pl/sql code maintenance

Ed Prochak <ed.prochak_at_magicinterface.com> writes:

> Tim X wrote:
> >
 

> 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.)
>
> > 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.
>

I tend to agree. The 3 branch solution was not my preferred approach, but rather one proposed by another developer who had used a similar setup with his previous employer.

CVS does support labels and you can have labels associated with different branches as well as different versions. We would have labels for dev, qa and production which are associated with different branches. There are some advantages of a multi-branch approach, but I need to do a bit more investigation and testing before I'm convinced the advantages of a multi-branch approach actually outweigh the additional complexity.  

> 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.
>

Yes, CVS does support embedded version IDs - I think its pretty much the same as SCCS. In fact, at the moment, I'm looking at ways of providing standard templates which everyone will use when creating packages which will always include a function which returns the ID of the code module. I've been doing this with my own development for years - using emacs as my main dev environment makes this very easy to setup and maintain. Unfortunately, I'm the only one who uses emacs and linux to do my development - everyone else uses w2k and TOAD. The only reason I'm allowed to use emacs and linux is because I'm a blind developer and the combination of the emacspeak speech system and the linux speak up provide the best and most reliable screen reading/text-to-speech environment for development I've found. With emacs, I have reliable and simple integration of templates, CVS and other very useful tools. TOAD does appear to support templates, but I've got to work out a mechanism which will allow all developers to utilize the same templates (e.g. via a mapped drive). It also appears to support 3rd party version control, but thats something I have yet to fully investigate.

At this stage, all I know for sure is I'm not giving up until we have some form of version control happening. My second goal is to have everyone using standardized templates and hopefully a standardized codeing policy which we currently don't have. My final goal is to try and get everyone sharing code and reducing the amount of time wasted developing code which already exists somewhere else in the system - as an example, last week I found no fewer than 17 different bits of code which generated fixed field width data files - 17 bits of code doing almost exactly the same job which could be replaced with a generic package that would only need to be developed once and reduce maintenance by removing the 16 other bits of code. this probably seems logical to most, but where I'm working has never had any policies, procedures or guidelines in this respect and all developers currently act as if they are their own little world - its a total mess. One of the systems we maintain has thousands of tables and views which have been created over the last 7 years by various developers who have left and nobody knows what they are for - the use of temporary tables has been rampant and documentation is pretty much non-existent.

I have a tough road ahead trying to change the habits of the last 7 years, but a good challenge always makes work more interesting and the days/years go faster!

Tim

-- 
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you 
really need to send mail, you should be able to work it out!