Purpose of this Document
The purpose of this document is to explain and compare different plans for improving the development environment for 2u/OCM employees, and ultimately to choose which one(s) we should pursue.
Background
The Development Environment (DevEnv) working group was created in February 2022 with the initial purpose of facilitating the adoption of the Tutor development environment across OCM. Tutor is the current standard environment for OpenEdx deployment and is becoming widely used in the OpenEdx community for development as well. The latest releases were created without any devstack-compatible images, so anyone developing off the release branches (as opposed to master) cannot use devstack at all. See https://openedx.atlassian.net/wiki/spaces/COMM/pages/3324149773/Development+Environment+DevEnv+Working+Group#Why-Tutor%3F for more information on the initial choice to move to Tutor.
As the DevEnv working group worked on Tutor, it became clear that Tutor was not yet in a state where it would be a suitable development environment for most OCM employees. Meanwhile, as new employees joined and were onboarded, it likewise became clear that devstack was not fully compatible with new Mac hardware. Teams with new employees, along with members of the DevEnv working group, looked for quick ways to unblock the new hires. This resulted in two particular efforts: a cloud-hosted devstack, and an M1-compatible local devstack (with MySql 8.0).
Goals
Ultimately, we are working towards a development environment with the following properties:
Fast to install
Easy to maintain and/or regenerate
Usable by the broader OpenEdX community
Reasonably consistent with main production environments
Easy to understand
Easy to troubleshoot problems
Well-documented
On a user-level, we’d like the environment to facilitate developer experiences such as:
A new developer (OCM or community) sits down and within a short amount of time (on the order of minutes or hours rather than days), is able to start working on a task
A developer can easily recreate and trace a production bug in their local setup
A developer can easily create the test data they need for a task, keep it when generating a new environment, and provide it to other developers who may want to work in the same area
Possible Approaches
Optimizing Tutor for OCM development
Completed Work
OCM-specific instructions for developing with Tutor, including instructions for edx-platform, enterprise, and course_discovery: Using Tutor for local development
Several issues created for and then solved by the Tutor team at tCRIL (easier mounting, fixing RCM)
Remaining Work
Filling out Tutor Adoption Requirements by Squad
Productizing the plugins created here https://github.com/edx/devenv-wg/pulls (and determining the structure of OCM-specific plugins)
Pros
Strongly recommended and supported by tCRIL
Consistent with most of the OpenEdX community
Cons
Tutor is not fully optimized for development and still suffers from some slowness and missing features
For example, the default of rebuilding the image every time you want to run the service is very slow, especially as it for some reason it needs to collect assets every time
High activation energy cost to switching the entire OCM organization off devstack
Creating a cloud-hosted devstack
Completed Work
Remaining Work
Pros
Cons
Continuing incremental improvements to local devstack
Completed Work
Remaining Work
Pros
Cons
Improving sandboxes for development
Completed Work
Remaining Work
Pros
Cons
Related projects
Dev Data (OEP-37)
Better base containers (OEP-45) - ArbiBOM is working on it
Concerns
Staffing - What are the top priorities? What’s important enough to preempt other projects in progress?