Django 3.2 Upgrade: Service Levels

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

Service Levels

Options	Plan and Automate	Create PRs	Review	Merge	Deploy	Test

Options	Plan and Automate	Create PRs	Review	Merge	Deploy	Test
1. Hands-off	By project team	By project team	By project team	By project team (with notice)	By project team	By project team
2. Trust but verify	By project team	By project team	By project team	By project team (with notice)	Need to do	Need to do
3. Review everything	By project team	By project team	Need to do	Need to do	Need to do	Need to do
4. DIY	By project team	Need to do	Need to do	Need to do	Need to do	Need to do

Service Levels Description

Option 1. Hand-off (Owning Squad is available for advice)

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 week of request.

This option allows the owning squad to spend little to no time on this project, and concentrate on other work. In 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 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 15th. 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)

Project team creates PRs, 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 15th. 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 all the steps in Django 3.2 Upgrade: Steps to Upgrade a Repositoryarchived. Project team supervises timeline and status.

Needed from the owning squad: to deliver upgrade to 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.