jpabloae.blog

Release Engineering at Openbravo

Posts Tagged ‘Mercurial

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.
Advertisements

Written by jpabloae

18/10/2010 at 17:33

Posted in openbravo

Tagged with , , , ,

On demand branch testing for Openbravo developers

These have been some hard working but passionate weeks for Ken, an Openbravo ERP Core developer. He’s been working on implementing a couple of features in the accounting engine. In fact he’s pretty excited:

– “Wow, this is really going to be valuable for our users!”.

But hold on Ken, you think you’ve finished the development process but you haven’t. Let’s go back to the beginning, so that you can understand.

Once upon a time Ken and his team detected the need to developing a new feature. So being this a relevant change in the Core of the product, Ken decided to start developing this new feature in a new Mercurial branch. It’s the common sense choice for these cases, because he doesn’t want to integrate these changes into Core until it’s ready for general usage. Then he dived into the interesting part: he spent 2 weeks coding and writing some new tests for this new feature. So there he is, he wants the end users to enjoy this new development as soon as possible. This is legitimate and desirable, but Core has a golden rule which cannot be broken:

Anything pushed into the Core repository (erp/devel/pi) must meet a certain quality defined by our automatic tests. This is what we usually call the integration process, or simply int.

To see this simpler: all the balls in int must always be green. You might be wondering which tests they cover. Click on any of the jobs listed in the integration tab to see a description of what they do.

So Ken is now somehow a bit frightened, because although he has written quality code, and quoting his own words:

You never know for sure if you pass the tests until you pass them

And running the tests in your own machine is not an option, because from one side it’s difficult to set them up and from another side we’re continuously adding new tests to this process. As this is a legitimate concern, we’ve decided to solve this gap: we’ll provide Ken a way of running all the tests in a simulated environment, a real clone of the integration process.

So how can Ken run all the tests on his branch? Simple, just running this command:

hg push -f https://code.openbravo.com/erp/devel/try

And then monitor the jobs in the try tab. As of now only one developer can use try at a time. So you need to click on the Changes link of the active job to see if it’s testing your branch or not.

To make things easier to remember, you can add the following snippet to your main Mercurial configuration file (e.g. $HOME/.hgrc):

[paths]
try = https://code.openbravo.com/erp/devel/try

So that if you ever need to run the tests in a branch, the process would be as simple as running this command:

hg push -f try

But Ken is confused:

– “How can everyone push to the same repository? We are using different branches. Isn’t this crazy?”.

The key lies on the -f argument we’re passing to the hg push command. If you’re interested in the basic internals of how this works, every time you push your commits you’ll create a new head in the repository, and the last commit of this head will effectively become the tip of the entire repository. And the try tests are run against this tip. Confusing? If you want to have a better understanding I suggest you to play with a local repository and see how it evolves as you push new heads. If you don’t care, just use it and forget about the internals.

So what’s next? This is just the beginning of this try feature, you can consult the reference documentation. Some future plans in our TODO list:

  • Add e-mail notifications when your build starts, ends and with the final result.
  • Increase the number of developers that can use this simultaneously.

This feature is available for all the Core contributors (Openbravo S.L.U staff and external contributors). Would you like to become a Core contributor? Great! Read the following guide.

I’m sure you have suggestions about this, so we’ll be happy to hear about them. You can do it either by adding a comment here or by joining us in the #openbravo IRC channel.

I would like to thank the Mozilla team for the original idea behind this concept.

Written by jpabloae

01/07/2010 at 14:00

Tip: Mercurial authentication comfort

Mercurial 1.3 has a nice feature that makes our coding lives easier. You can define your authentication credentials globally, so that it will remember your username, the password, or both in any repository cloned from code.openbravo.com. There’s therefore no need to define the credentials individually in every repository.

Example of the relevant section to be added to $HOME/.hgrc:

[auth]
ob.prefix = code.openbravo.com
ob.username = johndoe
ob.password = supersecret

If you only want it to remember the username, then remove the password line.

And if you still are using an older version (hg version), you can follow these instructions to update to 1.3.1.

For more information about this feature check the hgrc(5) man page.

Written by jpabloae

02/11/2009 at 11:11

Posted in openbravo

Tagged with ,

Merging projects made joyful

One of the biggest complaints from developers during the 2.50 development phase was the amount of time and effort it took to merge a project branch into trunk, or vice versa. I want to show you how much this has been simplified with the switch to Mercurial. In this example we merge erp/devel/pi into erp/devel/main, a total of 220 changesets. The process takes less than 3 minutes, including pushing the result to code.openbravo.com.

PS: Put it in full screen to read the text.

Written by jpabloae

27/03/2009 at 09:42

Posted in openbravo

Tagged with ,

Mercurial ready for Openbravo ERP

Openbravo ERP has moved from Subversion to Mercurial. Trunk and the stable branches have been migrated. Trunk has been renamed to “main”. The new server is located in Europe and its new name is code.openbravo.com. This is the new repository structure:

New repository structure

New repository structure

So for example main is located at: http://code.openbravo.com/erp/devel/main

If you browse to http://code.openbravo.com/erp/devel you’ll get the full list of ERP development repositories.

There is a new repository called pi, which stands for Pre-Integration. Till 2.50 is released we will only accept bugfix pushes to main. All new developments have to pushed to the pi repository. Then those developments will be integrated into main when the proper QA has been done.

So to begin with you should install Mercurial. Then if you haven’t done so it’s recommended to read the  developer guide. Then, you can do a clone of main and play with it following the guide. You can also install and configure the Mercurial Eclipse plugin. Before pushing make sure you have properly configured Mercurial. Your credentials are the same one as with Subversion.

So from now on Subversion is not used for trunk and the stable branches. You should work on the new server and with Mercurial.

Written by jpabloae

02/03/2009 at 13:10

Posted in openbravo

Tagged with ,

Mercurial coming soon

Once Openbravo ERP 2.50beta is frozen, we plan to move trunk and the stable branches from Subversion to Mercurial. Check the new developer’s documentation.

We’ll let you know about the server details just before launching the migration. Please read the document and don’t hesitate to ask any doubts you have about this.

There is also an older document explaining the rationale behind this change.

To follow this migration more closely join or read the openbravo-development mailing list.

Oh, and presenting myself in my first post, my name is Juan Pablo Aroztegi, I work in Openbravo since August 2006 and I’m currently in the Release Management Team. My contact details in the about page.

Written by jpabloae

21/02/2009 at 16:00

Posted in openbravo

Tagged with ,