jpabloae.blog

Release Engineering at Openbravo

Archive for April 2009

The new packaging of ERP 2.50

Openbravo ERP has replaced its installers with virtual appliances and source code tarballs. We believe this is a major step forward. Why? This post explains the rationale behind this decision.

In 2.1x and 2.2x Openbravo ERP was deployed using Ant Installer. In 2.3x and 2.40 we switched to a binary installer technology. Starting from 2.50, Openbravo ERP has changed its packaging formats.

I remember having a brainstorming session with a project colleague, analyzing what we could improve in the overall installation and release process. That is, from the moment Release Management takes the code from QA, till users install it in their computers. The discussion led to the following conclusions:

  1. What’s the hardest part in the Openbravo ERP deployment? Certainly not the ERP, but all the software stack it relays on: Ant, JDK, Tomcat, PostgreSQL/Oracle and some extra adjustment in the operating system to make Openbravo ERP happy (system variables, permissions, etc).
  2. Let’s think about average computer users, with experience as an ERP user. They have a good ERP functional knowledge, but they don’t necessarily know how to install, configure and optimize Apache Tomcat, PostgreSQL, Ant, JDK, system variables and user permissions. They simply are not interested nor have the time to deal with that. How would the installation process look like for these kind of users? They’ll most probably give up after the second or third problem.
  3. Let’s think about advanced computer users. Does the installer help them deploy Openbravo ERP? The installer basically performs two tasks: double check that all the required component’s are sane and build the ERP from sources. All these checks were hidden behind the GUI and the 2.40 version did not have a command line equivalent. In 2.50 this can be summarized in 2 commands:
  4. ant diagnostic
    ant install.source
    

    Advanced users know what they’re doing and they prefer running these 2 commands by hand. Hiding this behind a GUI does not help them at all. In fact they dislike it.

  5. How fast is the 2.40 release process? The installers or any other packaging deliverables must not be the bottleneck. Ideally, if for some reason the QA process fails it must be because of an ERP bug and not because of a packaging problem. This was far from being truth. The release process was a pain and slow.

So having a look at the 4 points, we realized the installer failed in all of them. It doesn’t matter what installer technology we used, it just was not the right tool for us. Some of the problems of 1) and 2) could be solved by creating a one-click installer that deployed and configured all the technology stack plus Openbravo ERP. But this has mainly 2 problems:

  • It’s not useful for production systems, where users want to use the Tomcat, Ant, JDK, PostgreSQL, etc. provided by their operating system’s package manager. This allows them to install and update those packages very easily. This is understandable and in fact recommended.
  • We found out that virtual appliances do a better job in terms of ease of deployment and immediateness. And most importantly, we provide the users exactly the same environment we have tested. And not only that, it solved our 4th problem. The release process has been immensely simplified. QA does all the ERP testing in appliances, and when the product is ready Release Management creates the final appliances with the final ERP code. A smoke test gives the green light to publish the release.

So the virtual appliances solve the problems for the average computer users (points 1 and 2), and also the release problems (point 4). For advanced users (point 3) we offer them detailed installation instructions and the source code in two formats: tarballs and direct access to the main Mercurial repository.

Wondering how this affects the upgraders? Good news, starting from 2.50 upgrades are managed through the Module Management Console. In other words, Openbravo ERP is capable of updating itself and there is no need to have external upgraders.

Next steps? Package and include Openbravo ERP in all the possible Linux/BSD official repositories (Debian, Fedora/Centos/RedHat, FreeBSD, Gentoo, openSUSE, Ubuntu, etc).

Written by jpabloae

27/04/2009 at 08:47