Eric, Anytime I tried to use a different approach then the 'best pratices' I ended up in a worse situation. IMHO you don't need a quarterly production release in order to use a good development process. If the work in a certain branch is done after 48 hours, that's fine!
I hope that if you really create a release each 3 or 4 week, you won't have much paralel branches active. It appairs to me that with 2 CI build (on the trunk and on the branch for the current release) should be enough. The result of this would be that at the end of each iteration, you would need to create a new branch and re-configure 1 build-plan on your CI-server each month. To me this sound better then checking out from a tag and then manually changing the source prior to building the product. According to J2EE development guidelines and common best practices, the product you release should not contain any environment specific configuration. If so, refactor that, so the number of builds you have to products decreases by a factor 3. (Just 1 release for dev, QA and production instead of 1 for each environment). I know that I'm frequently more rigid then other developers when it comes to procedures and best practices, so if you decide to incorporate some 'work-around' it's fine with me. (At least as long I don't have to work on your development team. ;-) ) Good luck with your problem and if you do find another good solution, please let us know! With kind regards, Marco On 12/13/07, Eric Minick <[EMAIL PROTECTED]> wrote: > > 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: users@maven.apache.org > > 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] > > > > > ********************************************************************** 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]
