Curt makes a good point - you can do CI without doing CD. The snapshot stuff
works just fine with CI.
It seems to be a tool that is prone to being used foolishly
I think that's probably true of any sufficiently powerful tool or technique.
Jez.
On 15 November 2010 10:23, Yanko, Curtis [via Mav
>
> I would like to see the whole "Best Practice" described. I would like
> to see how Hudson users deal with mock data and incremental development
> and testing of on-line applications where the MC and V teams are
> working together towards a fully functional system or a working bug fix or
> mino
BTW - I also think Stephen's suggestion is a good one - it's more or less
what I suggest in the book.
On 10 November 2010 09:45, Jez Humble wrote:
> Hey Todd.
>
> My interpretation of what Jason is saying in his comment here -
> http://www.lucasward.net/2010/11/maven-and-continuous-delivery.htm
Hey Todd.
My interpretation of what Jason is saying in his comment here -
http://www.lucasward.net/2010/11/maven-and-continuous-delivery.html - "you
should be able to tag the code, and pluck the snapshot out and promote it to
a release repository... Someone just needs to do the two weeks of work
I confess I haven't read
> your book yet but it is on my short list so only a matter of time I'm
> sure.
>
>
>
> Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
> Making IT Happen, one build at a time, 600 times a d
OK this is great - I think we're on the same page now.
> And I am pretty sure that the community in general is not really in favor
> of this kind of massaging of the artifacts from snapshot -> release. It
> invalidates your testing of said snapshot.
>
> I think it is crucial that the release art
>
> My mantra is this, if you are feeling pain in your process, do it more
> often which should force you to either solve the problem or realize it's
> upstream.
That is one of my 8 principles of CD ("If It Hurts, Do It More Frequently,
and Bring the Pain Forward" - p26). And I think it applies
>
>
> And in a community driven environment, if something isn't perceived as
> valuable, it generally doesn't get done. You are welcome to create a plugin
> to do this or perhaps enhance an existing one. If the community feels it is
> valuable, you will get a lot of help to make it happen. If the
>
> At the risk of derailing the conversion again though, there is likely a
> good reason for why it has been such an up hill battle for you. I hope you
> are prepared to consider that CD is not as great of a solution to a lot of
> the industry as you wish it to be.
Well, if I and many others h
>
> Only my stuff can be a SNAPSHOT and it is either all a snapshot or it is
> not. So, if B & C are mine it's not an issue, if they belong to some one
> else's, they can't be SNAPSHOTs, it's that simple. I can even use the
> enforcer to ensure there isn't a SNAPSHOT set anywhere as part of the
>
Hi Curtis
> What you're proposing is indeed interesting. But you do seem to pick and
> choose what you want (reproducibility) and what you can dispense with
> (tags and branches).
>
Correct. In my defence, I have extremely good reasons why I want
reproducibility and don't care about tagging, de
Hi Todd.
> Ok. I will refocus here. Let me just say that this discussion is
> inevitable. It is important as the value of CD will help determine if Maven
> should consider working towards supporting this kind of process. The basic
> architecture of Maven today does not lend well to it. So we c
g from the conversation is the final assembly
> where A,B and C get put together for deployment which is also managed as
> a binary and represents the bill-of-materials. And of course my Maven
> Site report for A would have documented which B & C I had too.
>
> ______
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:[hid
>
> You may use any number of commits to complete a particular user story.
But you can still keep your software releasable by implementing features in
an incremental way, as described here:
http://martinfowler.com/bliki/FeatureToggle.html
I don't see how delivering an in progress story has any
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
on
Hi Brian
It just seems like the rev ID is really useful here for identifying
> reproducible builds without creating releases every time, does it fit with
> your ideas? If so, a hypothetical repository manager plugin could be
> maintaining information about snapshot dependencies based on SCM rev
ble 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
On 7 November 2010 10:02, Brian Topping wrote:
> Does your book discuss ways to get around these issues?
No, it's a patterns / practices book so we don't go into a lot of detail on
the tools because that information tends to go out of date fast. We discuss
Maven a bit at the end of Chapter 13
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 ra
20 matches
Mail list logo
