views:

132

answers:

2

The company I work for writes a lot smallish Perl and Bash scripts to massage data into something usable for our software. These scripts, like any code, can change. I provided them CVS because of the file versioning rather than repository versioning. Anyway, I am thinking out a deploy tool to get the scripts from development to production. The production server will have it's own simple versioning system in that if one of the scripts' md5 sum does not match the one in a database it will not run the script and email the appropriate parties.

I want to force the programmers to deploy the most current CVS version of the script. If it is not the most current it should die with a message telling them they have to check in their version first. I realize there might be cases where you need to deploy an old file. Those would be exceptions and could be handled as such.

What's the best to do this? Is it just as simple as doing a 'cvs diff' ?

+1  A: 

if you going to write some kind of distribution script it should be relatively simple

1) The script should be committed in your cvs repository

2) I advice to call the script from your makefile (or any build system you use) something like this

make dist

and the dist rule will call your script.
3) script will perform

 cvs up -An

and analyze the output to look for M or C or A or R status by redirecting the output to grep for example.

grep -c ^[MCAR]

if count > 0 you got a problem.

4) if one of above found fail the build script

5) if not create the tar or any other form of distribution you are using

To deploy older version you can make an -A as a parameter by default set to -A and overridden for example by shell variable to be for example -r tag-3.14.4 .

Ilya
use '^[MARC] ' to prevent capital character in file names causing false positives...
dmckee
you are right corrected. Thanks
Ilya
A: 

I worked on an internal tool that did deployments. It was designed for the enterprise (and to meet SOX regulations), and so it relied on approvals to deploy code.

Because of this, we deployed the version of code the developer specified in the request, not the latest version. The reason is that a developer may need to make changes, place into test, meanwhile other changes take place. These newer changes have not gone through the test (QA) phases, but the developers original version has, so we would deploy that version.

All that to say, I would design it in such a way that a version number could be specified, and if no version number then push the latest.

Brian Schmitt
That's a good thing to to take into consideration
Chris Kloberdanz