Thanks Marco, I also tend to agree here as well and I think this would be a no-brainier if I was going to production quarterly. This particular project has minor updates going into production every week or three. That's border-line insane, but that matches the business needs. I've been at a number of organizations that work the same way.
My concern is that branch explosion could be difficult to manage from a CI perspective as well as for developers. I again find myself asking for "best practices" without giving all the details. My apologies. Best practices always change a bit as you face different problems. -- Eric On 12/13/07, Beelen, M. - SPLXL <[EMAIL PROTECTED]> wrote: > > Eric, > > When I read your email I think it's more an issue for source code > management and versioning, then that it should be for maven. > > If you start the process of releasing a module, you could create a > branch for that version and then release some beta or milestones (M1, > M2, M3, ....., M10) from that branch and send it to QA. If QA approves a > certain milestone, you could check it out and adjusted the > version-number to remove the milestone identifier and release the actual > version. > > Changes to mainline code should be performed on the trunk so they won't > get in the way of you release and QA proces. Upon your release, you > should merge the changes from the branch to the trunk and continue to > work on the next release. > > With kind regards, > Marco > > > > > > > -----Original Message----- > From: Eric Minick [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 12, 2007 11:25 PM > To: [email protected] > Subject: Pre-release Testing Best Practices? > > I'm looking at doing some releases using the maven release plugin. Our > environment is a set of pretty typical in house development projects for > some web-apps. So we have things like dev, qa and production > environments for deployment and frequent releases. > > We don't want to cut a release before doing QA on it. So an ideal > scenario is to put a snapshot build into QA, and get it approved. Once > approved, we would want to release that code, verify that dependency > changes didn't break things with regression tests, then move on to > staging and production. > > A natural concern here is that there are likely more changes to the > mainline code base that come in during testing and we would not want to > release those. Getting the code that went into the tested build out of > source control at release time is not a problem though. > > I have two questions: > > 1) Are there common \ recommended strategies for dealing with this type > of scenerio? > 2) If I just pull the old code out and run a release, is the SVN label > (copy) command a local copy (which would only include the files in my > release space) or a remote copy (which would include my newly checked in > pom as well as any changes committed since we went to QA)? > > Thanks, > > Eric > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > ********************************************************************** > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain > confidential and privileged material intended for the addressee > only. If you are not the addressee, you are notified that no part > of the e-mail or any attachment may be disclosed, copied or > distributed, and that any other action related to this e-mail or > attachment is strictly prohibited, and may be unlawful. If you have > received this e-mail by error, please notify the sender immediately > by return e-mail, and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries > and/or its employees shall not be liable for the incorrect or > incomplete transmission of this e-mail or any attachments, nor > responsible for any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > registered number 33014286 > ********************************************************************** > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
