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

Advertisements