From: cs_mj@gsbacd.uchicago.edu (Mark Jaeger)
Subject: Re: Control of Ingres software development on unix
Organization: 
Date: Thu, 30 Jul 1992 21:22:14 GMT

In article <12375@ecs.soton.ac.uk>, mk@ecs.soton.ac.uk (Mike Kellaway) writes:
>
> CONTROL OF INGRES SOFTWARE DEVELOPMENT ON UNIX
>
> We have to develop our applications on the same unix box as
> we run them live.
>
> What we are looking for is the best way of setting up the live and
> development environments so that it is easy to control the development
> environment and to move a new version to live.

We use VMS, but the principles should be the same.  For each of our
systems, we typically have three databases: production, test, and
development.  For project xxx, we name them xxxprod, xxxtest, and xxxdb.

The production database is live and has all the current data.  It only
has to contain back-end objects (tables, views, indexes, permits,
integrities, procedures, rules), but sometimes it contains report-writer
or RBF reports, and forms, joindefs, and QBFnames for QBF use.  The test
database is recreated periodically from scratch as a complete copy of
the production database.  The development database contains the same
back-end objects, but only contains a skeleton of the data, for the most
trivial of testing.  This is also where we keep all of our forms and ABF
applications.

We develop everything in the development database.  After testing it in
this database (e.g., with ABF "Go"), then we move on to the test
database.  Once we're convinced that it works, then we wait until the
evening when the users have gone home, and migrate the changes to the
production database.  This may include table changes and the
installation of a new version of the system to a public execute-only
directory.

All of this is our ideal.  In practice, we hardly ever stick to it
completely, so we end up with lots of chaos, too.

> Source code control can only cover part of an application. e.g. not
> forms control.

I know at least one group at our site has written a program that reads
the system catalogs for the last date of change for a form, and then
fudges the change date on an empty file to fool the "make" program. This
changes the "make" into a two-stage process: first, read the database
system catalogs and set the change dates on a bunch of OS files; and
then, run "make".

> Also we seem to be forced to use absolute pathnames.
> e.g. help files.

I assume you are using "help_frs" or "help_forms".  I suggest writing a
3GL procedure such as the following example in C:

	void frs_help( const char *subj , const char *file ) {
	#ifdef ARGS_FOR_SQL
		exec frs BEGIN DECLARE SECTION ;
		char *subj ;
		exec frs END DECLARE SECTION ;
	#endif
		exec frs BEGIN DECLARE SECTION ;
		char buf[ 200 ] ;
		exec frs END DECLARE SECTION ;

		sprintf( buf , "%s/%s" , getenv( "XXX_HELP" ) , file ) ;
		exec frs HELP_FRS ( subject = :subj , file = :buf ) ;
		return ;

		}

The environment variable XXX_HELP tells the system where to find the
help files.  This way, you don't have to hardwire the path name.  You
can also put the path in the database, in a "parameter" table.  Changing
this becomes a simple matter of changing a value in the database.

> We have tried using different database names and owners for live and
> development but this causes problems,.

With ABF applications, you can use the "-d" switch to run the
application against a different database, and, in fact, that's exactly
what we do, since we hardly ever run the application against the
development database.

For ESQL applications, we have written a 3GL procedure to wrap around
the "exec sql CONNECT" statement.  It allows the same usage, so that we
can supply the "-d" and "-u" switches on the command line.

--Mark Jaeger				internet: cs_mj@gsbvax.uchicago.edu
Graduate School of Business		yellnet:  (312) 702-0328
University of Chicago			faxnet:   (312) 702-0233
Disclaimer: My opinions are my own and not those of my employer.
Ich bin ein Virus.  Mach' mit und kopiere mich in Deine .signature.