Hi George, We are facing similar questions - our current processes are based on CVS.
We make extensive use of tags, like "test" "qa" "prod" "demo" - which move from older to newer revs of files in cvs. The deployment scripts we run are driven by these "request" tags - and those scripts also create and modify additional tags to keep track of what's where since when. One family of tags controls the migration of application files and another family controls the migration of uPortal framework files (we use vendor branches and tags to keep track of releases imported from ja-sig). There's a presentation of this here: https://mywebspace.wisc.edu/jfthomps/vc/IntVCandCM3.ppt There are some other links here: https://mywebspace.wisc.edu/jfthomps/vc/ It seems clear that Maven2 and svn are in our future with uPortal 3. While we have what seems like a robust and flexible way to handle config files in CVS, by using map files, one main question for us seems to be how to handle config files in Maven2 and svn. At times we had over a dozen different environments on-line at the same time, with all updates fully automated. It seems clear that we won't have tags "floating" in svn like we do in cvs - and tags are not really at the file level in svn, so we'll have some adventures with reengineering our processes for svn and Maven2. My guess is that I'll no longer be in the business of applying "prod" tags to invidual files (which I won't miss). We'll probably have the trunk, tags and branches subdirectories in svn under each portlet - and app developers will work at that level. Somehow, probably via Maven2, they may create a war or zip file when ready to promote an app. I might just be maintaining the "inventory" of apps in a pom.xml (e.g., appX_qa_20070731_1515_MikeF). Of course we'll probably have a different pom.xml in each environment and if we compare, for example, the qa and prod versions, we could see which apps have different releases in those environments. We hope to reduce the number of config files (maybe 75+ today), but we probably will still need to deal with the issue of "how to change the deployed code (e.g., increase or decrease logging level) in environment X". At the moment I can admire the problem, but don't have any immediate solutions. I hope that we'll get some approaches to the problem and would be happly to hear from you if you come up with some ideas. Comments? Cheers, Jim George Lindholm wrote: > > Hi, > I'm trying to come up with a process to manage source code promotion > from devl to verf to > production, as well as tracking production deployments (i.e. track the > state of the webapps > directory in svn), both as a way to restore a change and to make > deployment easier > across instances/machines. > > So I'm wondering what other sites are doing? > > Thanks > > George > > -- > [EMAIL PROTECTED] ITServices, UBC > Senior Programmer Analyst > > phone: 604.822.4375 fax: 604.822.5116 > > > -- > You are currently subscribed to [email protected] as: > [EMAIL PROTECTED] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev > > -- View this message in context: http://www.nabble.com/Code-promotion-with-subversion-tf4194735.html#a11936245 Sent from the uPortal - Developer mailing list archive at Nabble.com. -- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
