aspose file tools*
The moose likes Agile and Other Processes and the fly likes source control & migration process Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "source control & migration process" Watch "source control & migration process" New topic
Author

source control & migration process

louise rochford
Ranch Hand

Joined: Apr 04, 2002
Posts: 119
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
Ranch Hand

Joined: Nov 05, 2003
Posts: 134
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
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
louise rochford
Ranch Hand

Joined: Apr 04, 2002
Posts: 119
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
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Sounds like a reasonable approach.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: source control & migration process
 
Similar Threads
Maven or Ant: SVN revision
Sharing resources between EARs
Version control in eclipse indigo
Q for Mike Clark: tagging the release
Configuration management of JBoss files