You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by bhatia <Bh...@OFAC.CH> on 2007/08/24 12:03:49 UTC
development process
Hello,
Can someone guide me as to how we can compile, make changes, work with
branches etc with Ivy ?
Till date, our developers work the old-way ie to compile one project they
checkout all its dependant projects (.project file in Eclispe); basically
all action happened in the workspace and the project was committed and
tagged to CVS. For working on a branch, we checkout a branch in this case,
work on it and commit/tag to CVS.
I have successfully created a repository of artifacts (3rd party and
internal) with compile time and run time configurations thanks to which the
developer can now fetch dependencies for a particular configuration from the
IvyDE plugin. Compiling a project using Ivy is no problem either even though
all our projects are massively circular dependant amongst themselves and all
this works with confugurations I have defined.
How do we work in the Ivy world ? Checkout a project from CVS, compile it
thanks to IvyDE by retrieving dependencies, make changes to it in the local
workspace, then what ??? publish it with changes to the ivy repository with
rev="CURRENT"... ?? Same logic for the branch ? And when I am ready to
commit and tag on a branch, I publish the branch with rev="my-branch-tag" ?
Is this the way a team should work in the Ivy environment ?
thanks
--
View this message in context: http://www.nabble.com/development-process-tf4322737.html#a12309658
Sent from the ivy-user mailing list archive at Nabble.com.
Re: Little Ivy survey (was: development process)
Posted by Matthias Kilian <ki...@outback.escape.de>.
On Sun, Aug 26, 2007 at 04:59:58PM -0700, dtayl wrote:
> > - A-0.8.15.0 depends on B-1.2.3.0 and on C-7.4.2.8.
> > - B-1.2.3.0 depends on C-7.4.2.8, too.
> > - B-1.3.0.0. depends on C-8.0.0.0.
> > - When you now update A's dependency on B to 1.2.3.0, you'll get
> > C-8.0.0.0 when using the default conflict manager. This may or
> > may not lead to problems.
>
> This only makes sense to me if it reads:
>
> "When you now update A's dependency on B to 1.3.0.0..."
>
> Is that what's meant?
Yes, fixed. Thanks.
Ciao,
Kili
Re: Little Ivy survey (was: development process)
Posted by dtayl <dt...@stanford.edu>.
Very helpful survey! Thanks!
One question...
Matthias Kilian wrote:
>
> - A-0.8.15.0 depends on B-1.2.3.0 and on C-7.4.2.8.
> - B-1.2.3.0 depends on C-7.4.2.8, too.
> - B-1.3.0.0. depends on C-8.0.0.0.
> - When you now update A's dependency on B to 1.2.3.0, you'll get
> C-8.0.0.0 when using the default conflict manager. This may or
> may not lead to problems.
This only makes sense to me if it reads:
"When you now update A's dependency on B to 1.3.0.0..."
Is that what's meant?
ciao
Re: Little Ivy survey (was: development process)
Posted by bhatia <Bh...@OFAC.CH>.
Basically, the questions basically are about "when to publish", with
revision="branch-tag" or branch="branch-tag" etc...
thanks
bhatia wrote:
>
> Thanks to all of you. You have well responded on what a build server
> should do in the context of product development and I believe many are
> still in the dark over the big picture, the real truth :-)
>
> However, I still have questions related to working with Ivy in the Eclipse
> workspace e.g.
>
> 1) After making changes to a project (checkout out or updated from CVS),
> do I publish it to the repository with revision="CURRENT" or
> revision="latest.integration" and then reference this dependency from a
> dependant project from my workspace ? Is this the way to go ? So work on a
> dependency, publish it and then reference it from a dependant project ?
> Doesnt this make the development process longer in the Eclipse workspace ?
>
> 2) How can developers work on the HEAD using IvyDE, ant targets in the
> local workspace and with the Ivy repository I have set up ?
> e.g. Developer A gets a project from the HEAD, adds his changes, tests in
> local, if all is OK, he commits to HEAD in CVS. At this point, should he
> also publish this to the repository, if yes revision="HEAD" or
> revsion="latest.integration"....
>
> 3) Similar questions on the branch. I saw that there is a branch attribute
> documented on the website. So ,after making changes to a branch in
> Eclipse, a developer publishes the version/tag he commits to CVS like
> branch="branch-tag" or revision="branch-tag"...stuff like that...
>
> I hope you understand that the questions I have are concerned with "how to
> work in Eclipse with Ivy" rather than what the best practices of a build
> processes are on the build server which you have very well responded to
> and your response is a great starting point for me in the 2nd phase of
> this project when I try to integrate Ivy in our continuous build process.
>
> I hope my questions are making sense :-)
>
> thanks
>
>
>
>
>
> Xavier Hanin wrote:
>>
>> Thanks a lot for this detailed report, Matthias, I think it can help many
>> users.
>>
>> To make it easier to find by users, I think it would be a nice idea to
>> convert it to a little article. Do you have a blog? It would be a very
>> interesting post, to which we could link from Ivy site.
>>
>> Xavier
>>
>> On 8/24/07, Matthias Kilian <ki...@outback.escape.de> wrote:
>>>
>>> On Fri, Aug 24, 2007 at 03:03:49AM -0700, bhatia wrote:
>>> > How do we work in the Ivy world ? Checkout a project from CVS, compile
>>> it
>>> > thanks to IvyDE by retrieving dependencies, make changes to it in the
>>> local
>>> > workspace, then what ??? publish it with changes to the ivy repository
>>> with
>>> > rev="CURRENT"... ?? Same logic for the branch ? And when I am ready to
>>> > commit and tag on a branch, I publish the branch with
>>> rev="my-branch-tag" ?
>>>
>>> So, since Xavier wrote that a little survey would be welcome, and
>>> since this survey may answer your questions, here's what we do.
>>> YMMV.
>>>
>>> (Assuming development on the HEAD trunk for now, I'll describe when and
>>> how we deal with branches in a minute)
>>>
>>> - Checkout or Update the sources, make the appropriate changes, build,
>>> test, commit.
>>>
>>> - If everything looks well, trigger a release (major, minor or
>>> patchlevel) on a dedicated build machine -- we're running
>>> cruisecontrol on it, so for HEAD revisions we can use cruisecontrol's
>>> JMX interface to trigger a build with a special target. We've a couple
>>> of standard targets in some special build.xml that's imported in the
>>> build scripts of all projects: release-major, release-minor,
>>> release-patch, release-fix (the latter for hot fixes on a branch, see
>>> below). The same set exists for milestone builds, but we don't use
>>> this yet.
>>>
>>> - The release-* targets will do the following steps:
>>> * cvs update
>>> * Pull in the current version (major, minor, patch, fix) from a file
>>> "version.properties".
>>> * Calculate appropriate new version numbers (increase the requested
>>> level, and set all lower levels to 0).
>>> * Write the new version.properties.
>>> * Run the normal build, including ivy resolution and retrieval. We
>>> also include release information (status, revision, date, build
>>> account) into the manifests of our applications.
>>> * Make a backup copy of ivy.xml (to ivy.xml~). The important thing
>>> here is that our project's ivy files typically don't have status,
>>> rev etc. set, and also contain "latest.release" or "x.y.+"
>>> revisions in their dependencies.
>>> * Deliver the ivy file with appropriate status (currently always
>>> "release", since we don't use milestone and integration builds
>>> yet, as noted above).
>>> * Publish the delivered ivy file and the artifacts.
>>> * Commit the changed ivy.xml and version.properties with a proper
>>> cvs log message (e.g. Release 0.8.15.0), and tag it
>>> (with RELEASE_0_8_15_0 in this case).
>>> * Move ivy.xml~ to ivy.xml, to get back the undelivered ivy file.
>>> * Commit again, this time with "Unfreeze" as the cvs commit message.
>>>
>>>
>>> That's all for releases on the HEAD trunk. When we need a hotfix
>>> for an older revision (which happens quite often, since we're not
>>> supposed to deploy our latest and greatest features without lots
>>> of testing on dedicated QA machines), we proceed as following:
>>>
>>> - If it's the first hotfix for the revision currently running on our
>>> production systems (e.g. RELEASE_0_8_15_0), check out / update to this
>>> revision and create a new branch (BRANCH_0_8_15).
>>>
>>> - Update to the branch.
>>>
>>> - Modify, build, test, commit (on the branch). Developers must be take
>>> special care about the ivy.xml they are using here -- it's the
>>> delivered on, containing only fixed dependencies (no latest.* or
>>> x.y.+). If that's not desired, the devlopers have to change
>>> dependencies manually before committing their changes back to the
>>> branch. Actually, we had a case two weeks ago where we *only*
>>> changed dependencies for some hot fixes.
>>>
>>> - On the build machine, checkout that branch, then run ant as above with
>>> the release-fix target. This does the same as the other release-*
>>> targets.
>>>
>>>
>>> This gives absolutely reproducable results, which is especially
>>> important when you've rather long development cycles with the need
>>> of beeing able to reproduce builds from several months ago to apply
>>> bug fixes to them. One caveat when using branches for hotfixes like we
>>> do: if you bump some dependency to a newer revision, double-check wether
>>> all other dependencies are still at the correct revisions; you may have
>>> to use force="true" on some dependencies. For example:
>>>
>>> - A-0.8.15.0 depends on B-1.2.3.0 and on C-7.4.2.8.
>>> - B-1.2.3.0 depends on C-7.4.2.8, too.
>>> - B-1.3.0.0. depends on C-8.0.0.0.
>>> - When you now update A's dependency on B to 1.2.3.0, you'll get
>>> C-8.0.0.0 when using the default conflict manager. This may or
>>> may not lead to problems.
>>>
>>>
>>> What's still on my TODO list are the mentioned integration and milestone
>>> builds and a better integration of ivy and cruisecontrol (or any other
>>> CI-like system).
>>>
>>> Milestone builds would be nice, since we could test them on the QA
>>> machines and then, if everything is ok, switch them from milestone
>>> to release status, using the same mechanism as above. Unfortunately,
>>> there're also some problems, since we deploy on WebSphere Application
>>> Server, but we don't put EJB and resource bindings into our builds,
>>> so this is kind of error-prone, and it's more safe to just copy the
>>> tested applications from QA to the production machines.
>>>
>>> I'm also planning to support pure integration builds on the CI
>>> machine, so tightly coupled projects will be tested without having
>>> to make and tag a new release all time.
>>>
>>> Oh, and one final remark: NEVER EVER ship code built only in your
>>> IDE. It's not reproducible. I've even seen projects that were not
>>> buildable on any except a single developer's machine. Even if IvyDE
>>> helps a lot, there may still be problems, like a forgotten commits,
>>> different locale settings, or just sloppy developers not caring at
>>> all about quality. So, ALWAYS use a dedicated build machine that
>>> ONLY builds, tags and publishes releases.
>>>
>>> Ciao,
>>> Kili
>>>
>>> --
>>> I don't care what gutter Wim is lying in, make sure he's lying on
>>> his back, please!
>>> -- Marc Espie on undeadly.org
>>>
>>
>>
>>
>> --
>> Xavier Hanin - Independent Java Consultant
>> http://xhab.blogspot.com/
>> http://incubator.apache.org/ivy/
>> http://www.xoocode.org/
>>
>>
>
>
--
View this message in context: http://www.nabble.com/development-process-tf4322737.html#a12313469
Sent from the ivy-user mailing list archive at Nabble.com.
Re: Little Ivy survey (was: development process)
Posted by bhatia <Bh...@OFAC.CH>.
Thanks to all of you. You have well responded on what a build server should
do in the context of product development and I believe many are still in the
dark over the big picture, the real truth :-)
However, I still have questions related to working with Ivy in the Eclipse
workspace e.g.
1) After making changes to a project (checkout out or updated from CVS), do
I publish it to the repository with revision="CURRENT" or
revision="latest.integration" and then reference this dependency from a
dependant project from my workspace ? Is this the way to go ? So work on a
dependency, publish it and then reference it from a dependant project ?
Doesnt this make the development process longer in the Eclipse workspace ?
2) How can developers work on the HEAD using IvyDE, ant targets in the local
workspace and with the Ivy repository I have set up ?
e.g. Developer A gets a project from the HEAD, adds his changes, tests in
local, if all is OK, he commits to HEAD in CVS. At this point, should he
also publish this to the repository, if yes revision="HEAD" or
revsion="latest.integration"....
3) Similar questions on the branch. I saw that there is a branch attribute
documented on the website. So ,after making changes to a branch in Eclipse,
a developer publishes the version/tag he commits to CVS like
branch="branch-tag" or revision="branch-tag"...stuff like that...
I hope you understand that the questions I have are concerned with "how to
work in Eclipse with Ivy" rather than what the best practices of a build
processes are on the build server which you have very well responded to and
your response is a great starting point for me in the 2nd phase of this
project when I try to integrate Ivy in our continuous build process.
I hope my questions are making sense :-)
thanks
Xavier Hanin wrote:
>
> Thanks a lot for this detailed report, Matthias, I think it can help many
> users.
>
> To make it easier to find by users, I think it would be a nice idea to
> convert it to a little article. Do you have a blog? It would be a very
> interesting post, to which we could link from Ivy site.
>
> Xavier
>
> On 8/24/07, Matthias Kilian <ki...@outback.escape.de> wrote:
>>
>> On Fri, Aug 24, 2007 at 03:03:49AM -0700, bhatia wrote:
>> > How do we work in the Ivy world ? Checkout a project from CVS, compile
>> it
>> > thanks to IvyDE by retrieving dependencies, make changes to it in the
>> local
>> > workspace, then what ??? publish it with changes to the ivy repository
>> with
>> > rev="CURRENT"... ?? Same logic for the branch ? And when I am ready to
>> > commit and tag on a branch, I publish the branch with
>> rev="my-branch-tag" ?
>>
>> So, since Xavier wrote that a little survey would be welcome, and
>> since this survey may answer your questions, here's what we do.
>> YMMV.
>>
>> (Assuming development on the HEAD trunk for now, I'll describe when and
>> how we deal with branches in a minute)
>>
>> - Checkout or Update the sources, make the appropriate changes, build,
>> test, commit.
>>
>> - If everything looks well, trigger a release (major, minor or
>> patchlevel) on a dedicated build machine -- we're running
>> cruisecontrol on it, so for HEAD revisions we can use cruisecontrol's
>> JMX interface to trigger a build with a special target. We've a couple
>> of standard targets in some special build.xml that's imported in the
>> build scripts of all projects: release-major, release-minor,
>> release-patch, release-fix (the latter for hot fixes on a branch, see
>> below). The same set exists for milestone builds, but we don't use
>> this yet.
>>
>> - The release-* targets will do the following steps:
>> * cvs update
>> * Pull in the current version (major, minor, patch, fix) from a file
>> "version.properties".
>> * Calculate appropriate new version numbers (increase the requested
>> level, and set all lower levels to 0).
>> * Write the new version.properties.
>> * Run the normal build, including ivy resolution and retrieval. We
>> also include release information (status, revision, date, build
>> account) into the manifests of our applications.
>> * Make a backup copy of ivy.xml (to ivy.xml~). The important thing
>> here is that our project's ivy files typically don't have status,
>> rev etc. set, and also contain "latest.release" or "x.y.+"
>> revisions in their dependencies.
>> * Deliver the ivy file with appropriate status (currently always
>> "release", since we don't use milestone and integration builds
>> yet, as noted above).
>> * Publish the delivered ivy file and the artifacts.
>> * Commit the changed ivy.xml and version.properties with a proper
>> cvs log message (e.g. Release 0.8.15.0), and tag it
>> (with RELEASE_0_8_15_0 in this case).
>> * Move ivy.xml~ to ivy.xml, to get back the undelivered ivy file.
>> * Commit again, this time with "Unfreeze" as the cvs commit message.
>>
>>
>> That's all for releases on the HEAD trunk. When we need a hotfix
>> for an older revision (which happens quite often, since we're not
>> supposed to deploy our latest and greatest features without lots
>> of testing on dedicated QA machines), we proceed as following:
>>
>> - If it's the first hotfix for the revision currently running on our
>> production systems (e.g. RELEASE_0_8_15_0), check out / update to this
>> revision and create a new branch (BRANCH_0_8_15).
>>
>> - Update to the branch.
>>
>> - Modify, build, test, commit (on the branch). Developers must be take
>> special care about the ivy.xml they are using here -- it's the
>> delivered on, containing only fixed dependencies (no latest.* or
>> x.y.+). If that's not desired, the devlopers have to change
>> dependencies manually before committing their changes back to the
>> branch. Actually, we had a case two weeks ago where we *only*
>> changed dependencies for some hot fixes.
>>
>> - On the build machine, checkout that branch, then run ant as above with
>> the release-fix target. This does the same as the other release-*
>> targets.
>>
>>
>> This gives absolutely reproducable results, which is especially
>> important when you've rather long development cycles with the need
>> of beeing able to reproduce builds from several months ago to apply
>> bug fixes to them. One caveat when using branches for hotfixes like we
>> do: if you bump some dependency to a newer revision, double-check wether
>> all other dependencies are still at the correct revisions; you may have
>> to use force="true" on some dependencies. For example:
>>
>> - A-0.8.15.0 depends on B-1.2.3.0 and on C-7.4.2.8.
>> - B-1.2.3.0 depends on C-7.4.2.8, too.
>> - B-1.3.0.0. depends on C-8.0.0.0.
>> - When you now update A's dependency on B to 1.2.3.0, you'll get
>> C-8.0.0.0 when using the default conflict manager. This may or
>> may not lead to problems.
>>
>>
>> What's still on my TODO list are the mentioned integration and milestone
>> builds and a better integration of ivy and cruisecontrol (or any other
>> CI-like system).
>>
>> Milestone builds would be nice, since we could test them on the QA
>> machines and then, if everything is ok, switch them from milestone
>> to release status, using the same mechanism as above. Unfortunately,
>> there're also some problems, since we deploy on WebSphere Application
>> Server, but we don't put EJB and resource bindings into our builds,
>> so this is kind of error-prone, and it's more safe to just copy the
>> tested applications from QA to the production machines.
>>
>> I'm also planning to support pure integration builds on the CI
>> machine, so tightly coupled projects will be tested without having
>> to make and tag a new release all time.
>>
>> Oh, and one final remark: NEVER EVER ship code built only in your
>> IDE. It's not reproducible. I've even seen projects that were not
>> buildable on any except a single developer's machine. Even if IvyDE
>> helps a lot, there may still be problems, like a forgotten commits,
>> different locale settings, or just sloppy developers not caring at
>> all about quality. So, ALWAYS use a dedicated build machine that
>> ONLY builds, tags and publishes releases.
>>
>> Ciao,
>> Kili
>>
>> --
>> I don't care what gutter Wim is lying in, make sure he's lying on
>> his back, please!
>> -- Marc Espie on undeadly.org
>>
>
>
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://incubator.apache.org/ivy/
> http://www.xoocode.org/
>
>
--
View this message in context: http://www.nabble.com/development-process-tf4322737.html#a12313283
Sent from the ivy-user mailing list archive at Nabble.com.
Re: Little Ivy survey (was: development process)
Posted by Xavier Hanin <xa...@gmail.com>.
On 8/24/07, Matthias Kilian <ki...@outback.escape.de> wrote:
>
> On Fri, Aug 24, 2007 at 03:36:01PM +0200, Xavier Hanin wrote:
> > To make it easier to find by users, I think it would be a nice idea to
> > convert it to a little article. Do you have a blog? It would be a very
> > interesting post, to which we could link from Ivy site.
>
> Well, my "blog" is basically a huge plain text file, so I made this
> survey a separate (small) plain text file (and a HTML version created
> with txt2tags)
Great, I've posted a link to dzone.com:
http://www.dzone.com/links/reproducable_releases_using_ivy_ant_and_cvs.html
Vote for it :-)
Xavier
;-)
>
> HTML: http://dead-parrot.de/ivy/
> plain text: http://dead-parrot.de/ivy/ivy.txt
>
> I'll probably update this from time to time, and I'll also add some
> samples, ant scripts etc, but I've to ask our customer first.
>
> Ciao,
> Kili
>
> --
> It's a Barrier Of Entry issue: if you can't figure out which floppy
> to boot from, go run Gentoo.
> -- Matthew Jenove on tech@openbsd.org
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://incubator.apache.org/ivy/
http://www.xoocode.org/
Re: Little Ivy survey (was: development process)
Posted by Matthias Kilian <ki...@outback.escape.de>.
On Fri, Aug 24, 2007 at 03:36:01PM +0200, Xavier Hanin wrote:
> To make it easier to find by users, I think it would be a nice idea to
> convert it to a little article. Do you have a blog? It would be a very
> interesting post, to which we could link from Ivy site.
Well, my "blog" is basically a huge plain text file, so I made this
survey a separate (small) plain text file (and a HTML version created
with txt2tags)
;-)
HTML: http://dead-parrot.de/ivy/
plain text: http://dead-parrot.de/ivy/ivy.txt
I'll probably update this from time to time, and I'll also add some
samples, ant scripts etc, but I've to ask our customer first.
Ciao,
Kili
--
It's a Barrier Of Entry issue: if you can't figure out which floppy
to boot from, go run Gentoo.
-- Matthew Jenove on tech@openbsd.org
Re: Little Ivy survey (was: development process)
Posted by Xavier Hanin <xa...@gmail.com>.
Thanks a lot for this detailed report, Matthias, I think it can help many
users.
To make it easier to find by users, I think it would be a nice idea to
convert it to a little article. Do you have a blog? It would be a very
interesting post, to which we could link from Ivy site.
Xavier
On 8/24/07, Matthias Kilian <ki...@outback.escape.de> wrote:
>
> On Fri, Aug 24, 2007 at 03:03:49AM -0700, bhatia wrote:
> > How do we work in the Ivy world ? Checkout a project from CVS, compile
> it
> > thanks to IvyDE by retrieving dependencies, make changes to it in the
> local
> > workspace, then what ??? publish it with changes to the ivy repository
> with
> > rev="CURRENT"... ?? Same logic for the branch ? And when I am ready to
> > commit and tag on a branch, I publish the branch with
> rev="my-branch-tag" ?
>
> So, since Xavier wrote that a little survey would be welcome, and
> since this survey may answer your questions, here's what we do.
> YMMV.
>
> (Assuming development on the HEAD trunk for now, I'll describe when and
> how we deal with branches in a minute)
>
> - Checkout or Update the sources, make the appropriate changes, build,
> test, commit.
>
> - If everything looks well, trigger a release (major, minor or
> patchlevel) on a dedicated build machine -- we're running
> cruisecontrol on it, so for HEAD revisions we can use cruisecontrol's
> JMX interface to trigger a build with a special target. We've a couple
> of standard targets in some special build.xml that's imported in the
> build scripts of all projects: release-major, release-minor,
> release-patch, release-fix (the latter for hot fixes on a branch, see
> below). The same set exists for milestone builds, but we don't use
> this yet.
>
> - The release-* targets will do the following steps:
> * cvs update
> * Pull in the current version (major, minor, patch, fix) from a file
> "version.properties".
> * Calculate appropriate new version numbers (increase the requested
> level, and set all lower levels to 0).
> * Write the new version.properties.
> * Run the normal build, including ivy resolution and retrieval. We
> also include release information (status, revision, date, build
> account) into the manifests of our applications.
> * Make a backup copy of ivy.xml (to ivy.xml~). The important thing
> here is that our project's ivy files typically don't have status,
> rev etc. set, and also contain "latest.release" or "x.y.+"
> revisions in their dependencies.
> * Deliver the ivy file with appropriate status (currently always
> "release", since we don't use milestone and integration builds
> yet, as noted above).
> * Publish the delivered ivy file and the artifacts.
> * Commit the changed ivy.xml and version.properties with a proper
> cvs log message (e.g. Release 0.8.15.0), and tag it
> (with RELEASE_0_8_15_0 in this case).
> * Move ivy.xml~ to ivy.xml, to get back the undelivered ivy file.
> * Commit again, this time with "Unfreeze" as the cvs commit message.
>
>
> That's all for releases on the HEAD trunk. When we need a hotfix
> for an older revision (which happens quite often, since we're not
> supposed to deploy our latest and greatest features without lots
> of testing on dedicated QA machines), we proceed as following:
>
> - If it's the first hotfix for the revision currently running on our
> production systems (e.g. RELEASE_0_8_15_0), check out / update to this
> revision and create a new branch (BRANCH_0_8_15).
>
> - Update to the branch.
>
> - Modify, build, test, commit (on the branch). Developers must be take
> special care about the ivy.xml they are using here -- it's the
> delivered on, containing only fixed dependencies (no latest.* or
> x.y.+). If that's not desired, the devlopers have to change
> dependencies manually before committing their changes back to the
> branch. Actually, we had a case two weeks ago where we *only*
> changed dependencies for some hot fixes.
>
> - On the build machine, checkout that branch, then run ant as above with
> the release-fix target. This does the same as the other release-*
> targets.
>
>
> This gives absolutely reproducable results, which is especially
> important when you've rather long development cycles with the need
> of beeing able to reproduce builds from several months ago to apply
> bug fixes to them. One caveat when using branches for hotfixes like we
> do: if you bump some dependency to a newer revision, double-check wether
> all other dependencies are still at the correct revisions; you may have
> to use force="true" on some dependencies. For example:
>
> - A-0.8.15.0 depends on B-1.2.3.0 and on C-7.4.2.8.
> - B-1.2.3.0 depends on C-7.4.2.8, too.
> - B-1.3.0.0. depends on C-8.0.0.0.
> - When you now update A's dependency on B to 1.2.3.0, you'll get
> C-8.0.0.0 when using the default conflict manager. This may or
> may not lead to problems.
>
>
> What's still on my TODO list are the mentioned integration and milestone
> builds and a better integration of ivy and cruisecontrol (or any other
> CI-like system).
>
> Milestone builds would be nice, since we could test them on the QA
> machines and then, if everything is ok, switch them from milestone
> to release status, using the same mechanism as above. Unfortunately,
> there're also some problems, since we deploy on WebSphere Application
> Server, but we don't put EJB and resource bindings into our builds,
> so this is kind of error-prone, and it's more safe to just copy the
> tested applications from QA to the production machines.
>
> I'm also planning to support pure integration builds on the CI
> machine, so tightly coupled projects will be tested without having
> to make and tag a new release all time.
>
> Oh, and one final remark: NEVER EVER ship code built only in your
> IDE. It's not reproducible. I've even seen projects that were not
> buildable on any except a single developer's machine. Even if IvyDE
> helps a lot, there may still be problems, like a forgotten commits,
> different locale settings, or just sloppy developers not caring at
> all about quality. So, ALWAYS use a dedicated build machine that
> ONLY builds, tags and publishes releases.
>
> Ciao,
> Kili
>
> --
> I don't care what gutter Wim is lying in, make sure he's lying on
> his back, please!
> -- Marc Espie on undeadly.org
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://incubator.apache.org/ivy/
http://www.xoocode.org/
Re: Little Ivy survey (was: development process)
Posted by Jing Xue <ji...@digizenstudio.com>.
Quoting Matthias Kilian <ki...@outback.escape.de>:
> - Modify, build, test, commit (on the branch). Developers must be take
> special care about the ivy.xml they are using here -- it's the
> delivered on, containing only fixed dependencies (no latest.* or
> x.y.+). If that's not desired, the devlopers have to change
> dependencies manually before committing their changes back to the
> branch.
Very interesting point - and perhaps extremely important for anyone
who hopes for reproducible builds. Thanks for bringing it up, Matthias.
I wonder whether ivy could provide some support to "freeze the
dependencies". OTOH, something alone the lines of adding a
"freeze-dependencies" attribute to ivy.xml, which when set to true
would cause the published ivy.xml to have static dependencies as
resolved. (It's probably a lot more complicated than that. I'm just
throwing an idea out there)
> Oh, and one final remark: NEVER EVER ship code built only in your
> IDE. It's not reproducible. I've even seen projects that were not
> buildable on any except a single developer's machine.
Hear, hear. I once worked on a project where the _production support_
people used Eclipse to build the war files to be deployed to the
production servers. Let's just say... man, all those sleepless release
nights! 8-)
Cheers.
--
Jing Xue
Little Ivy survey (was: development process)
Posted by Matthias Kilian <ki...@outback.escape.de>.
On Fri, Aug 24, 2007 at 03:03:49AM -0700, bhatia wrote:
> How do we work in the Ivy world ? Checkout a project from CVS, compile it
> thanks to IvyDE by retrieving dependencies, make changes to it in the local
> workspace, then what ??? publish it with changes to the ivy repository with
> rev="CURRENT"... ?? Same logic for the branch ? And when I am ready to
> commit and tag on a branch, I publish the branch with rev="my-branch-tag" ?
So, since Xavier wrote that a little survey would be welcome, and
since this survey may answer your questions, here's what we do.
YMMV.
(Assuming development on the HEAD trunk for now, I'll describe when and
how we deal with branches in a minute)
- Checkout or Update the sources, make the appropriate changes, build,
test, commit.
- If everything looks well, trigger a release (major, minor or
patchlevel) on a dedicated build machine -- we're running
cruisecontrol on it, so for HEAD revisions we can use cruisecontrol's
JMX interface to trigger a build with a special target. We've a couple
of standard targets in some special build.xml that's imported in the
build scripts of all projects: release-major, release-minor,
release-patch, release-fix (the latter for hot fixes on a branch, see
below). The same set exists for milestone builds, but we don't use
this yet.
- The release-* targets will do the following steps:
* cvs update
* Pull in the current version (major, minor, patch, fix) from a file
"version.properties".
* Calculate appropriate new version numbers (increase the requested
level, and set all lower levels to 0).
* Write the new version.properties.
* Run the normal build, including ivy resolution and retrieval. We
also include release information (status, revision, date, build
account) into the manifests of our applications.
* Make a backup copy of ivy.xml (to ivy.xml~). The important thing
here is that our project's ivy files typically don't have status,
rev etc. set, and also contain "latest.release" or "x.y.+"
revisions in their dependencies.
* Deliver the ivy file with appropriate status (currently always
"release", since we don't use milestone and integration builds
yet, as noted above).
* Publish the delivered ivy file and the artifacts.
* Commit the changed ivy.xml and version.properties with a proper
cvs log message (e.g. Release 0.8.15.0), and tag it
(with RELEASE_0_8_15_0 in this case).
* Move ivy.xml~ to ivy.xml, to get back the undelivered ivy file.
* Commit again, this time with "Unfreeze" as the cvs commit message.
That's all for releases on the HEAD trunk. When we need a hotfix
for an older revision (which happens quite often, since we're not
supposed to deploy our latest and greatest features without lots
of testing on dedicated QA machines), we proceed as following:
- If it's the first hotfix for the revision currently running on our
production systems (e.g. RELEASE_0_8_15_0), check out / update to this
revision and create a new branch (BRANCH_0_8_15).
- Update to the branch.
- Modify, build, test, commit (on the branch). Developers must be take
special care about the ivy.xml they are using here -- it's the
delivered on, containing only fixed dependencies (no latest.* or
x.y.+). If that's not desired, the devlopers have to change
dependencies manually before committing their changes back to the
branch. Actually, we had a case two weeks ago where we *only*
changed dependencies for some hot fixes.
- On the build machine, checkout that branch, then run ant as above with
the release-fix target. This does the same as the other release-*
targets.
This gives absolutely reproducable results, which is especially
important when you've rather long development cycles with the need
of beeing able to reproduce builds from several months ago to apply
bug fixes to them. One caveat when using branches for hotfixes like we
do: if you bump some dependency to a newer revision, double-check wether
all other dependencies are still at the correct revisions; you may have
to use force="true" on some dependencies. For example:
- A-0.8.15.0 depends on B-1.2.3.0 and on C-7.4.2.8.
- B-1.2.3.0 depends on C-7.4.2.8, too.
- B-1.3.0.0. depends on C-8.0.0.0.
- When you now update A's dependency on B to 1.2.3.0, you'll get
C-8.0.0.0 when using the default conflict manager. This may or
may not lead to problems.
What's still on my TODO list are the mentioned integration and milestone
builds and a better integration of ivy and cruisecontrol (or any other
CI-like system).
Milestone builds would be nice, since we could test them on the QA
machines and then, if everything is ok, switch them from milestone
to release status, using the same mechanism as above. Unfortunately,
there're also some problems, since we deploy on WebSphere Application
Server, but we don't put EJB and resource bindings into our builds,
so this is kind of error-prone, and it's more safe to just copy the
tested applications from QA to the production machines.
I'm also planning to support pure integration builds on the CI
machine, so tightly coupled projects will be tested without having
to make and tag a new release all time.
Oh, and one final remark: NEVER EVER ship code built only in your
IDE. It's not reproducible. I've even seen projects that were not
buildable on any except a single developer's machine. Even if IvyDE
helps a lot, there may still be problems, like a forgotten commits,
different locale settings, or just sloppy developers not caring at
all about quality. So, ALWAYS use a dedicated build machine that
ONLY builds, tags and publishes releases.
Ciao,
Kili
--
I don't care what gutter Wim is lying in, make sure he's lying on
his back, please!
-- Marc Espie on undeadly.org