On Model-Based Modelling Builds

In principle, I think most people agree that builds should be a shared responsibility, i.e., everyone should be equally able to do builds and the effort to do so should be equally distributed. Unfortunately, equal effort can sometimes result in nobody doing anything at all, because hardly anybody wants to! Trying to do the right thing in this context has launched many an accidental career in release engineering. So the best we can do is make the build effort as efficient as possible, giving everyone less reason to complain.

This has become essential for the Modeling project, which now has roughly sixty active sub-projects, many of which are one or two committer efforts with no way to justify a full-time release engineer. With that in mind, the Modeling PMC has recently decided to standardize on one build engine - Buckminster (often affectionately referred to as "Bucky") - for all of its projects, starting with the Helios release.

Why standardize? The obvious reason is to spread the joy of supporting build infrastructure across multiple projects. Less obvious, but no less important, is our not-so-distant goal of having a single build chain that can support true continuous integration for the entire Modeling stack, which should be much simpler if all of the builds are using the same technology.

Why Buckminster? The people and technology were familiar, so that was obviously a factor. But we tried to make as objective a decision as possible. Key considerations were the following:

• CDO and Teneo, having independently Buckminsterized last year, were enthusiastic supporters and made a strong case for the benefits.

• Unlike the alternatives, Buckminster is model-driven (it uses EMF). This makes it a no-brainer for us modeling zealots.

• We wanted to be able to reuse existing metadata, which is an advantage that Bucky has over Maven alternatives.

• Having a build that runs the same way in a developer workspace as on the server makes it much more efficient to spread build responsibilities across the teams.

• Adopting Buckminster gets us a step closer to using b3 (Buckminster will soon be supported as a build execution engine for b3), which we think is the future.

• Last, but not least, someone (i.e., Cloudsmith) stepped up to do the work!

Upon closer inspection, Buckminster had a few holes that needed filling. Support for automated build identifier generation/insertion, CVS tagging, and dependency version range management were non-negotiable for build slackers like Ed Merks (not to mention the rest of us mere mortals), and automated build promotion via Hudson was also highly desireable. So we rushed these changes through in time for Helios.

The effort of migrating from various older build systems (PDE Build, Athena, and variants) was not inconsequential. However, it ended up being relatively painless. One reason I can say this is because Michal Ruzicka (Buckminster committer and my colleague at Cloudsmith) did pretty much all the work. Michal was able to Buckminsterize most of the key Modeling projects in roughly a month of effort, which was pretty amazing, all things considered. Thanks again, Michal!

The first Buckminster build of EMF went live with M7 two weeks ago and the many other Modeling projects will soon follow. We'll be cutting a few key projects over as Helios heads toward completion. A number of others have chosen to postpone switching until just after the Helios release.

We'll send out periodic updates as the individual projects adopt the new build system over the coming weeks, so stay tuned for more details. In the meantime, if you want to hear more about what we're doing (and how), let us know!

 

From http://kenn-hussey.blogspot.com/2010/05/on-model-based-modeling-builds.html