Tuesday, March 29, 2011

Branched Appliance Development

We've recently introduced a new beta feature, allowing you to clone a specific version of one of your appliances to a new appliance; effectively creating a branch. This feature is at the heart of any strategy beyond rudimentary mainline development.

The following is an example of how the current Studio feature set can be used for a release-oriented branching strategy.

Lets assume an appliance, MyAppliance, which I intend to develop over a long term using my own milestones, and share on SUSE Gallery.  I also intend to offer updates with bugfixes on each milestone release.

I will develop on MyAppliance, treating it as a mainline branch.  When I reach my version 1 milestone, instead of immediately sharing that build to the Gallery, I will clone that version to a new appliance: MyAppliance 1.0, perform a build without making any changes, and share that build.  In the Gallery, it will appear as "MyAppliance 1.0" with one shared build: version 1.0.0.

While v1.0 is out in the wild, I can return to my mainline branch, MyAppliance, and continue development towards my next milestone.  When (not if... but when) a bug is reported on my 1.0 release, I can switch over to that branch (appliance MyAppliance 1.0) and work through to a fix.  When I'm satisfied with the quality of the fix,  I can release an update on that branch, sharing the build to the Gallery.  In the Gallery, I will now have "MyAppliance 1.0" with two builds: the default (1.1.0) and a prior build (1.0.0).

The bug that was fixed in "MyAppliance 1.0" probably exists on my mainline branch as well.  Unfortunately, Studio doesn't (yet) have diff/merge functionality, but I can view the configurations, and the changelogs, and determine exactly what needs to be done to resolve the issue on my mainline branch as well.  If I have already made any other milestone branches ("MyAppliance 2.0" in the diagram), I should manually apply the update to those branches as well.

This process mirrors common behavior for projects of nearly any scale; you can adjust to your workflow simply by changing the point at which you branch. Two other common options are branching at the beginning of a version cycle (alpha branching) or when a milestone is feature-complete (beta branching).

1 comment:

  1. example what i would like to see is:
    - susestudio build both for 32bit and 64bit arch. with one single appliance.
    - one single appliance can have multiple version. example, cd version with limited apps and dvd version with full apps installed.
    - multiple branches which all branches always sync with main appliance. say, i have 'minimal-X-only' applliance. then i can have kde and gnome branches. then when the install firefox in my 'minimal-X-only' appliance, it (firefox) automatically installed also to kde and gnome branches.



© 2013 SUSE