Maintenance - Upgrade Mechanism (r&d)

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