Release Management/Testing environments
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
- Core will never be modified directly. It will either be updated through the Central Repository or directly by providing a OBX file.
- Developments are stored as modules.
- Ability to test the developments in the testing environment, once the set of tests passed.
- Ability to clone the production environment to the testing environment.
- Ability to promote the developments from testing to production in an easy manner.
- Ability to provide an updated Core OBX module with a hot-fix without waiting for the official Core OBX.
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.
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.
I want to promote the latest tested changes from testing to production
This is the process to be followed:
- Make sure you first have tested it in the testing environment.
- Perform the exact same steps of applying those OBX files, now in the production system.
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:
- Replicate the database from the production system.
- Install a module using the Module Management Console in the testing system.
- Check that everything is correct.
- Repeat the process in the production system.
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:
- The support team provides the hot-fix OBX file.
- The user applies the OBX file using the Module Management Console, by specifying the file fom the file system.
Once the official release is out the user can apply the new OBX using the Module Management Console.
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.