ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephane Bailliez <sbaill...@gmail.com>
Subject Re: ivy integration with automated build tools
Date Fri, 15 Feb 2008 20:51:30 GMT
Shawn Castrianni wrote:
> I have my standalone ivy builds working great such that any developer can build and retrieve
dependencies.  However, now I am trying to get automated builds going for continuous integration,
scheduled nightly builds, etc.  I was curious what people out there are using.  I always run
into the problem of coordinating the automated build systems build numbers and ivy's build
numbers.  It would be great if they could be the same such that a developer could look at
the automated build website and see builds with numbers that match the number in the ivy repository.
>   

I would not use the 'automated' build number, but do the promotion 'on 
demand'.

Strictly speaking only a human can know if a version is actually a minor 
or a major bump for a version and as far as the 'build number' goes, you 
always have one available which is more meaningful than anything else, 
it's the revision number of your scm which you can pull easily during 
your build process, you don't need to increment/commit etc...your scm 
does that.

> I also see overlap in functionality between ivy and automated build systems with dependency
management, publishing, and promotion.  I have all of that working with ivy and am wondering
if I just ignore those aspects of the automated build system in favor of ivy?
>   
That depends what you want to do.

In a previous shop (which was actually last century), I was always 
building the current trunk (which were always having fixed revision for 
dependencies), plus the stable branches (with fixed revision of 
dependencies as well of course) plus the 'future possible trunk', which 
was the trunk of all projects all depending on the trunk of their 
dependencies.

The 'future possible trunk' was merely an indication of a possible API 
breakage that could eventually occur if people are releasing a new 
version. So for a  project that has modules which are pretty 'unstable' 
and that has a lot of API changes, etc... it's something that can be 
broken quite often but it can be a useful indicator 'sometimes' if used 
right as if there is relatively good discipline in your organization 
that can allow you to catch mistakes more early than after a release.

In our current shop...we work only with fixed revision. It was 
_extremely_ difficult to move from the original view of 'I depend on  
latest.development of everything' (which grew up organically from the 
fact that the project was created from scratch, modules were created, 
etc... and no real discipline as 'doing thing' was more important than 
'doing it reasonably right').

Depending on the latest.dev for all your modules is as you can imagine 
is a total nightmare in term of stability of component because you never 
know on what you depend and that forces each developer to build the 
entire universe which is utterly stupid and then you have people hacking 
around to actually trying to decrease the build time, which creates even 
more problem, etc.... It's a very good way to have chaos in your 
organization as the view of the world will vary depending on people...

When you work with fixed revision that puts more emphasis on your 
process and you have a reasonably good idea of the code you depend on 
and you can see what people are doing.

-- stephane


Mime
View raw message