• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Tim Cooke
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • paul wheaton
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Tim Holloway
  • Carey Brown
  • salvin francis

source control & migration process

 
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 134
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sounds like a reasonable approach.
 
Come have lunch with me Arthur. Adventure will follow. This tiny ad:
create, convert, edit or print DOC and DOCX in Java
https://products.aspose.com/words/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!