we average about 10 releases before something makes is fit for production On Thu, 13 Dec 2007 11:53:48 Eric Minick wrote: > I tend to agree, and this is the first time we've really sought to do Maven > releases on deployable artifacts. But to have traceability for what went > into my artifact it seems that I'd at least want to ensure that my build > ran through a release:prepare dry run before being deployed to production. > Otherwise, there could be snapshot jars inside my ear - which limits > reproduceability / traceability. > > If I'm doing release:prepare dry runs, there's value (tagging / site > deployments / pom incrementation) in running the rest of the release > process. So I do think I want to run the release. The problem here is that > you end up with a second artifact that needs to be retested at some level. > The alternative is to guess that an untested codebase is ready for release > and cut a release to give to QA. That's simpler, but I would expect several > maven releases per actual production deployment. > > I'll admit that I'm mostly an Ant guy who dabbles in maven, make, rake, > etc, so most of these challenges are a bit new for me. > > -- Eric > > On 12/12/07, Michael McCallum <[EMAIL PROTECTED]> wrote: > > The most common misconception IMO is that a maven release == a release... > > > > I consider a Release to an environment to be a well understood collection > > of > > tags of artifacts thats reproducible. An artifact should have an > > independent > > release cycle. > > > > all you need to do is manage the deployables i.e. what exactly ends up in > > your > > war. You can do that in the pom for the war project. That way you have > > the power to go forwards and backwards or whatever in the actual war that > > gets deployed. The contents does not need to be linear over time. > > > > On Thu, 13 Dec 2007 11:25:19 Eric Minick wrote: > > > 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] > > > > -- > > Michael McCallum > > Enterprise Engineer > > mailto:[EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED]
-- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
