Projects:Buildvalidations execution restriction/Functional&Technical Specifications
Contents |
Introduction
The objective of this project is to provide a mechanism that will allow buildvalidations to identify whether they should be executed when performing an upgrade.
Functional requirements
Prior to this project, the buildvalidations did not have the ability to identify the version where their logic should be applied when upgrading the ERP system.
The functional requirement of this project is to provide an easier approach that will allow developers to set a dependency for a buildvalidation with a particular module in order to determine if it should be executed or not during an upgrade.
- First Execution Version: defines the first version since the module script should be executed. Before an upgrade, if the dependent module has a version lower or equal than this version, the module script will NOT be executed. By setting this limit we are ensuring that this version and previous ones do not require the module script execution.
- Last Execution Version: defines the last version of the dependent module for which the module script should be executed. Before an upgrade, if the dependent module has a version higher or equal than this version, the module script will NOT be executed.
Technical requirements
The technical requirements of this project consist in:
- Buildvalidation API: provide an API that can be used to set a dependency between a buildvalidation and a particular module version (this module will be usually core, but it could be another module). This dependency means that when upgrading from a version higher than a limit version, the buildvalidation will not be executed.
Performance Requirements
The performance requirement of this project is not to impact on the execution time of some build tasks affected by this change:
- update.database
- update.database.mod
Also, the possibility of avoid buildvalidations execution during this tasks should help to decrease their execution time.