Openbravo Design and Development Process/Launch
Openbravo Release Cycle
The launch phase covers all the steps that are necessary to deliver a successful release to the market, including (but not limited to):
- quality assurance testing (QA)
- early adopters testing (Innovators program)
- and training
Openbravo solutions are released on a quarterly basis. In the case of the Openbravo Commercial Suite (Openbravo for Retail) versions are released as 3.0RRXXQY, where:
- XX is the year
- and QY the quarter of the year.
As shown in the image above, the duration of a release cycle is seven months. For instance, and in the case of Openbravo Commercial Suite 18Q4 design and development activities started dated on 1st June 2018 and will finish at release dated on December 31st, 2018.
The release process consists of the following phases
- 3 month development cycles, when engineering team focus on code development & review, testing and code integration
- 1 additional month for the engineering team to test and fix the bugs found, as well as to create the user documentation and train the support team.
- 1 month for the QA team to test and validate the release according to what defined in the corresponding Test Plan. At the end of this phase the release is published as QA Approved (QAA) only for participants in the Openbravo Innovator Program
- 2 months maturation cycle to evolve from QAA to Confirmed Stable (CS).
Openbravo strongly recommends that only releases that have reached CS are used in production environments
In summary, Openbravo will release Confirmed Stable (CS) releases in March (i.e RR18Q1), June (i.e. RR18Q2), September (i.e. RR18Q3), and December (i.e. RR18Q4) on a yearly basis.
Early adopters testing (Innovators program)
As already mentioned Openbravo has stablished an innovators program based on what there is a maturation cycle to evolve Openbravo releases from QAA to Confirmed Stable, in collaboration with a set of Openbravo end clients.
These clients have access to the corresponding release in QAA status for them to use it and help Openbravo to mature it.
QAA releases have passed automated tests, all fixed issues have been individually verified and the QA team has completed a set of manual tests to identify further improvement.
When it reaches the QAA stage, the release is not yet available for a wide audience but it can already be used for production purposes for those who have a particular interest, explicitly assuring full alignment with the end client.
As part of the Innovators program, interested Partners will receive support in the update process of a customer’s production environment to the current QA Approved release.
For additional information, please review this Openbravo blog post.
Openbravo Release Notes
Every time Openbravo releases a new version of its Business or Commerce solutions, all what it contains it is documented in the corresponding Release Notes wiki page.
Release Notes wiki page informs about the date when a version was published as well as its maturity status.
It is important to remark that within Openbravo release note wiki page, there are direct links to what a given release includes, for instance 18Q4.
New versions of Openbravo Commerce Suite can include:
- new functionality implemented according to the corresponding product roadmap
- fixes of the issues reported by Openbravo partners, fixed by Openbravo according to the corresponding Openbravo partner’s services level agreement
- and extensions that are modules which extend the functionality of the Openbravo Commerce Suite
Openbravo solutions can be delivered on different maturity status:
- Test: This status is used for versions that have not been completely tested yet. Quarterly releases published with this status should be installed only in instances which want to test the solution (staging environments), generally to provide feedback to the Openbravo development team. Versions with this maturity should not be installed in production environments and Openbravo discourages it.
- Quality Assurance (QA): This status is used during the quarterly releases to publish versions being passed to QA team for testing. QA team will run functional and automated test to make sure that nonconforming outputs or issues found have been properly fixed, as well as will make sure that conforming outputs keep working.
When QA team finally approves some version it will be moved to the following stage QAA described below. A quarterly release in QA stage is also not recommended to be used for production purposes as it is being verified.
- QA Approved (QAA): At this stage the version has passed QA testing, as already said all identified issues have been individually verified and the QA team runs a set of manual and automated tests to identify further improvement requirements and to solve identified issues.
Despite the fact the release is getting to a stage of being stable, from the perspective of Openbravo this stage in the release cycle is not yet considered ready for generalized deployment for production purposes. We therefore recommend to only deploy releases in this stage for production purposes in case there is a particular interest that requires to do so and with the explicit consent of your client / end user.
- Confirmed Stable (CS): This is the final stage of a version. At this stage the release has passed the three previous stages of maturity, so it is tested and it has been working during at least 2 months in the QA Approved maturity and is moved to Confirmed Stable without known regressions / important issues. Openbravo recommends all its Partners and end clients to work with releases that have reached this stage of maturity since Openbravo can warrant its stability which we consider key for a mission critical software solution like Openbravo.
- Canceled (C): Canceled versions are not available to be installed in any instance, because there are later versions which can be installed instead.
Professional instances of Openbravo are defaulted to just accept versions in Confirmed Stable maturity status, as Confirmed Stable modules are modules that have been in use with customers for an extended period of time and are therefore proven by real world usage. Restricting access to modules in this status is recommended to organizations that prefer safety over the benefits of adopting new functionality closer to the leading edge of innovation.
Apart when required there are out of schedule emergency releases which are used to for targeted fixing of very important bugs. Typically on the 15th every month release teams checks if any such fixes are pending to be published and prepares and extra release with those.
Those releases can be identified by their version which is constructed as follows 3.0RRXXQY.Z, where :
- XX is the year of the base release
- QY is the quarter of the base release
- Z is simple digit number starting with 1
and will run through the same maturity status and release process.
Example the release named 3.0RR17Q2.1 is based on the initial base release 3.0RR17Q2 and contains only small set of targeted fixes on top. All those fixes will be fixed and verified by the corresponding engineering team and QA team will run once more all manual and automated tests, all of that within the same release cycle.