[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: slightly off topic - Directory Structures
Re: slightly off topic - Directory Structures
Tue, 24 Jun 2003 09:06:41 +0200
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529
-----BEGIN PGP SIGNED MESSAGE-----
| This is what I was thinking ... that if you want to build exactly what is
| in production than jars and other lib or dependencies need to be included.
| We were actually contemplating using CVS as a mechanism to store what is in
| production including all of the executables ...
| In our staging are we would set up what we wanted to be in production and
| then when we were happy we would save all of these files into the
| production project ... then would go to our production box and to cvs
| update and we should then have a production environment ...
| This would make any rollbacks very easy because we could always just cvs
| update -r to get back to a certain production environment.
| Again we were just contemplating this ... any comments?
I know of one project where they use CVS in that manner; as a repository for
code put into production. They have two CVS repositories: one for the source
code and one for deliverables.
When they make a release to production they insert the built system into the
other CVS database. The production system then updates the local sandbox, thus
getting the latest version.
There is much to be said about this system, but admittedly is has its pros.
~From what I have gathered are they quite happy with this system.
My only concern is that there are synchronization issues involved here.
Traceability is also a problem since this scheme involves different
repositories, although that could be fixed with using only _one_ repository
instead. That would, on the other hand, make the local copy ludicrously large...
The point I'm trying to make is that although this works in practice, it is
hard to ensure that the contents of a release is consistent. I'd rather have a
build system where I can re-create any previous release with a command that
checks out that particular branch or tag and then build the system accordingly.
This is a guarantee that I can re-build any released version at a later stage
and still be sure about the content.
All this can be fixed with scripts, documentation and procedures, of course. It
is more a matter of "best practice" and what suits your environment I suppose.
The way I have set it up in my project is to have a SQL database from which I
can allocate build numbers; this ensures that build numbers are unique. Those
numbers are then inserted into include files and what-nots and also cheched in
to CVS as part of a build and then is the whole system tagged. Once the build
is tagged is the assembled binary structure copied to a server (to a directory
that reflects the build number) from where the testers can install it.
This gives me the ability to later fetch a tag of the system and just build it
and all include files and versioning information is correct as per that build.
Everything is run by Ant, of course.
| > > <Project Name>/Common ? This is a link to the Common Project. This link
| > > provided as a convenience when doing development. This directory should
| > > only be used in development and not in production
| > I don't get this one.
| Well this goes back to one of my earlier posts where if you have common
| reusable code where does it go and how is it handled by CVS.
| for example StringUtils.java or something like that?
Again, I would probably use Ant for this. Ant can work CVS and it would be a
piece of cake to have Ant retrieve a particular project and put it somewhere
inside your sandbox prior to building the system. This requires that everyone
builds the system using ant at least once, but that should not be a problem.
| I do use JUnit ... but I always feel that there should be a test suite
| especially when you are making changes to common code. This way you can
| see if you have broken anything. Also I am not sure if any of you have
| used "Tinderbox" which is an automated build mechanism. We would have
| automated builds and then part of the build mechanism would be to run our
| test suite. This worked nicely as you always new that the current code in
| CVS production not only build but passed all of your automated tests
I have looked briefly at Tinderbox but not implemented it. What I am
considering right now is something called "continous integration", using
CruiseControl. Please take a look at this link for further info:
and info re. CruiseControl can be found at
Looks very promising, indeed!
One who has been working at that same desk in the same office for fifteen
years and has very much his own ideas about why he is continually passed over
(The Meaning of Liff, Douglas Adams)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----