I didn't see a reply from a Brian. What answer did he provided that answered your question?
________________________________ Curt Yanko | Continuous Integration Services | UnitedHealth Group IT Making IT Happen, one build at a time, 600 times a day -----Original Message----- From: jhumble [mailto:j...@jezhumble.net] Sent: Monday, November 08, 2010 11:58 AM To: users@maven.apache.org Subject: Re: Continuous Delivery and Maven Todd, I have read all of your posts and I have come to the conclusion that you're missing the point of CD. I was really hoping to avoid an argument about process, because I just want to work out what needs to be done to Maven to make it support CD, and that's already a big enough discussion for one thread. However since the thread has (perhaps inevitably) been taken over by a discussion about what continuous delivery is, I will add my 1c. In any case I think I have what I need from the discussion with Brian. With CD, the software is *always* production ready, right from the start of the project. Any work of any kind that doesn't result in a deployable build is waste. If you are at the start of a release, your product owner will have a good > idea of how much content needs to get to the customer to fullfill that > release. Doing CD through the entire lifecycle is largely a waste IMHO. Wrong. In fact, it's the opposite - any work that doesn't keep the software in a deployable, releasable state is waste, because you can't know whether or not the work you have done is actually useful, or even whether it keeps the software working. And you can't know whether or not the software is working - i.e. whether or not the build can be deployed - until it has passed end-to-end acceptance tests under realistic loads in a production-like environment. I am fine with you using the process you describe. If it works for you, that's great. But please don't call it continuous delivery - it isn't. Now, assuming we are working in a cd process, the crucial thing is that we don't waste any cycles creating a build that couldn't be released. We then take this binary and put it through the rest of the deployment pipeline (or build life or whatever you want to call it). But crucially, we don't want to recreate the binary later on. If you want more detail on the mechanics of how it works, you can read the free chapter from my book here: http://www.informit.com/articles/article.aspx?p=1621865 *What I want from Maven* *===================* We want the simplicity of snapshots with the traceability of proper releases. So I think from what Brian said, I'd like the the Maven snapshot build process to create enough metadata in the pom file such that when you ran the release plugin, it wouldn't be necessary for it to rebuild the artifact - it could just do the various bits of tagging and metadata creation using the information in the pom associated with the snapshot. We might also want the release plugin to try and recreate the binary using its process and verify the md5 is the same as the md5 of the snapshot. If anybody has any feedback on this hypothesis, I'd be very grateful. Thanks, Jez. On 8 November 2010 08:49, Thiessen, Todd (Todd) [via Maven] < ml-node+3255336-1962346083-143...@n5.nabble.com<ml-node%2B3255336-196234 ml-node+6083-143...@n5.nabble.com> > wrote: > > I'm thinking tha Ci wouldn't be affected at all, CD still requires > > Ci as a quality metric preventing deployment to the customer. > > I am curious to see that. Or how it would work. How do you put in > fixed release numbers into a CD build and then switch back to CI > building? And I can only imagine it being quite complex. > > The only thing I can think of is something like: > > 1. CI build produces 1.0-SNAPSHOT > 2. CD build produces 1.0-01 > 3. CD build reverts source back to 1.0-SNAPSHOT 4. Repeat > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3255336&i=0> > For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3255336&i=1> > > > > ------------------------------ > View message @ > http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370 p3255336.html > To unsubscribe from Continuous Delivery and Maven, click here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubs cribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwtMTg4 MjM1NzMyNA==>. > > > -- Jez Humble Co-author, *Continuous Delivery <http://continuousdelivery.com/>* http://continuousdelivery.com/ http://jezhumble.net/ -- View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370 p3255361.html Sent from the Maven - Users mailing list archive at Nabble.com. This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
