Merging code for safe deployments

Owned by Robert Raposa
Last updated: Sept 21, 2022 by Matt Hughes (Deactivated)Version comment
2 min read

Overview

Deployments of the Open edX platform happen in at least two very different forms:

  • Some organizations (primarily 2U/edX) release all changes from the tip of the main branch (still named master in certain repos, like edx-platform).

  • Many organizations will only deploy come the next named release.

When merging code, there are special considerations for both these situations. All concerns must be accounted for in each PR.

Deployments from Main

At this time, 2U/edX deploys all changes from the tip of the main branch (sometimes “master”) of the edx-platform repository . A technique referred to as blue-green deployments is used to provide end users with a zero downtime experience for web users. This means that when new code is deployed, the last version of the code may still be running at the same time.

Special considerations must be made when adding migrations, because both the old and new code will be pointing to the same database. See Everything About Database Migrations | Deployment and backward-compatible migrations for details.

Likewise, when making changes to celery tasks, special considerations must be made to ensure tasks won’t fail when there are old and new workers getting tasks from old and new web-services.

All merges must be safe for blue-green deployments, even though only the final result is likely to make it into the next named release.

Named Release Deployments

Many organizations will take some downtime during an upgrade to a newer Open edX named release. These deployments do not have the same concerns as blue-green deployments, but there exist cases where changes must happen in multiple merges, spread out across named releases. Again, this special consideration must remembered by all, even if being made by an organization that is deploying continuously from main.

One example is when squashing migrations, which can be read about in Everything About Database Migrations | Squashing Migrations.

Another example is when deprecating and removing code. Code removal may sometimes need to be deferred for the sake of named releases.