Each IDA we plan to upgrade to Django 3.2 has an owning squad within edX.
Project Lead Jeremy Bowman (Deactivated) and Project Manager Natalia Berdnikov (Deactivated) have developed a “menu of options” for owning squads, offering various levels of involvement. Each squad that owns a DJango Django IDA needs to:
choose from the options below how involved they want to be in the upgrade work
document their decision in https://docs.google.com/spreadsheets/d/11DheEtMDGrbA9hsUvZ2SEd4Cc8CaC4mAfoV8SVaLBGI/edit#gid=2033344699.
Green cells indicate work that would be done by the project team, lead by Jeremy Bowman (Deactivated).
Yellow cells indicate work owning squad would do.
...
Project team does everything (development through deployment and testing), owning squad is not involved, aside from possible advice if project team gets stuck and needs help. Project team will give owning squad advance notice before merging changes.
Needed from the owning squad: occasional advice within 1 weeks week of request.
This option allows the owning squad to spend little to no time on this project, and concentrate on other work. This option is good for areas of code that don’t require too much domain knowledge and can be easily done by the project teamIn order to choose this option, the owning squad must have (or soon provide) clear documentation on how to deploy the service. Testing by the project team will be limited to monitoring that the service’s overall error rate in New Relic doesn’t significantly increase after deployment and there isn’t a surge of new error types that seem related to the upgrade; if more fine-grained testing is required, one of the other options below should be chosen.
Option 2. Trust but verify (Owning Squad deploys and tests)
Project team creates and (after providing advance notice) merges PRs, owning team squad deploys and tests.
Needed from the owning squad: Deploy and test merged PRs within 2 weeks, with enough time for the final PR to be tested before October 1515th. Update project team on progress, highlight any possible blockers to the project team in advance.
This option is a compromise and allows the owning team to save time on development, while ensuring the end result. Note that there may be a delay between the project team merging a PR and the owning squad deploying it; squads that prefer merged PRs to be promptly deployed should probably choose a different option.
Option 3. Review everything (Owning Squad reviews, deploys, and tests)
...
Needed from the owning squad: Review, deploy and test PRs within 2 weeks, with enough time for the final PR to be tested before October 1515th. Provide updates to the Project team along the road, highlight any possible blockers.
This option is a compromise and provides the owning team with the benefit of outsourcing the bulk of development work to the project team, while still closely supervising the end result and having full control over it. This option might be good for teams who have a more complex area of code.
Option 4. DIY (Owning Squad creates PRs, reviews, deploys, and tests)
Owning squad does everything (use project plan and automation provided by project team, deployment, testing, etc.)all the steps in https://openedx.atlassian.net/wiki/spaces/AC/pages/1704591765/Django%2B3.2%2BUpgrade%2BSteps%2Bto%2BUpgrade%2Ba%2BRepository. Project team supervises timeline and status.
Needed from the owning squad: to deliver upgrade to prod production and Edge by October 15. Provide updates to the Project team along the road, highlight any possible blockers.
This option requires most time from the owning squad, while at the same time ensuring that the upgrade is done exactly as the owning team wants. This option might be good for areas of code that require a lot of domain knowledge or are otherwise complex.
...