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
