>
> 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 to integrating
modules too.
> You're trying to solve a two-sided jello view of a system at
> build time, perhaps what you need is to refactor you architecture (and
> why SaaS, Cloud and federated systems lend themselves to CD). Maven is
> your pain point but I say you're just not doing it right.
>
We can both play that game, but it's not very productive. I respect the fact
that you have a bunch of experience and that you've created a process that
works great for you, and I am not suggesting you change it. Hard as it may
be to believe, I have had many experiences that point me in exactly the
opposite direction, also working for organizations that make "our little
A->B->C game" seem trivial.
So, after we *find something valuable* we can release it trivially.
>
And I think this is the nub of the problem - you don't have a sufficiently
frequent release cycle to experience the problems I am describing.
--
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-tp3245370p3256015.html
Sent from the Maven - Users mailing list archive at Nabble.com.
