Re: Tag locking change

[erik . cumps]

Hi Guys,

  sorry for butting in but I couldn't resist trying to add my
  0,02 EUR...

What I usually do in cases such as this, where there's a boundary
between development and QA/approval, and where I am the admin, is
this:

Every development commit triggers an update of a separate working
directory somewhere off the web server. After the update a deployment
script is run which deploys the updated tree to the web server's document
tree.

During QA checking the working directory is locked to prevent any
automatic updates (on the level of the auto-update script, not a CVS-
level lock) so that everybody is quite clear on what it is exactly 
that QA is viewing.

Then, if QA approves the working directory is tagged with an approval
tag.

Finally we do a CVS update to get all the commits that we missed while
we were locked and the lock is removed so we have auto-updating after
commits again.

One of the things about this method is the decoupling of development
and QA/testing CVS activity. To me, development and testing live in
slightly different universes: development has different standards by
which to measure the product than QA. So often you have development
fixing bugs and implementing features at a slightly frantic pace
whereas QA wants tighter control on what is tested when.

So, another way of achieving that might be to have developers tag
the tree whenever a bugfix or feature reaches stability, and QA update
it's tree whenever a new tag is available. But that just means more work
for everybody. Scripting can take away a lot of that work and tedium.

Anyway, that's just my humble opinion. :)

Erik



--- Original mail from Adam Bregenzer ---

On Wed, 2002-10-09 at 14:58, Greg A. Woods wrote:
> [ On , October 9, 2002 at 14:26:15 (-0400), Adam Bregenzer wrote: ]
> > Subject: Re: Tag locking change
> >
> > On Wed, 2002-10-09 at 13:58, Greg A. Woods wrote:
> > > 
> > > Yes, sure, but that copying is done (or at least the source for the
> > > copying is created with) "cvs update", RIGHT?  (i.e. it had better 
be!)
> > 
> > Not at all.  The server that holds the cvs repository also has apache
> > runing on it.  When a commit occurs each file that is committed is
> > copied into a seperate directory.  That directory is the DocumentRoot
> > for apache.  That way, when a change is committed it is automagicall
> > viewable by browsing to the cvs server.  The point is that one who 
does
> > not edit the site manages and approves the site.
> 
> My point was that you can do the same thing more reliably with a "cvs
> update" in a working directory that is the DocumentRoot.
But then it wouldn't be automagic, it would be whenever cvs update is
run.  Certianly every minute would be 'acceptable' but this solution is
fine.  Plus in this case the repository and the live site have different
directory structures.

> >  Currently that
> > individual runs cvs rtag when the site is in a producation ready 
state. 
> 
> Then that individual _could_ edit the site, so it is irrelevant from the
> access rights point of view whether or not that indivudual runs "cvs
> tag" or "cvs rtag".
He/she certianly *could* but do you want a manager knowing they can? :P
Plus, she doesn't modify the code so why keep or have a checked out
copy?  (I understand it's necessary in cvs, I'm trying to make a point)

> > Then a script is run that does a cvs export with that tag and posts it
> > to the live site.  It has nothing to do with the client, it's all
> > *server* side.  I see no reason for it to bve tied to an update, I 
don't
> > even know how to execute a server-side script on update and wouldn't
> > want to anyways.
> 
> You could trigger the server-side "cvs update" in any number of ways,
> though the very best would be if the individual doing the testing and
> approving did it just before testing.
It's primarially for the developers, the testers only see it at
regularly scheduled intervals so a developer's commit doesn't fsck
something up.  The environment on the cvs server emulates the live
environment, most developer machines do not that is the reason for the
constant sync with cvs, immediate testing....  Plus, I don't want to
give testers access to the test server and I don't want to write an
interface for them to do it.

> > > When it's "ready" you should be "cvs tag"ing the working directory 
which
> > > matches the "ready" revisions of the files.
> > 
> > But what if I have not working directory.  What if the developers are
> > just that.  Developers.  I can certianly tell them to tag it for me 
but
> > that's a bit strange.
> 
> That does not make any sense.  You can have a working directory if you 
want.
Well, the first sentence should be 'But what if I don't have a working
directory', but I think you mean my point doesn't make sense.  What if
you don't want or need to have a working copy?  You cannot really do
anything in cvs without a working copy, which is obviously something
some people on this list have not realized.  The fact that what I said
doesn't make sense is a reflection upon you of the design and
methodology in cvs.  Ya know not everybody wants a working copy....

> > Actually, I realized something else, you can't run an rtag from a
> > application that was run from a commitinfo script.  That's what I was
> > thinking.
> 
> You can't run "cvs tag" directly from comitinfo scripts either, but that
> shouldn't be an issue.  It's easy enough to design better solutions.