jpabloae.blog

Release Engineering at Openbravo

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?

Advertisements

Written by jpabloae

01/10/2009 at 19:37

Posted in openbravo

Tagged with , ,

10 Responses

Subscribe to comments with RSS.

  1. Hi Juan Pablo,

    I’m very happy to hear that our beloved tecnicia14 builds will be soon be back with a renewed face :D

    The 2 different environments make sense at 100%. Now let’s try to improve demo.openbravo.com in order that it provides more value than live.builds.openbravo.com :)

    The candidate jobs are also perfect. When one job is not available because of a compilation error or is in compilation time, let’s display an alternative page (not a 404) to select a similar job or directly redirect:
    * If erp_devel_pi-full-oracle job is not available, propose/redirect to erp_devel_pi-full-pgsql and vice versa.
    * Try not to launch jobs at the same time in order that if one is in building process the other one is running.
    * If erp_devel_pi-full-oracle is broken, do not launch again erp_devel_pi-full-pgsql: this way we have at list one pi instance up and running.

    Regarding the resources, what do you mean by “One for Oracle (shared). Because a bug in the ERP shouldn’t affect the daily builds.”

    Thank you very much for the initiative!

    Rafa Roda Palacios

    02/10/2009 at 07:55

  2. Hi Rafa,

    Thanks for your comments!

    My idea is to only put the last working build of a job. If for example erp_devel_pi-full-oracle job succeeds in build numbers 23, 24 and 26, but fails in 27, we’ll only install the 26th. And if it’s fixed in 28 then it will be installed replacing the previous one.

    As the build process would be run in one machine and the ERP environments would be located in another, the build will not affect the ERPs at all.

    Regarding the resources, what do you mean by “One for Oracle (shared). Because a bug in the ERP shouldn’t affect the daily builds.”

    I meant that we’ll use one machine for Oracle only. We also do this for the builds, but it won’t be the same machine because a bug in the ERP could e.g. trigger an infinite loop and use a lot of CPU, this decreasing the build speed considerably. So we’ll have 1 Oracle for the builds, and another one for the ERPs live testing. And with “shared” I meant that I think we can share it between live.builds.openbravo.com and liveqa.builds.openbravo.com.

    Juan Pablo

    jpabloae

    02/10/2009 at 08:08

  3. Hi,

    Nice to see that will have a place to test and try to reproduce the errors (aka bugs).

    This will help also the triage team to not schedule and assign bugs without testing them in the latest available build.

    Does the install.source ant task exist on 2.40, or do you meant, a full (from scratch) installation?

    Hope to see those live instances soon! :)

    Cheers,

    Iván

    katratxo

    03/10/2009 at 09:57

    • Ha! I double checked and there is an install.source in 2.40 … I didn’t know that :p

      katratxo

      03/10/2009 at 10:03

    • Cheers Iván,

      That’s right, this can potentially improve the triage filter, in terms of speed and quality. And therefore make the developer’s life easier.

      Regarding install.source, I think it was added in 2.3x.

      Juan Pablo

      jpabloae

      03/10/2009 at 13:18

  4. Live builds will also improve defect reporting, the step before doing a good triage ;) Once these live builds are available, their usage should be encouraged at http://wiki.openbravo.com/wiki/Bug_Reporting_Guidelines#Before_reporting_a_bug

    Rafa Roda Palacios

    07/10/2009 at 13:54

  5. I don’t know here’s a right place to say it, I really need a live testing environment for localization, something like livei18n.builds.openbravo.com.

    Localizers need it to ensure translation quality, BUT:

    (1). Good translators are generally not good at openbravo system setup. we also shouldn’t expect they have efficient skill for vmware,ubuntu,oracle,tomcat to prepare environment…

    (2). We may need to invite end users for testing, who are neigher engineer not translator, but have profond knowledge for accounting or real business operations. they can easily access live testing server for checking proper translations.

    With live testing environment, localizers can focus on localization itself, quality and efficiency will be improved a lot.

    It’s great if have meachanism that populating latest translation work on openbravo svn repository into live testing server automatically.

    hidemaru hidekawa

    08/10/2009 at 13:26

    • Hi Hidemaru,

      It’s an interesting idea I hadn’t thought of.

      I wonder however if that would be the best solution to the problem. What would be be the main goal of this? Make it easier for people to translate Openbravo ERP? Make it easier for people to check the latest translation?

      If the goal is to make it easier to translate Openbravo ERP, I have the impression that live servers would not work. First of all we’d need 1 ERP per translation, and this currently means 47 ERP instances. And secondly I think that if there ware multiple translators of one language they could collide, given the way in which the translations currently work.

      What I believe would be a good solution is to provide a web interface, publicly available, where anyone can translate the strings from English to your language. And a daily process could do the process of packaging these translations into a translation module. This way it’s easy to contribute and very little technical knowledge is required. This should not be hard to do. What do you think?

      jpabloae

      19/10/2009 at 12:59

      • Thanks for your reply. Recently I also put similar post on openbravo forum, but currently only get 5 views and nobody replies my post:) So, maybe community don’t need the solution I proposed…

        http://forge.openbravo.com/plugins/espforum/view.php?group_id=100&forumid=597808&topicid=7004249

        Anyway pls let me reply your comments.

        > I wonder however if that would be the best
        > solution to the problem.

        My original purpose is:
        1. help system setup for translators who’re unlikely to have enough system knowledge
        2. improve workflow efficiency between translation and check translation
        3. facilitate collaboration between localization team members

        so, my reply would be:
        > Make it easier for people to translate Openbravo ERP?

        yes, but in my thought, it should be combined with CAT tool like trados, omegaT. These tools are essential to ensure quality and efficiency for large volume translation (400,000 words in openbravo).

        > Make it easier for people to check the latest translation?

        yes, especially for team member collaboration. Also hope to improve efficency to setup testing environment.

        > If the goal is to make it easier to translate
        > Openbravo ERP, I have the impression that live
        > servers would not work

        My original thinking is put all(47) localizations on svn trunk into one server ( one ERP instance), then each login user specify target language in user preference for testing. Number of 47 are little bit many, but some multi-national company need multiple languages in one system for different nationalities, so I think it’s a kind of actual use-case.

        Regarding multiple tranlators, openbravo policy is assigning one localization leader per language for coordination. So each langauge would have its main trunk. I think situation is similar to system coding by multiple programmers using version control system. Openbravo company is providing svn for localizers too.
        http://wiki.openbravo.com/wiki/How_To_Localize#How_to_become_a_localization_leader

        > What I believe would be a good solution is to
        > provide a web interface

        I also think it’s good idea. It may be more useful if it’s based on svn repository? It can record revision hisotry, and it also can be combined with CAT tool workflow…

        hidemaru hidekawa

        19/10/2009 at 16:55

  6. I understand your concern. Do you know Launchpad’s translations mechanism? (translations.launchpad.net). If you access any project, you’ll see the progress in the different translation efforts per language. And if you register you can even edit the translations using your web browser. I think that if we had something similar, thentranslating Openbravo ERP would be quite easy and would solve our first problem. What do you think of a system like this?

    And the second problem is testing them in the ERP. For this I think we can assume that if you’re interested in using the ERP, so at a minimum you can download a virtual appliance and start it.

    Thanks for the feedback,

    Juan Pablo

    jpabloae

    26/10/2009 at 16:12


Comments are closed.

%d bloggers like this: