This article will cover acronyms and terms used in this Repo
Capture baseline data is required in order to determine "All systems nominal" after an upgrade.
Baselines can be captured for performance metrics, error rates, transactions/sec etc.
The more baselines that can be compared against, the better.
The business owner is a representative from the business that will be responsible for the upgrade from a business perspective:
- Making go/no go decisions related to the upgrade
- UAT
- Downtime/Uptime requirements allowed
The date that the vendor or open-source community determines the major version of the engine will no longer receive updates, security patches, etc.
The deadline for determining if the upgrade will proceed on the scheduled date/time. This is a business decision based on testing.
This is a sequential, step-by-step plan that will be used to perform the upgrade in both the Staging/Pre-Prod and Production environments.
Every step should be captured (with an asignee) to avoid any unexpected issues.
This includes testing and the rollback plan
Testing performed in a development environment that is more in-depth than a Smoke test. Exact criteria should be determined with the business.
The amount of data the system can lose before a critical business impact, defined by the Business Owner
Measured in seconds/minutes/hours, etc
The amount of time the system can be down before a critical business impact, defined by the Business Owner
Measured in seconds/minutes/hours, etc
Testing performed by business and technical team in order to validate the system has not regressed in any way.
From a business perspective: Everything functions as expected
From a technical perspective: No performance regressions
With respect to a database major version upgrade, the roadmap should include dates for the various phases of testing, code-freezes, go/no-go decision points and go-live dates.
Initial testing performed by the development team and testing teams to make sure the system comes "online"