Interestingly enough, I kind of feel that we have a different definition of continuous integration.
You generally don't want to, and hopefully very rarely need to, go back to a specific revision. The whole idea is that you are always reproducing problems on the latest version of your project's trunk and all latest trunks of all its dependencies. Reproducing it on a specific revision has little value. If you are not reproducing, fixes and adding new features on the latest trunk, then you are not really doing continuous integration. Why? Older revisions are simply just that; old. If you do go back and reproduce it on a specific revision, you still have to fix and reproduce on the latest trunk. 99% of the time, you can go right to the latter. For this, Maven is excellent and is what I would hope you are your book would recommend. For those few cases where you do need to reproduce a specific revision and all of its dependencies, you are right, it can get very messy with snapshots everywhere. I think you are making a mountain out of mole hill here. > -----Original Message----- > From: jhumble [mailto:j...@jezhumble.net] > Sent: Sunday, November 07, 2010 11:41 PM > To: users@maven.apache.org > Subject: Re: Continuous Delivery and Maven > > > Hi Curtis > > I'm the first to admit I'm no Maven expert. > > So please let me just confirm. Let's assume I am working on project A > which > depends on projects B and C. For the sake of argument, let's say that the > source code for A, B and C have separate roots in SVN, and are usually > checked out independently. The CI system builds A at version 50 using > snapshot dependencies on B and C, which are fetched from a central > snapshot > repository. > > Later, there are multiple updates to projects B and C which result in new > versions of them becoming available. > > Say I now check out the source code to project A to version 50, because I > want to try and debug some issue that cropped up in a performance testing > environment, and I run a maven build. Will that use the latest versions > of > the snapshots from the repo, or the versions that were originally fetched > when it was run on the CI system? > > Can I even find out exactly which versions from svn the snapshots of B > and C > came from that were used by the CI system to generate the original build > of > A? > > Thanks, > > Jez. > > On 7 November 2010 20:10, Yanko, Curtis [via Maven] < > ml-node+3254520-1036569885-143...@n5.nabble.com<ml-node%2B3254520- > 1036569885-143...@n5.nabble.com> > > wrote: > > > Very interesting discussion. With all due respect to Mr. Humble, and I > > am a big fan of CD, I am going to venture to say that you don't > > understand Maven very well. As a thought experiment, you are correct in > > saying that a build based on snapshots is not reproducible. As a more > > practical matter however, I feel it is. > > > > Dependencies come in two flavors, our and theirs (internal and 3rd > > party). If, all of *our* dependencies are SNAPSHOT (we're doing the > > developing) and all of *theirs* are 'versioned' then the build is in > > fact reproducible assuming you build everything from a particular repo > > version even with the default auto-update setting (in fact, it's > > required). > > ________________________________ > > > > 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:[hidden > email]<http://user/SendEmail.jtp?type=node&node=3254520&i=0>] > > > > Sent: Sunday, November 07, 2010 11:15 AM > > To: [hidden email] > <http://user/SendEmail.jtp?type=node&node=3254520&i=1> > > Subject: RE: Continuous Delivery and Maven > > > > > > Hey Todd > > > > The whole point of continuous delivery is that every check-in creates a > > potential release candidate. > > > > When you're doing continuous deployment, you could be releasing > multiple > > times a day, so you don't bother cutting branches or tagging or any of > > that stuff because of the overhead. I'd rather not get into the > > justification for this process on this thread - but I wrote a book on > it > > if you're interested: > > http://www.amazon.com/gp/product/0321601912 and many other people have > > blogged about it. > > > > You're right that creating a concrete release for each commit could > > potentially use up a lot of space - but that's fine, you can just > delete > > the older ones. What this *does* mean in turn though is that it is > > essential to be able to recreate any given build given the version in > > source control it came from, and this is where Maven falls down. > > Snapshots just aren't suitable because they aren't reproducible: what > > the snapshot looks like depends not only on what versions of the > > dependencies are available at the time the snapshot is created, but > also > > what Maven's configuration and plug-ins happen to be at the time you > run > > it (assuming Maven is configured to auto-update - the default). I can't > > revert back to a particular revision in version control, run maven, and > > be sure that the artifact it generates is identical to the one it > > created when the commit was initially triggered. > > > > Ideally what I'd like is for Maven to explicitly support the continuous > > delivery model and provide snapshots that are reproducible. Failing > > that, a guide to configuring Maven so that its binaries are > reproducible > > (for example by switching off auto-update, and having sufficient > > metadata stored in pom files and Maven's artifacts repository to know > > what the state of each of the dependencies was at any given time. > > -- > > View this message in context: > > http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven- > tp3245370<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven- > tp3245370?by-user=t> > > p3254090.html > > Sent from the Maven - Users mailing list archive at Nabble.com. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [hidden > email]<http://user/SendEmail.jtp?type=node&node=3254520&i=2> > > For additional commands, e-mail: [hidden > email]<http://user/SendEmail.jtp?type=node&node=3254520&i=3> > > > > > > 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: [hidden > email]<http://user/SendEmail.jtp?type=node&node=3254520&i=4> > > For additional commands, e-mail: [hidden > email]<http://user/SendEmail.jtp?type=node&node=3254520&i=5> > > > > > > > > ------------------------------ > > View message @ > > http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven- > tp3245370p3254520.html > > To unsubscribe from Continuous Delivery and Maven, click > here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubsc > ribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwtMTg4Mj > M1NzMyNA==>. > > > > > > > > > -- > 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- > tp3245370p3254534.html > Sent from the Maven - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
