On 15/11/2010 10:41 AM, Benson Margulies wrote:
Ron,
It's not too hard to set up a CI process (e.g. on Hudson) that tests
the latest version of everything. Don't publish snapshots to your
repo, set up the cascade of jobs to share correctly.
If that answers a question that is useful to you, great.
It is never as hard as people seem to think to set something up so that
it works correctly but I am amazed at the hacked up development process
that get described here.
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 minor
enhancement.
How does one manage a production environment with released systems
functioning while new releases are being developed and patches are being
applied to the current release?
If, rather, you need to somehow model all kinds of combinations of
-SNAPSHOT and non-SNAPSHOT dependencies, or you feel compelled to
publish snapshots to your local repo, chaos is just around the corner.
In maintenance and bug-fixing, you do need to mix Releases with
SNAPSHOTs to build a full system since you might only be releasing 2
portlets out of 50 to add a new small function or fix a bug. The
overhead of rebuilding 70 modules to get 2 fixed is just not something
that we can support.
We do publish SNAPSHOTS to the internal repo but they come with a
warranty and some functional spec that the rest of the team can live with.
This does not cause a problem because we know what we are building and
know the combination that has to be tested within the scope of each
active project.
Ron
On Mon, Nov 15, 2010 at 10:27 AM, Ron Wheeler
<[email protected]> wrote:
On 15/11/2010 8:18 AM, Yanko, Curtis wrote:
You're happy about NOT using CI????
Yes. It seems to be a tool that is prone to being used foolishly.
We are a small shop maintaining and developing a large (70+POM files) portal
application with portlets, web services, servlets and batch process and do
not seem to have the types of issues that the people, trying to use CI,
bring to the table.
They seem to get into all kinds of troubles with SNAPSHOTs, build
repeatability, source control and architectures that are too interdependent.
I can not see how they ever test anything with a continually unstable CI
build.
Of course, I know that I am only seeing the worst cases in the forum so my
mind is not completely closed on the subject.
I can hardly wait until we have a "Best Practice" section on the Maven site
so that I can see how a CI should be integrated into a Maven environment and
perhaps that will make me unhappy that I an not using CI.
Ron
-----Original Message-----
From: Ron Wheeler [mailto:[email protected]]
Sent: Saturday, November 13, 2010 2:05 PM
To: [email protected]
Subject: Re: Continuous Delivery and Maven
I would add the following bits of reality.
We don't use CI and a lot of the discussion makes me very
happy about that.
-Curt
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
