View source | Discuss this page | Page history | Printable version   

Release Management/Testing environments

Release Management/Internal

Index


Contents

Introduction

In a production Openbravo ERP system it is usual and recommended to have a testing environment. Among its benefits we could highlight the ability for end users to test new features in advance and for the system integrator to test new customization deployments.

System integrators add new features to Openbravo ERP by writing the code, testing it in the ERP and finally by promoting them to the production system. This article analyzes the testing environment, with the goal of defining the ideal process both in functional and technical terms.

Requirements

Processes

I want to do a customization

This customizations must be done through modules. Core must never be modified.

If you plan to publicly share or commercialize your module it is a recommended practice to use the Openbravo Forge, as it provides development services such as an Issue tracker, a SCM, Forums, News, the ability to publish it into the Central Repository, etc.


Developing in the Forge: reference documentation

Developing in the Forge for modules developed by Openbravo: reference documentation

General modules development documentation

I want to control the changes to my modules

Each module will be version controlled in individual repositories. System Integrators can use their SCM of choice. The testing and production environment only know about OBX. Using a SCM to develop them is recommended but nor mandatory.

Reference documentation

I want to send my changes to the testing environment to test them

The system integrator creates an OBX file in their development machine. And then they apply it through the Module Management Console in the testing environment. As a prerequisite make sure that the testing environment has been replicated with the latest changes from the production environment.

Reference documentation

I want to promote the latest tested changes from testing to production

This is the process to be followed:

Reference documentation

Replicating production into a testing environment

I want to install a module not developed by us and deploy it to the production system

This is done through the testing environment, as follows:

Reference documentation

Replicating production into a testing environment

I want to a apply a hot-fix Core OBX before the official release is published

Openbravo creates daily Core OBX files with the latest changes in our main repository. These modules are tested by our continuous integration framework. It is possible for the support team to provide a customer access to one of these OBX files which contains a fix interesting for that specific customer. A fix that cannot wait for the normal release schedule (monthly). In those cases:

Once the official release is out the user can apply the new OBX using the Module Management Console.


Reference documentation

Required deliverables

There are two possibilities:

Testing and production in different machines

Develop an option in the Cloud Appliance to replicate the ERP from another appliance.

Testing and production in the same machine

Implement the optional testing ERP in the Cloud Appliance, isolated from the production ERP (as much as possible). This is useful for small implementations like QuickStart where having the testing environment in another machine is not feasible.

Retrieved from "http://wiki.openbravo.com/wiki/Release_Management/Testing_environments"

This page has been accessed 7,347 times. This page was last modified on 2 February 2010, at 07:57. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.