Mailing-List: contact continuum-users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: continuum-users@maven.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <45621C0F.90302@israfil.net>
Date: Mon, 20 Nov 2006 16:20:15 -0500
From: Christian Edward Gruber <cgruber@israfil.net>
Organization: Israfil Consulting Services Corporation
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: continuum-users@maven.apache.org
Subject: Re: Forced builds
References: <265E9EE670ED404DA5DBE42428204A44353569@uscnt0416.us.deloitte.com>
	 <45620059.8030401@venisse.net>
 <52bab8690611201131k14526c9dwafe9e9ed4f698a94@mail.gmail.com>
In-Reply-To: <52bab8690611201131k14526c9dwafe9e9ed4f698a94@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------080306010406010603010206"

--------------080306010406010603010206
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Complex projects with lots of external dependencies, particularly
dependencies on external snapshot versions of code.

Also, we run a nightly integration test against external systems (we
only run Unit tests on the normal non-forced build, or they'd take too
long), and changes in the underlying database, or changes in the test
data would cause test failures that need to be identified.

I feel that this attitude Wayne cites (no delta, no build) is quite
common, but makes a lot of assumptions about one's environment, and I
think is unrealistic in many large-scale development environments.  It
may be perfectly reasonable in Wayne's context, or many others, mind
you.  But especially in large, highly interconnected development
environments (like a big bank), you want to have relevant information
communicated between groups and architectural layers as quickly as
possible to identify any defect or change in assumptions, so a set of
system/integration tests run on a schedule (hourly, daily, whatever) are
entirely appropriate, and may identify defects regardless of code-changes.
 
The good news, Alexander, is that 1.1 will have such a feature (Jesse
committed this a few weeks ago - not so much a forced build, but a fresh
cut of the workspace, which has the same effect), so when 1.1 is
released you can do exactly this.  I frankly run a trunk build, because
for all its little instabilities, it's so feature-superior to 1.0.3 that
for me it's worth the hassle.  One of the main "gets" for our
organization is the forced scheduled build.  Continuum (1.1-SNAPSHOT)
has proven to be quite handy at decreasing latency in communication of
API changes, underlying business cases (test data), or other issues by
forcing the issues faster, when used this way... even when humans forget
to talk to humans.

Cheers,
Christian.

Wayne Fay wrote:
> No changes in code == no reason to build, right? I don't see the
> usefulness of this enhancement, personally... Unless of course some
> PHB has laid down a "build all projects every 3 hrs" kind of mandate
> in your organization.
>
> Wayne
>
> On 11/20/06, Emmanuel Venisse <emmanuel@venisse.net> wrote:
>> Not yet, why?
>>
>> Emmanuel
>>
>> Morgovsky, Alexander (US - Glen Mills) a �crit :
>> > Is it possible to have Continuum force build every n hours even if the
>> > code in the source code repository hasn't changed?
>> >
>> >
>> > This message (including any attachments) contains confidential
>> information intended for a specific individual and purpose, and is
>> protected by law.  If you are not the intended recipient, you should
>> delete this message.
>> >
>> >
>> > Any disclosure, copying, or distribution of this message, or the
>> taking of any action based on it, is strictly prohibited. [v.E.1]
>> >
>>
>>
>


-- 

*christian** gruber + process coach and architect*

*Israfil Consulting Services Corporation*

*email** cgruber@israfil.net + bus 905.640.1119 + mob 416.998.6023*


--------------080306010406010603010206--