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] > >
