Upgrade Service Levels

For each repository involved in a major upgrade project, the team owning it (“owning team”) should choose from the following “menu of options”, offering various levels of involvement and support. The decision should be documented in the “Owner Does” field of the appropriate issue on the https://github.com/orgs/edx/projects/17/views/1 board.

Green cells indicate work that would be done by the upgrade orchestration team

Yellow cells indicate work that would be done by the owning team

Service Levels

Service Levels Description

Owner does everything

Owning team does all the steps in the upgrade instructions referenced from the upgrade issue in the https://github.com/orgs/openedx/projects/4/views/1. The orchestration team prepares those instructions and supervises the upgrade timeline and status.

Needed from the owning team: to make all the changes outlined in the instructions, and release or deploy them (as appropriate for the type of repository in question) before the target date specified in the roadmap issue. Provide updates to the orchestration team along the way, highlight any possible blockers.

This option requires most time from the owning team, 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.

Owner reviews, merges, deploys, and monitors

The orchestration team creates PRs, then the owning team reviews, deploys, and monitors them. This option should only be chosen for service repositories that actually need deployment

Needed from the owning team: Review and merge the PRs, then deploy the changes before the target date specified in the roadmap issue. Monitor the deployed changes for any problems. Provide updates to the Project team along the way, and 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 orchestration team, while still closely supervising the end result and having full control over it.

Owner reviews and merges

The orchestration team creates PRs, and the owning team reviews and merges them and makes any necessary package release. This is not an appropriate option for services requiring deployment.

Needed from the owning team: review of PR within 2 weeks of request (and before the target date specified in the roadmap issue).

This option is a compromise and provides the owning team with the benefit of outsourcing the bulk of development work to the orchestration team, while still closely supervising the end result and having full control over it.

Owner deploys and monitors

The orchestration team creates and (after providing advance notice) merges PRs, and the owning team deploys and monitors.

Needed from the owning team: Deploy and monitor merged PRs before the target date specified in the roadmap issue. Update the orchestration team on progress, and highlight any possible blockers to the orchestration team in advance.

This option is a compromise and allows the owning team to save time on development, while retaining control of deployment timing and the ability to revert quickly if problems occur. Note that there may be a delay between the orchestration team merging a PR and the owning team deploying it; teams that prefer merged PRs to be promptly deployed should probably choose a different option.

Owner reviews

The orchestration team creates PRs, and the owning team reviews them. Once a PR is approved, the orchestration team merges it and makes any necessary package release. This is not an appropriate option for services requiring deployment.

Needed from the owning team: review of PR within 2 weeks of request (and before the target date specified in the roadmap issue).

This option allows the owning team to spend little time on this project, and concentrate on other work. In order to choose this option, the repository must either require no release after code merges or have a release process very familiar to most Open edX developers. Testing by the orchestration team will be limited to ensuring that CI passes and the release is successfully created; if more fine-grained testing is required, one of the other options above should be chosen.

Owner offers advice

The orchestration team does everything (development through package release), the owning team is not involved, aside from possible advice if the orchestration team gets stuck and needs help. This is not an appropriate choice for a service requiring deployment, as the orchestration team cannot be expected to quickly ramp up on the deployment and monitoring process of another team’s service in the middle of a major upgrade project.

Needed from the owning team: occasional advice within 1 week of request.

This option allows the owning team to spend little to no time on this project, and concentrate on other work. In order to choose this option, the repository must either require no release after code merges or have a release process very familiar to most Open edX developers. Testing by the orchestration team will be limited to ensuring that CI passes and the release is successfully created; if more fine-grained testing is required, one of the other options above should be chosen.