How we do release engineering?

One of the challenging parts at Eclipse is doing the release engineering work. Large projects may have dedicated resources as well as well established processes. We don’t. However, I like the way the Eclipse project is doing their builds. They have (over simplified) a “version.properties” file that contains a list of bundles and a SCM tag to use. They are called map files and they drive the build.

For a long piece of Eclipse history, the map files were tagged manually by hand. Whenever a committer modified a bundle (aka. plug-in or feature). He also had to release those changes by tagging the bundle and updating the map file. When the Eclipse project migrated to Git they automated this process. A script is started before the real build begins. The script scans a branch for new commits since the last tag. If any new commits are found, the repository will be tag with a new tag and the map file will be updated.

I started migrating Gyrex to Git last week. The CVS to Git part was easy. Our build is running again. Thanks to an update to PDE Build it fully supports Git map files. Our process has always been as close to the Eclipse project as possible. We also use the map files which drive our build. We also used to tag our (CVS) projects by hand and we also used to update the map files by hand. Now with the change to Git we’ll also stop doing that.

I took the scripts from the Eclipse project and adapted them. We don’t run the script as part of our Hudson build job. Due to security concerns, the Hudson machines aren’t able to push changes back to Git repos. Thus, I run the tagging scripts on build.eclipse.org by cron. At the end of the run, a Hudson build will be triggered by the script via and Hudson API call.

You can find the scripts here:
gyrex-releng.git/tree/org.eclipse.gyrex.releng/builder/environments/build.eclipse.org/tagging

About these ads

3 Responses to How we do release engineering?

  1. Thanks for describing how gyrex is doing their releng. This is definitely one of the most challenging (because unfamiliar) areas and examples and best practices are very appreciated. Workflows how to develop for 37,38, and 42 in parallel would also be welcome.

    I’ve some hope that Eclipse CBI will help a bit here (for the build parts)…

  2. Remember to update your project metadata on portal.eclipse.org so we get an accurate count on the SCM Countdown…

    http://eclipse.org/projects/scmcountdown.php

  3. Pingback: How we do release engineering? | Eclipse | Syngu

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: