Guide to creating GitLab upgrade plans
Problem Statement
Customers are required to have an upgrade and a rollback plan as part of the Live Upgrade Assistance workflow, but there is no standard on what a good plan looks like.
As a result, customers can share vague plans that leave lots of room for improvement. This gives the Support Engineer responsible for the pre-scheduling tasks a lot more work in helping the customer create a good plan.
It's also a problem because if a particular scenario isn't caught, then the upgrade could also lead to an emergency.
Proposal
Create guidance for how to formulate an upgrade plan. We should be able to send this to customers, which they can use to either create a plan or improve their existing one. It should touch on:
- Plans to create a full backup they can restore to, if needed
- Formulating their upgrade path
- Pointing them to zero-downtime docs if needed and ask them to review the requirements
- Finding the upgrade docs specific to their setup (upgrading Geo, multi-node, gitlab-chart, the db, etc.)
- Determine version-specific steps to complete (upgrade the db, updating config, etc.)
- Determining their rollback plan
This should also go in the GitLab documentation, alongside the upgrade docs.
DRI
@harishsr will act as the DRI for this issue.
Potential Roadblocks/Things to consider
The template should allow for flexibility to account for specifics with:
- Different installation types (omnibus/docker/chart/source)
- Scaled architecture
- Geo
- Version-specific changes
Desired Outcome
Support Engineers can refer to this documentation when working on live upgrades. They can ask customers to use these docs to create their plans, and then review the customer plans against these docs to confirm that important steps aren't missed.
Support Engineers will be able to more-quickly approve upgrade/rollback plans.
In an issue.
Related Issues/MRs/Epics/Tickets
- Current customer documentation
- Current internal documentation