source control & migration process

[louise rochford]

Hope I've got the right place for this...

I was wondering what process people use for managing version control of released code. We use cvs for the source java files, and on most projects it has been sufficient to tag these files with a build verison. If we needed to revert to a previous build we could regenerate the ear by checking out & building the tagged source.
But - we don't version & control the ear files themselves -just store them on a lan in some arbitary directory structure.

Now I've just been stung by releasing the wrong version of an ear file. This ear was created by an external company, so never went anywhere near cvs.

I want to tighten up our procedures for managment of the ears / jars etc. What do you do? Build afresh from the source for each release / release previously build ears? When you migrate code through development to testing to production environments, how do you ensure the version eg you're putting live is the same version thats been tested?

Any comments or references?

Cheers,
Louise

[Naina Si]

We use PVCS for version control. We label all the files for any test, model or prod deployments and create an ear with those files.
We also checkin that ear into PVCS with the same label as the one we used to label files.

That way we can deploy the same ear to all the regions (model, prod) and we know for sure that source is same for all.

[Ilja Preuss]

We don't put any product of our build process into version control. We *do* name zip/ear/war files so that we can connect them to a version tag, though, and archive them in a defined folder. And we put everything under version control that we don't build ourselve, such as thirdparty jars.

Did the ear you mentioned need to work together with something that was under version control?

[louise rochford]

Thanks for the feedback.

No, this particular ear file had nothing to do with any of our own java code. In fact the only reason I was involved was because it was java code that needed deploying - called by & calling non-java code I had nothing to do with at all. I received several versions of the ear over a 9 month period, but my filing wasn't up to the job, so the version I released to testing last autumn wasn't the same as the one I got released to production last week.

I've created a bespoke 'simple' project (using WSAD) & retrospectively booked the ears in to cvs as files in this project. I think this is the safest thing to do & looks like the standard approach - just something I hadn't thought about much before.

[Ilja Preuss]

Sounds like a reasonable approach.