jpabloae.blog

Release Engineering at Openbravo

Towards a better Openbravo ERP release process

Openbravo ERP 2.50 has a time based release plan. This helps us get bug fixes and new features into our user’s hands more quickly and improve our planning process.

Up to now we’ve been releasing Maintenance Packs on a monthly basis. However we have detected some improvement areas, mainly two:

  1. We want to release like a clock:  same time, same day, every month. Everyone gets benefited by this:
    • End users appreciate knowing the release dates without even reading a release calendar. They simply know that they’ll have an update at the end of every month.
    • Our engineering team can organize more effectively: developers, QA, Support, Release Management.
  2. Developers should know what commits they push go into what release. This way they can organize their work more efficiently.

So let’s start! We already have the list of desired improvements and we know that we need to set the key dates. So first we need to identify the different kind of events involved in the development process:

  • Regular commits (e.g. bugfixes or small features).
  • Large project merges (e.g. a new large feature).
  • QA automatic tests.
  • Feature freeze for the release.
  • Release packaging.
  • QA manual tests.
  • Publish the release.

Now we need to set some dates and deadlines. The QA manual work – bug found – fix it loop lasts around 10 days. So the freeze and packaging should be before the 20th. And we want to provide a guarantee to developers, so that they know which commits go into what release. Here’s a proposal:

  • All the commits pushed before the 15th of a month will go into that month’s release. We’ll make sure all the tests are passed, working together with the developers in case there’s a failure.
  • We’ll freeze the code the 18th and start the packaging right after this moment. This means we have 3 days to make the code pass all the automatic test suite. It should be more than enough. It also means that commits pushed between the 15th and the 18th might go into that month’s release. If it passes the tests of course.
  • From that moment on QA can start the manual work. If they find issues the affected developer will work on the fix and they’ll iterate on this process till QA happy is happy with the result.
  • Afterwards the Release Management team can publish the release.

And last but not least, project merges tend to create instabilities in the code main line, compared to having no reintegrations at all. So taking this into account the project merges must be done a specific time frame: from the 22nd of one month until the 5th of the next one. So that we give it enough room (10 days) to get the code stable for the freeze time.

We can see these policies summarized in the following graph:

Openbravo ERP 2.50 release timeline

Improving a release process is usually an evolution, not a revolution. And I believe this is the first step towards better timely releases.

Advertisements

Written by jpabloae

31/03/2010 at 16:21

Posted in openbravo

Tagged with ,

2 Responses

Subscribe to comments with RSS.

  1. 1 month release cycle seems quite tough for me. It allows to implement small/quick improvements, but it is hard to implement serious refactoring for old and dusty places.

    Probably practice used for Linux kernel for 3 months cycle would be better.

    Valdis

    01/04/2010 at 10:12

  2. Hi Valdis,

    We use Mercurial for our source code management, and its branching capabilities make it easy to do refactoring in a separate branch. This allows us to implement new features and big changes in an isolated and comfortable way. And whenever these branches are ready we reintegrate them into the main line and it goes into that month’s release. From this side it’s somehow similar to what the Kernel does with Git. It’s an advantage distributed SCMs offer.

    There are various approaches to this. We try to follow the “release early, release often” policy, so that our users can get our developments as quickly as possible. The “early” and “often” terms are not the same for everybody, it’s 1 month in our case :-)

    Thanks for your comment.

    jpabloae

    01/04/2010 at 21:37


Comments are closed.

%d bloggers like this: