Consider removing "Update the blog post upgrade barometer section with the migration types for this release, including the time they took to complete." from the release tasks
Right now it's up to the release managers to determine which migrations ran, how long, and what the total migration time is. From what I remember, we do log regular migrations and their output but we don't for post-deployment migrations. We also don't do this for background migrations. This leads to RMs not being certain about the total migration time, unless we added some form of logging for this that I am not aware of this.
Uncertainty aside, I doubt this information is useful in the first place. The timings are based on GitLab.com, which is an environment very different from many others. This means that we may say "Migrations will take 15-30 minutes", only for them to take two minutes for most people.
Based on this, we need to do one of two things:
- Implement proper logging for migrations so we at least know the timings of both pre and post deploy migrations
- Get rid of this step entirely, and add some standard blurb about migrations to the release post
I strongly prefer option two, because:
- It's the easiest to implement
- Most of the time the migration timings really aren't that interesting, except for maybe major releases. This means we're doing a lot of work for something that is useful maybe once a year.
The standard release blurb would look something like this:
Database migrations in this release may take between 30 and 60 minutes for instances similar to the size of GitLab.com. For most smaller instances the total time should be no more than roughly 15 minutes.