info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: slightly off topic - Directory Structures


From: thomas . maciejewski
Subject: Re: slightly off topic - Directory Structures
Date: Tue, 24 Jun 2003 07:37:29 -0400

|---------+---------------------------------->
|         |           Karl-König Königsson   |
|         |           <karl-konig.q.konigsson|
|         |           @posten.se>            |
|         |                                  |
|         |           06/24/2003 03:06 AM    |
|         |                                  |
|---------+---------------------------------->
  
>------------------------------------------------------------------------------------------------------------------------------|
  |                                                                             
                                                 |
  |       To:       address@hidden, address@hidden                              
                             |
  |       cc:                                                                   
                                                 |
  |       Subject:  Re: slightly off topic - Directory Structures               
                                                 |
  
>------------------------------------------------------------------------------------------------------------------------------|










**********************************************************************
The information contained herein is confidential and is intended solely for the 
addresse(s).  It shall not be construed as a recommendation to buy or sell any 
security.  Any unauthorized access, use, reproduction, disclosure or 
dissemination is prohibited.
Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall assume 
any legal liability or responsibility for any incorrect, misleading or altered 
information contained herein.
**********************************************************************


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

address@hidden wrote:
| 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.


OK but I dont see why using CVS prevents this ...
Like I am picturing that you have your build mechanism to build in the
staging area.
Once you build and your build pushes out to the directory structure that
will be used in production ... why not do a checkin?
Then when testing is done on that release ( never do development in that
area ) commit and TAG it then go to the production area and do an update ON
A TAG

All I am seeing is that CVS will keep track of the latest thing in
production and have the ability to roll back to any previous version. Again
lets assume unlimited disk space with infrequent production changes here.





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


Can you provide more detail on this solution with examples


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


http://www.martinfowler.com/articles/continuousIntegration.html

and info re. CruiseControl can be found at

             http://cruisecontrol.sourceforge.net/

Looks very promising, indeed!


Cheers!

             Karl-Koenig Koenigsson


Hey does anyone know which wiki wiki is the standard and where I can
download it?

I tried searching the web for it and it was a bit confusing.

Tom





- --
BROUGH SOWERBY
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
for promotion.
(The Meaning of Liff, Douglas Adams)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+9/iBiIlor53vvbcRAt0VAKDrvuOBVx4LtzfkiAXmaHfbD98L+gCgyjvw
QNJJqna0o0G/YPFyk3pFUGg=
=aln7
-----END PGP SIGNATURE-----








**********************************************************************
The information contained herein is confidential and is intended solely for the 
addresse(s).  It shall not be construed as a recommendation to buy or sell any 
security.  Any unauthorized access, use, reproduction, disclosure or 
dissemination is prohibited.
Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall assume 
any legal liability or responsibility for any incorrect, misleading or altered 
information contained herein.
**********************************************************************





reply via email to

[Prev in Thread] Current Thread [Next in Thread]