FYI. This isn't ready yet but has been is in the work since the start of the month.
Problem
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)
-
Dashboards
-
4 visualization levels (Aggregate > Pivot > Drill-through > RCA)
-
Display hints
-
8 Portlets
-
-
Data Sources (On-premise or Cloud Hardware and Software)
-
JS scripts (for UX Monitoring)
-
KPIs / SLAs
-
Monitoring Components
-
Rules (for real-time monitoring or automation)
Solution
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