jpabloae.blog

Release Engineering at Openbravo

Archive for October 2009

RM updates: Continuous Integration, Ubuntu, Javadoc, Release Notes

Like in any other team, some of the tasks we do in the Release Management Team have consequences in users, other times in developers and some times even in other company staff. We feel it’s important to notify other teams about what has been done. Not the progress or the future plans, we have Scrum of Scrums for that. But about the actual specific results.

So this is a simple as this: whenever there’s something new we think it could useful to a specific groups of users we’ll write a short summary to them. This will happen every 2 weeks.

Continuous Integration

  • There’s a new set of tests called erp_sanity_tests. This intends to collect various basic checks that are not worth to keep as a single Hudson job. As for now there’s one included, to Check if the primary keys of the database in erp/devel/pi that were present as columns in erp/stable/2.40 have a onCreateDefault value set.New tests are accepted either by describing them to us or by sending us the code to be run.
  • The QuickStart and Module Installation jobs have been moved from slave1 to slave2. We currently have 4 machines for builds.openbravo.com, and with this change one 100% dedicated to smoke tests.This affect developers in the way that now smoke tests will be finished quicker without interruptions from other jobs.

Ubuntu package

There was a demand for instructions on how to install the Ubuntu package with Tomcat in one server and PostgreSQL in another. This steps are currently manual and they’ve been documented.

Release Notes

They have been refactored. Now there’s a main page where you can see all the versions.

Then you can access the specific summary notes for each release. Check 2.50MP6 for an example.

And if you’re interested in more details, the Changelog page shows the complete list of fixed issues.

The 3 pages are linked. And the idea is to replace the Changelog page at some point, by delegating in Mantis to do this automatically.

Openbravo ERP API Javadoc

The Openbravo ERP API is now available for online viewing.

This includes all the releases since 2.50, as well as docs for erp/devel/main and erp/devel/pi, which are automatically updated in each incremental build of our continous integration framework.

Advertisements

Written by jpabloae

15/10/2009 at 11:19

Ideas for Openbravo ERP development builds live testing

Many of our developers and power users are frequently requesting live installations where to test daily or even hourly builds of the development repositorios (pi, main, etc). We already had this internally in the headquarters of Pamplona (the so called tecnicia14 machine) and it was pretty popular among the local developers and even the consultants. In this post I collect some ideas and ask for feedback.

I’ve been thinking on why this is useful, who the target users are, how this fits with our current continuous integration framework (builds.openbravo.com), what the frequency should be, etc.

To begin with, adding this feature is on the second milestone in the Openbravo Continous Integration project.

Target audience

Firstly, I basically see three groups of users interested in this:

  1. Developers and power users: it’s obviously interesting for them to test the latest versions with different databases and running on different environments.
  2. Sporadic users who want to test the latest developments and see how the progress is going.
  3. QA team: they need these environments all the time, all the day.

The QA team has one big restriction: they need to be the only ones accessing the ERP at that time. And vice versa, developers don’t want to share the environment with QA: imagine them testing the DeleteClient functionality.

So the proposal is to have two different environments:

  • live.builds.openbravo.com: for developers, power users and sporadic curious users. Open to the world.
  • liveqa.builds.openbravo.com: for the QA team. Restricted access.

Candidate jobs

Given that we use Hudson as our CI framework, these would naturally be two different Hudson nodes. Having a look at the list of builds I’ve detected the following candidates:

The incremental jobs are only useful for testing the upgrade process, but not for live testing. That’s why they’re not included here.

Implementation

  • Every time one of the selected builds is successful we could create a tarball with a database dump and the WAR file, placing them in a known location. The sources could also be shipped, because some of the modularity features require this.
  • Then, the every new Hudson job would take their correspondent files and reset the environments using this database dump and WAR file.

As the reset process would take 5 minutes at most, the frequency could be 1-4 times a day.

Resources

Three machines would be required for this:

  • One for Oracle (shared). Because a bug in the ERP shouldn’t affect the daily builds.
  • One for Tomcat and PostgreSQL (live.builds.openbravo.com).
  • One for Tomcat and PostgreSQL (liveqa.builds.openbravo.com).

Open questions

Anything is open to questions, of course, but this is a list of topics I have brainstormed:

  • Is there any other build you would include?
  • Would you find useful to test the ERP in other operating systems and architectures other than Linux and x86/x86_64?
  • What reset frequency would be reasonable?
  • If QA needs a separate environment, do developers need it too?

What else other than listed above would be of interest for you in these live testing machines?

Written by jpabloae

01/10/2009 at 19:37

Posted in openbravo

Tagged with , ,