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 <[EMAIL PROTECTED]> 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.
