Django 3.2 Retrospective

Owned by Natalia Berdnikov (Deactivated)
Last updated: Dec 12, 2023 by Feanil Patel
2 min read

What should we continue doing?

  • 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.

What should we stop doing?

  • 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

What should we start doing?

  • 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