Release Engineering at Openbravo

Archive for October 2010

We’re branching the Openbravo 3.0 code line

Up to now the 2.50 and 3.0 versions of Openbravo have shared the same Core. “Core” is what we call the most essential module of Openbravo, the one that includes standard functionality like Financial or Sales Management.

If 2.50 and 3.0 have shared the same Core, what’s the difference between them? While a default 2.50 installation includes just Core, the 3.0 version includes a distribution of several modules: right now “Core” plus 16 more.

In terms of source code management we decided to keep one code line as much time as possible, simply because it reduces our developer’s backporting work. Backporting basically means that a bug fixed in 3.0 should also be fixed in 2.50 (if it affects 2.50, of course).

The news is that we have now reached the point where the 2.50 and 3.0 Core cannot share the same code any more. So we are planning to branch the 2.50 and 3.0 code-lines around the 15th of November.

And that’s not all about it. According to our plans we’ll be releasing version 3.0RC3 precisely the 15th of November. The extra news is that we’ll be having two 2.50 MPs on November, 2.50MP24 and 2.50MP25. Why? Simple, as the “Core” is still shared between 2.50 and 3.0, version 3.0RC3 will be needing some code not ready yet in 2.50MP23. And this is why we need 2.50MP24.

In terms of timing, we’ll freeze 2.50MP24 the 1st of November and release it the 15th of that month. So are we releasing both 2.50MP24 and 3.0RC3 the 15th of November? That’s right, and starting from that point the 2.50 and 3.0 Core code-lines will follow their own paths.

Lastly a couple of notes about how this affects to the 2.50 to 3.0 upgrade process:

  1. While we are introducing a separate branch to simplify our code management, 3.0 is just another version of core and updating from 2.50 MPx to 3.0 is not any different than updating from 2.50 MPx to 2.50 MPy. In both cases, it is a full code replacement of core and, as long as the system has been configured using the principles of modularity and does not contain any core customization, system configurations and extensions are going to be preserved during the upgrade.
  2. We will be cleaning the 3.0 core more aggressively than we are doing with the 2.50 core. Because of that, we can expect a higher volume of API changes in the 3.0 code line for the next few months and up to general availability date. However, we will continue to be conservative in 3.0 as well and accept only low risk API changes in an effort to minimize the chances to break module dependencies.  3.0 API changes will be listed in the Release Notes and users intending to upgrade from 2.50 are encouraged to monitor those notifications.

Written by jpabloae

18/10/2010 at 17:33

Posted in openbravo

Tagged with , , , ,

Sizing Openbravo: the art of choosing the right hardware

Let’s say you’ve been working hard customizing Openbravo for a customer. And now you’d like to deploy it, so that the customer can start using it immediately. Next step? You go ahead and start installing the ERP on a server… wait! Not yet! You first need to think about the hardware, don’t you? Not so relevant nowadays? A commodity? Try to answer these questions and you’ll see why it matters:

  • How many employees does the company have?
  • From these employees, how many of them will use the ERP?
  • From these users, could you classify them depending on the amount of time and intensity they’ll devote to the ERP?
  • How do the most typical user flows look like? Standard ERP flows? Customized ones? Heavy report generation or long processes?

As you can imagine the hardware requirements differ quite significantly depending if you need to support 5, 20 or 100 concurrent users.

And let me ask you two additional questions:

  • Do you care about saving costs?
  • Do you like the feelings (aka headaches) arisen when you notice that your server just cannot cope with all the requests in the ERP? Imagine you’ve just bought some new hardware and it’s not enough. Even worse, the customer can no longer work under those conditions, they’re unhappy because of having to buy new hardware again and they do not trust your abilities to choose the right hardware this time.

“Well, of course I care about costs, my time and the service level I provide to my customers! Are you kidding?”

OK, I might have dramatized it a bit. Have I? If you’ve ever participated in an ERP implementation process, you’ll know that these things happen. Obviously no one chooses to consciously increase the project’s costs, look for headaches and decrease the overall customer satisfaction. But these might be some of the consequences of incorrectly sizing your Openbravo installation.

Sizing? Sizing, you say? A sizing is an approximation of the hardware resources required to support a specific software implementation, in this case Openbravo. And I have good news for you, for all these inconveniences can be avoided by using the Sizing Tool we’ve just developed for you!

In a nutshell, you simply tell the tool how many concurrent users you want to support and it tells you what hardware you can use. And in case you want to calculate it using your own flows, it’s enabled to allow that as well.

To give some of the behind the scenes details, we have written test cases for the most common Openbravo flows using a performance benchmarking tool called JMeter. This, summed to our experience with real customers has outcome in the Sizing Tool and Guidelines.

Additionally there’s some interesting data we have proved with this tool. For instance we’ve been specially pleased to see that Openbravo supports 100-250 concurrent users without a hitch (given the proper hardware, of course).

This tool is available for the Openbravo partners. What are you waiting for? Don’t miss it, check it out, it’s in the Partner Portal, under the Resources & Assets -> Delivery Materials sections.

Written by jpabloae

05/10/2010 at 19:15

Posted in openbravo

Tagged with ,