Maintenance - Upgrade Mechanism (r&d)
FYI. This isn't ready yet but has been is in the work since the start of the month.
It takes between 1 day and 3 weeks to upgrade Germain to a more recent version. Most time is spent on validating that the customer’s customization still work on the latest release.
How to store OOTB config and customizations; OOTB config is updated for each release, often conflicts with customizations
Monitoring rules are impacted by this - impossible to keep them in config only because we can't keep track of changes
Tracking changes to OOTB config is hard / impossible, so not always obvious what to re-import during upgrade
Possible to create bad config by posting invalid types [not covered below]
For certain config objects, do not require a fixed schema (monitoring components); use key/value pair or JSON instead [not covered below]
Germain Objects that Clients commonly customize:
Automation (email, script exec, sql exec, synthetic click, etc)
4 visualization levels (Aggregate > Pivot > Drill-through > RCA)
Data Sources (On-premise or Cloud Hardware and Software)
JS scripts (for UX Monitoring)
KPIs / SLAs
Rules (for real-time monitoring or automation)
Layer approach - store last value for each field; we already store each change as audit records.
Perform the server upgrade
Screen to upload all OOTB configs in one step
Automatic "rebase" or all configuration. System compares old OOTB with new OOTB and customized env config
For each config object that has been changed in OOTB and customizations, user is prompted to pick which version to use -> manual conflict resolution via diff screen