Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

The purpose of this page is to help those with write access to openedx repositories make informed decisions about when to merge pull requests.

2U employees: Please keep this page up to date! It will help the community help you by making informed decisions about merges that will affect edX production environments.

Context

Groups of individuals with merge rights to public repositories in the openedx GitHub organization include:

2U, unlike most other Open edX operators, ships code directly off of the master branch of Open edX service repositories. We aim not to merge in a way that would make it difficult for 2U employees to respond to breaking changes, whether they be intentional or accidental. Still, we do want to empower non-2U committers to merge changes without relying on a 2U employee to "push the button" for them.

Core contributors: Please consider these guidelines in conjunction with those listed in CC reviews and ownership.

2U employees: Please consider these guidelines in conjunction with the internal IDA release process and LMS/Studio release process.

Guidelines for edx-platform

When is edx-platform deployed?

edx-platform is continuously deployed to edX production. Upon merging a pull request, it is generally released to the Staging environment (courses.stage.edx.org) within one hour and the Production environments (courses.edx.org and edge.edx.org) within two hours.

What is the ideal merge window?

Non-2U: Monday through Friday, between 7:30 AM and 3:30 PM, Eastern Time.

2U: your team’s preferred working hours.

What should I do before merging?

Non-2U: Inform the relevant #cc-$PLATFORMAREA channel(s) in the Open edX Slack of your intent to merge with a lead time of ~15 minutes. See this document for a list of channels.

2U: may post in their internal Slack’s #warroom to raise awareness of their change if they believe it has an above-average risk of failure in production.

What if something goes wrong with my code?

Your PR may cause a bug in edX production, break tests on master, or break edX’s continuous deployment pipeline. If this happens, a 2U engineer will likely inform you of the issue and open a PR to revert your code, even if you already have a fix in progress. This isn’t personal (wink) 2U needs the master branch to be in a deployable state at all times, so they adopt a policy of “revert now, ask questions later”.

When you are ready, follow the normal process again to reintroduce a fixed version of your PR.

Are there other times merging is discouraged?

Weekends. Saturdays and Sundays.

Christmas and New Year’s Day (12/25 and 1/1). In some years, 2U requests a broader merge freeze between 12/22 and 1/4. Reach out to your the correct Slack channel if you want to merge within this time period.

Martin Luther King Jr. Day. The third Monday of January.

US President’s Day. The third Monday of February.

MA Patriot’s Day. The third Monday of April.

US Memorial Day. The last Monday of May.

Juneteenth. June 19th, or the weekday nearest to it.

US Independence Day. July 4th, or the weekday nearest to it.

US Labor Day. The first Monday in September.

Indigenous Peoples’ Day. The second Monday in October.

Veteran’s/Armistice Day. November 11th, or the weekday nearest to it.

Thanksgiving + day after. The fourth Thursday and Friday in November.

Additional special dates may come up. Please watch this page if you plan to merge code!

Guidelines for other repositories

When are other repositories deployed?

Frontend app repositories (ie “MFEs” / “micro-frontends”) are generally deployed to edX production manually by the owning team at 2U.

Backend service repositories (ie “IDAs” / “independently deployable apps”) are generally deployed to edX production manually by the owning team at 2U.

Python and JavaScript packages are “deployed” when they are upgraded in their respective service repositories. Because different services upgrade dependencies at different rates, the lead time from merging to production here can vary. To minimize this lead time, we recommend to quickly follow each package merge with (1) a package release and then (2) an upgrade of that package in at least one service. When upgrading the package in a service, follow that service’s merge timing guidelines.

Dev tools such as Devstack are not “deployed” per se, but merged changes are immediately apparent to developers once they git pull .

What is the ideal merge window?

You can merge to these repositories whenever you want to once you have met that repository’s review requirements.

What should I do before merging?

Non-2U: inform the relevant #cc-$PLATFORMAREA channels in the Open edX Slack with a lead time of ~15 minutes.

2U: inform the owning team. Depending on the repository, you may need to kick off a production deployment.

What if something goes wrong with my code?

Your PR may cause a bug in edX production, break tests on master, or break edX’s continuous deployment pipeline. You generally have two options:

  1. Merge a revert of your PR immediately and then reintroduce a fixed version at your leisure, or

  2. Leave the broken change on master but quickly "fix-forward" with a patch PR.

Keep in mind that 2U engineer may need you to take option (1) depending on their operational needs.

Are there other times merging is discouraged?

At the moment, no, but please watch this page if you plan to merge code!

  • No labels