This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Line Ups, Reported by Reinout Heeck
Feed Title: Travis Griggs - Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/travis-rss.xml
Feed Description: This TAG Line is Extra
Last week, there was an interesting blitz of comments in one of Rich Demers blogs. Reinout Heeck had a lot of interesting things to point out; one that intrigued me, was his company's adoption and use of "...lineups as implemented by Cees de Groot..." I had seen these a while back, but not kept up to date. I emailed Reinout and asked him to write more about these things. He not having a blog right now, I told him I'd host his comments for him and he kindly obliged. Thank you Reinout for the very informative report. I'll be taking a closer look at Lineups real soon now. My only remaining question is... how is "Heeck" pronounced?
And now for the very good report...
In our shop we have found Store's bundles to be troublesome for a variety of reasons. Here are the three important ones:
Bundles require that their content be defined only once, IOW package overrides coexisting with an earlier definition in one bundle is not supported by Store. This means that bundles cannot be used to version the state of (library code)+(patches)+(our code).
Bundles turn into a versioning bottleneck when the team is larger than a couple of people (specifically in a "everybody owns the code" process).
The tree presentation of Pundles in the tools lures people to use them as classifiers rather than for code layer management. The Pollock project for instance uses the Pundle hierarchy to classify agents vs artists instead of modeling the code layering.
Editors Comment. I couldn't agree more with these. Well and succinctly put.
We pretty much abandoned Bundles and started to use the prerequisite chain of Packages to manage our code configurations. In various discussions this has been referred to as "lineups" but in the public Store repository the code is called TIO-Store Extensions courtesy Cees de Groot.
When you load this (tiny) package you get an extra item Publish Configuration in the pundle hierarchy menu. Assuming you have a package 'MyPackage' selected this will recursively walk through the prerequisites of 'MyPackage' and record which versions are loaded in the image. If any of those prerequisites are unpublished it will open a publish dialog on them and abort, else it will continue by updating a package named 'MyPackage Configuration'. This configuration package only contains a prerequisite list specifying all recorded prerequisites with their version.
Early in use we found it hard to discern which packages play the role of configuration generator so we introduced a naming convention for these by having their name (confusingly) end in 'Config'. We leave these packages empty, they only specify top level prerequisites without version. We also souped up the RB to recognize both these conventions and show specialized icons.
Not much later it turned out that what we wanted to version was what our staging and build bots were doing, so in practice humans don't use the new menu item much. Instead the bots turn out to be doing the publishing of configurations. Humans are forced to keep the dependencies straight (which isn't a bad thing.
Moving to configurations has cracked the three problems I mentioned above:
A configuration can "contain" multiple package overrides
The versioning bottleneck is gone since there is no hierarchy of bundles that needs merging into.
We did a "step back" in the browser in that the package list is now so overpopulated that we cannot navigate it with mouse gestures. The usage pattern has turned into that of a searchable keyword database (by use of the "find package" dialog). This shift of usage has forced package naming sanity onto us, again not a bad thing.
Since configurations are just Packages they can be used as prerequisites too, IOW we got configuration composition (with a well-understood load ordering) for free as well.
If you step back you may notice that there is almost zero code involved. Most of the shift revolves around conventions that form a framework with very simple semantics once bundles are no longer involved.
Previous Topic
