Go for it Tim! Sounds like you are on the right track. Biggest challenge I
see is getting the programmers to stop each being an island and be a team.
Good luck!
Jim
"Tim X" <timx_at_spamto.devnul.com> wrote in message
news:87r8c2mtt7.fsf_at_tiger.rapttech.com.au...
> 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!
Received on Sat Dec 28 2002 - 10:01:15 CST
