Projects:Improved Upgrade Process
Contents |
Implement improved Upgrade Process - Functional Specifications
Overview
Purpose
The purpose of this project is to implement an improved upgrade process. This new process should have these key properties:
- The new rebuild window needs to make very clear to the user whether the build went perfectly fine, whether the build finalized with warnings, or whether the build failed.
- If the build failed, the application will not be able to be used until the user manages to make a succesful build (the system will allow the user to retry a build in case the system is in a "partial rebuild" state).
Functional Requirements
Business process definition
To achieve these goals, the following requirements will need to be fulfilled:
- The build process itself will be reviewed to make it reliable (errors should always make the process fail, warnings should appear when there really is a warning, ...).
- Before the build process starts, it will stop currently running tasks so that they don't interfere with the build process.
- The User Interface of the rebuild window will be changed. Instead of showing the log, the build phases will be shown, and they will be marked as they are being completed. If there were warnings or errors in any of the build phases, they will be marked as such.
- If the current phase of the system wasn't set to "fully complete", when you login, the "rebuild system" option will be available, and no window in Openbravo will work until the system is rebuilt succesfully.
- If the build was done but tomcat wasn't restarted, the "restart context" option will be available, and as before, no window in Openbravo will work until tomcat is restarted.
- A backup/recovery system implementation is not planned for this project
Specific subtasks based on business processes
| Num | Requirement | Importance | Estimation | Status |
| 1.1 | Before the build process starts, it will stop currently running tasks so that they don't interfere with the build process. | Must Have | 1 day | done |
| 1.2 | The status of the system will be saved in the database. | Must Have | 1 days | done |
| 1.3 | The information about whether there were warnings or errors on each build phase will also be saved in the database. | Must Have | 2 days | done |
| 1.4 | The User Interface of the rebuild window will be changed. Instead of showing the log, the build phases will be shown, and they will be marked as they are being completed. If there were warnings or errors in any of the build phases, they will be marked as such. | Must Have | 5 days | done |
| 1.5 | A property will be used to know whether the application needs to stop working if the status of the system is not ok. This property can be configured in the Openbravo.properties | Must Have | 1 day | done |
| 1.6 | If the current phase of the system wasn't set to "fully complete", when you login, the "rebuild system" option will be available. If rebuild was done but Tomcat wasn't restarted, the user will be able to restart Tomcat. | Must Have | 2 days | done |
| 1.7 | The log can be optionally shown in the rebuild window. A new functionality to read files from the file system and display them in a pop-up needs to be implemented. | Must Have | 1 day | done |
| 1.8 | The "build version" should be saved in the database and in the files so that it can be verified that the generated files were indeed deployed to tomcat | Nice to Have | 1 day | Not done |
| 1.9 | Revision of the build process to make it reliable | Must Have* (will not be fully completed) | 3 days | done |
| 1.10 | The rebuild window will kick logged users out, and will disable login for normal users until the rebuild has been completed successfully | Must have | 2 days | done |
User Interface Mockups
