Arbi-BOM notes: /wiki/spaces/AT/pages/3297313270
Django 3.2 upgrade overview: Django 3.2 Upgrade
MySQL 5.7 → 8.x upgrade should probably be done before the next major Django upgrade
Share IDA specific expectations and desired timeline before hand to help owning team to plan
Give the owning team guidance and examples for upgrading IDAs
The use of a shared common library constraint file
Allowing the deploying smoke testing be done by the owning team
Use of slack to help owning team’s questions and problems.
Involving community was a good decision for packages upgrade.
Extensive use of documentation on Confluence. The doc platform Confluence was important because that’s where engineers feel nature to search for answers on.
I cannot remember if this is true, but I thought the django 3.2 upgrade and migrating from Travis to github actions happened really close to each other. That’s a bit confusing in the beginning.
Owning teams ( hands off few services ) but there must be some process where they verify or help in deployment and testing.
All support tiers should have the owning squad performing any final testing and deployment of the actual Django upgrade
Introduce the Arbi-bom team to rest of the engineering organization. Faces and names. I do feel like in the beginning, I don’t really know what stake Usama and Muhammad had in this effort until pretty late in the tasks.
Engineering All-Hands presentations at least quarterly?
Maintaining a record sheet for each team’s person to coordinate the tasks with would be a good step in increasing the collaboration when getting the pull requests reviewed by other teams.
We should fix deprecation warnings in services actively which will minimize the final upgrade effort. We can create tickets in the backlog for fixing those warnings so those can be picked when the board doesn't have enough tickets to do.
Identify areas of the code that were challenging to get updated on schedule, and actively improve their state of maintenance.
Have an ongoing process for keeping dependencies up to date and pruning ones that aren’t actively maintained
Run upgrade codemods well before the Django upgrade
Better track outstanding warnings in CI suites, notify owners when they jump