Projects/Module Life Cycle Management/Functional Documentation
User documentation can be found here |
Contents
Overview
In the life cycle of a module version it is usual to go through different maturity statuses. For example the version can be published in a Testing status which is intended to be installed in QA instances, after some QA it can be promoted to Controlled Release to be installed in early adopters instances and after a period of time working on these instances the version would be set as Production status.
Purpose
The purpose of this project is to define and implement maturity statuses for module versions.
An initial maturity status is set by the module owner when he publishes the module version, and can be changed afterwards by him.
Openbravo ERP instances define which is the minimum maturity status of the modules to be installed.
References
Design Considerations
Assumptions
Dependencies
Constraints
As the list of possible maturity statuses is maintained in Central Repository and requested by Openbravo ERP each time it is needed, the values of this list will not be translatable in Openbravo ERP.
Glossary
Functional Requirements
User roles & profiles
There are two roles affected by this project:
- Module Owner: Is the person in charge of publishing new versions of the module. He defines the maturity status of his module.
- Openbravo ERP System Administrator: Is the person that installs and updates modules in an Openbravo ERP instance. He is able to decide which is the minimum maturity status of modules he wants to install in his instance.
Business process definition
User stories
Peter is the owner of the Neverland Localization Pack module. After he finishes developing the first version of this module (version 0.1.0), he publishes it with Test maturity status.
Wendy is very interested in this localization, so she wants to install it in a testing Openbravo ERP instance as soon as it is available (even it is not already Production ready) to check everything works as expected. She configures this instance to be able to install modules with Test status, she searches modules in the Module Management Console and finds that Peter has published version 0.1.0 as Test, she installs it and after some tests she finds out a critical issue in the module, she reports it and Peter decides to cancel the version.
Alice, as Wendy is also interested in this module so she sets her instance to allow Test modules, but now when she searches for new modules she doesn't find this one because the only version available is canceled. Meanwhile Peter fixes the issue and publishes a new 0.1.1 version as Test.
Now Alice and Wendy can install this new version.
James is also interested in this localization, but he does not wish to do testing on it, he only wants to install production ready modules in his instance, so he doesn't configure it to accept non-production modules. When he searches for modules, he doesn't find this 0.1.1 version.
After some testing, Alice finds some other issues in the module that are reported and fixed by Peter. He publishes a new Test version 0.1.2 which solves the issues and Alice and Wendy update the module to this latest version.
Finally Alice and Wendy do not find any further problem, so they communicates Peter they are happy with the module. Peter, then decides to set his module's maturity as Production.
Now when James searches for modules, he finds this localization pack and he can install it.
Functional requirements based on business processes
There are 2 sides which require to implement Life Cycle Management: Central Repository and Openbravo ERP.
Openbravo ERP
- Define default instance minimum maturity status accepted both for installation and upgrade.
- Ask central repository for the available maturity statuses list.
- Allow to change this defaults settings for the whole instance from a new Settings tab in Module Management Console window.
- Allow to define the minimum maturity status accepted for concrete module upgrades from a new Settings tab in Module Management Console window.
- When searching for module installation or scanning for module updates send this settings to central repository.
Central Repository
- Maintain a list of maturity statuses.
- When publishing a module, allow the published to define the maturity status.
- Allow module administrator to change the maturity status of a published module from a new tab in Module Version window.
- Allow module administrator to cancel a version of a module from a new tab in Module Version window.
- Receive minimum accepted maturity status for search and scan for updates and take it into account to calculate the available modules.
- In the module information, return the maturity status for the version so it can be displayed in the Openbravo ERP UI.
User Interface Mockups
Openbravo ERP
Settings tab in Module Manager Console window, where it is possible to define the minimum global accepted status for search and updates as well as the per module specific status.
File:MaturityLevel 0002 Settings.png
Search tab in Module Manager Console window. Here modules in a status different than Production are shown to the user.
File:MaturityLevel 0001 Add.png
Install popup. When installing or updating a module with a status different than Production this is prompted to the user.
File:MaturityLevel 0003 Pop.png
Central Repository
Publishing a module version. The initial maturity status appears as a drop down list.
Version Status. The maturity status can be promoted or the version can be canceled.
File:Module Tab - Mozilla Firefox 006.png
Technical Requirements
A new field for maturity status is needed in the Modules Central Repository returns to scan and search modules. This will require to create a new version of the WebService in Central Repository.
Non-Functional Requirements
Open Discussion Items
Closed Discussion Items
- ALO: In Settings tab module specific settings section, should we use ajax in order not to reload the whole content each time a module is added/removed or is it enough doing a request and re-generate everything. Ajax is better from user point of view, but it would complicate development.
- ALO/ICI: Ajax is not needed.
- ALO: When installing a new module with a maturity different than Production should this status be automatically saved as a specific setting for this module. In this way Wendy could find the new Test 0.1.1 version when scanning for updates having 0.1.0 installed, other way she would have to set it as specific for this module.
- ALO/ICI: Status is not automatically added as an exception, she would have to add this module as exception in case she wants to get new Test versions.
Testcases
Executed tests
Code review
- Openbravo ERP
- Central Repository module
Central Repository
jUnit
jUnit test cases for Central Repository can be found at [ https://code.openbravo.com/erp/pmods/org.openbravo.test.centralrepository/ ]
- jUnit test cases for new WebService3: 13 cases to test maturity levels (search and scan with different combinations of settings).
- Old WebService2 still works: Test old WebService implementation still works by executing existent jUnit tests in pi before merging the project branch.
UI
Check both in ie and ff.
- Publishing a module allows to select its maturity. Check publishing modules in different maturity levels.
- Change status. Check it is possible to change status forward.
- Cancel version. Check it is possible to cancel versions.
Openbravo ERP
Project Branch
- Execute integration tests in project branch.
New Settings Tab UI
Check both in ie and ff.
- Check by default maturity level for update and search is Production.
- Change level of update and search.
- Add specific module settings.
- Remove specific module settings.
Search/install
Pre-test
- In CR Openbravo ERP instance
- Select Translation: Spanish-Spain (es_ES) español-España module, set maturity Test for last versions (1.0.11, 1.0.10 and 1.0.9).
- Select Bank Account Search module, set its only version to Test.
Test
- Install a production module.
- No warning message appears.
- It is possible to install
- Having Production in install global setting search for the Bank Account Search: it does not appear.
- Having Production in install global setting search for the Translation: Spanish-Spain (es_ES) español-España.
- It appears in the results without additional message
- When click on install version 1.0.8 is installed without message
- Having Test in update global setting search for Bank Account Search
- It appears
- A message says its maturity level is test
- Link works
- Click on install for that module.
- Message saying maturity is test
- Link works
- Warning about installing a non production module
- It is possible to install
- Having Test in install global setting search for Spanish Localization Pack and click install
- Test version of Spanish Translation appears as additional module to be installed.
- A message says its maturity level is test
- Warning message about installing non production modules
- Link works
- Having Production in install global setting search for Spanish Localization Pack one and click install.
- The latest no-test (1.0.8) version of Spanish Translation module appears
- No message in that module
- No warning.
- Having Production in install global setting search for Bank Account Search Template and click install. It is not possible to install.
- Install obx. obx installation shouldn't have been affected by this project, check it is still possible to successfully install modules using obx files.
Scan for updates
Pre-test
- Install Spanish Localization Pack 1.4.2 (contains Translation 1.0.8)
Test
- Having Production in update global setting scan for updates.
- No updates available for Spanish Localization Pack
- Having Test setting for Translation scan for updates.
- Update available
- When clicking in install message appears next to Translation module
- Warning message appears
- It is possible to install
- Repeat last test, having no setting for translation module and Test as global update setting.
Pending tests
None
Project status
Project has been merged back to pi and will be released within 2.50MP20.