Embed Size (px)
Citation preview
Open edX Developer DocumentationRelease 1.0.0
edX Inc.
Jun 21, 2022
CONTENTS
1 Open edX Micro-frontend Developer’s Guide 31.1 Configuration with Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Overriding Brand Specific Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Open edX Named Releases 92.1 Latest Open edX Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 All Open edX Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3 Future Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.4 Security Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.5 Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3 Micro Frontends in Open edX 21
4 Getting Started 23
5 New Contributors 25
6 Ways to Contribute 276.1 Translations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.2 Bug Fixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.3 New Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7 Other General Docs 297.1 Architecture and Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297.2 Open edX Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
i
ii
Open edX Developer Documentation, Release 1.0.0
Note: This is the landing page for documentation relevant to developers of the Open edX platform. For other docu-mentation resources targeted for edX learners, educators, researchers, and Open edX operators, see docs.edx.org.
CONTENTS 1
Open edX Developer Documentation, Release 1.0.0
2 CONTENTS
CHAPTER
ONE
OPEN EDX MICRO-FRONTEND DEVELOPER’S GUIDE
The purpose of this document is to provide an overview of how micro-frontend applications (MFEs) are developed,configured, and deployed with the Open edX ecosystem. Open edX MFEs are small React applications that can bebuilt and deployed independently.
MFEs are dynamic client-side rendered JavaScript applications. MFE source code can be found in projects namedfrontend-app-*. These projects leverage node.js for their build processes. They are supplied configuration, then runto build HTML, CSS, and JavaScript. The static assets are then ready to be deployed and served statically.
To run an MFE locally you must install node 12 (with npm version 6.11 or higher). All MFEs offer the followingcommands:
npm install (install dependencies)npm start (development server)npm run lintnpm run testnpm run build (build static output)
1.1 Configuration with Environment Variables
Open edX MFEs expect a number of process environment variables (Accessible in node via process.env) in orderto properly configure the application. This includes links to other parts of the system, branding elements like the sitename and logos, cookie names, and authentication configuration details. Each MFE has .env, .env.development,and .env.test files that are consumed by the MFE. The production .env file contains only falsy values – the buildprocess should supply them via the command line prefixing the npm run build command.
Production build example:
SITE_NAME="My Site Name" npm run build
The above would only set the SITE_NAME - suitable values for all the other environment variables should be suppliedas well.
3
Open edX Developer Documentation, Release 1.0.0
1.1.1 Required Environment Variables
All environment variables in this section are required for Open edX micro-frontends.
A note on micro-frontend-specific environment variables
Individual micro-frontends may depend on other environment variables not on this list. Those variables will be docu-mented in the README files in individual micro-frontend repositories, but can be specified on the command line inthe same way as described above.
Fundamentals
NODE_ENV
Example: production | development | test
Used by both the build process and application to determine what type of environment we’re running. Valid values are“development”, “test”, and “production”. All production-like environments should use “production”, as this removesdevelopment warnings and checks, and can enable code optimizations for many dependencies like React. “develop-ment” is used by local development servers (i.e., webpack-dev-server, loaded with npm start), and “test” is used byMFE test suites (such as jest) run with npm run test.
PUBLIC_PATH
Example: / Used by both the build process and application to set the path of the application. Should include an initialforward slash /. Will default to / if not specified.
BASE_URL
Example: https://new-mfe.example.com
The fully-qualified URL to the micro-frontend being built. Used by frontend-platform as part of authentication, aswell as by many applications for internal links. The above example is on a sub-domain, but micro-frontends can beconfigured with a path LMS as well.
Internationalization
LANGUAGE_PREFERENCE_COOKIE_NAME
Example: example-language-preference
The name of the cookie where the user’s language preferences should be stored.
Service URLs
CREDENTIALS_BASE_URL
Example: https://credentials.example.com
The fully-qualified URL of the Credentials Service in the target environment.
DISCOVERY_API_BASE_URL
Example: https://discovery.example.com
The fully-qualified URL of the Course Discovery Service for the target environment.
PUBLISHER_BASE_URL
4 Chapter 1. Open edX Micro-frontend Developer’s Guide
Open edX Developer Documentation, Release 1.0.0
Example: https://publisher.example.com Status: DEPRECATED
This should be considered deprecated and will be removed from a future release until such time as publisheritself is included in an Open edX release. The fully-qualified URL of the Publisher Micro-frontend. Today thisis only used by micro-frontends that are not offically supported in any Open edX release, such as the Support ToolsMicro-frontend.
ECOMMERCE_BASE_URL
Example: https://ecommerce.example.com
The fully-qualified URL of the Ecommerce Service in the target environment.
LEARNING_BASE_URL
Example: https://learning.example.com
The fully-qualified URL of the Frontend App Learning in the target environment.
LMS_BASE_URL
Example: https://courses.example.com
The fully-qualified URL to the LMS in the target environment.
LOGIN_URL
Example: https://courses.example.com/login
The fully-qualified URL to the login page in the target environment.
LOGOUT_URL
Example: https://courses.example.com/logout
The fully-qualified URL to the API endpoint in the target environment which performs a user logout.
STUDIO_BASE_URL
Example: https://studio.example.com
The fully-qualified URL of Studio in the target environment. This is often used by micro-frontends from which educa-tors may wish to go edit course content, such as frontend-app-learning
MARKETING_SITE_BASE_URL
Example: https://www.example.com Status: DEPRECATED
This is required, but will be removed in a future release. Do not use in new code. The fully-qualified URL of theenvironment’s marketing site. Today this is used by frontend-app-account to link to a demographics collection page,and also as a base URL for optimizely experiment scripts. Use cases in frontend-app-account will be refactored to usedifferent environment variables, since neither use case has anything to do with marketing.
ORDER_HISTORY_URL
Example: https://orders.example.com
The fully-qualified URL to the Order History page. This is often used in a user menu in the header of micro-frontends.
1.1. Configuration with Environment Variables 5
Open edX Developer Documentation, Release 1.0.0
Analytics
SEGMENT_KEY
Example: ABCDEFGHIJKLMNOPQRSTUVWXYZ123456
An implementation-specific environment variable which, when configured, enables integration with Segment, a useranalytics and data management vendor. 32 characters.
Authentication
ACCESS_TOKEN_COOKIE_NAME
Example: example-jwt-cookie-header-payload
The name of a cookie where JWT authentication data should be stored.
USER_INFO_COOKIE_NAME
Example: example-user-info
The name of the cookie where user-specific information should be stored.
REFRESH_ACCESS_TOKEN_ENDPOINT
Example: https://courses.example.com/login_refresh
The fully-qualified URL of the endpoint which allows the micro-frontend to refresh a user’s JWT authentication. Theinconsistency in naming with other fully-qualified URL environment variables is unfortunate.
CSRF_TOKEN_API_PATH
Example: /csrf/api/v1/token
The path of the service’s CSRF token API endpoint. This gets prefixed with the domain of a request requiring CSRFprotection. This token is added to the X-CSRFToken header on outgoing requests.
Branding
SITE_NAME
Example: Your Site Name Here
The user-facing name of the site.
LOGO_URL
Example: https://edx-cdn.org/v3/default/logo.svg
The fully-qualified URL of the site’s logo file suitable for use in the application’s header.
LOGO_TRADEMARK_URL
Example: https://edx-cdn.org/v3/default/logo-trademark.svg
The fully-qualified URL of the site’s logo suitable for use in a footer. This is often a logo with a trademark such as (R)or (TM).
LOGO_WHITE_URL
Example: https://edx-cdn.org/v3/default/logo-white.svg
The fully-qualified URL of a white version of the logo suitable for dark backgrounds.
FAVICON_URL
6 Chapter 1. Open edX Micro-frontend Developer’s Guide
Open edX Developer Documentation, Release 1.0.0
Example: https://edx-cdn.org/v3/default/favicon.ico
The URL to the favicon.ico file to be used for the site. This will be added into the index.html file that serves themicro-frontend at build-time.
1.2 Overriding Brand Specific Elements
MFEs contain Open edX branded headers, footers and style. To build a MFE to reflect the brand of the particular OpenedX instance some npm dependencies are designed to be overridden. Overriding packages must expose the sameinterface as the dependencies they are overriding.
Example: for edx.org the Open edX @edx/frontend-component-header is overridden with @edx/frontend-component-header-edx using npm aliases (introduced in npm version 6.9.0). Example syntax below:
# Syntax: npm install <package-name>@<type>:<branded-package>
# npm packagenpm install @edx/frontend-component-header@npm:@edx/frontend-component-header-edx@latest
# git repositorynpm install @edx/frontend-component-header@git:https://github.com/edx/frontend-component-→˓header-edx.git
# local foldernpm install @edx/frontend-component-header@file:../path/to/local/module
A list overridable packages is being developed. Currently only @edx/frontend-component-header and @edx/frontend-component-footer are designed to be overridden. See those repositories for the interfaces they expose.
1.3 Deployment
The basic deployment strategy:
• Run the build script with environment variables on the command line. Example: NODE_ENV=developmentBASE_URL=open.edx.org ETC=etc npm run build
• dist/ directory is created that contains the deployable artifacts.
• Copy the contents of dist/ to a web server.
• Configure the platform to point at your MFE. (details on this coming soon)
Note: The following is edX-specific and depends upon automation set up in GoCD. A similar, more manual processwill need to be defined for Open edX installations.
edX MFEs are deployed automatically upon updates to the master branch in Github. GoCD collects three materials:the MFE source code, .yml configuration, and pipeline scripts (edX tubular).
.yml configuration contains:
• APP_CONFIG
• NPM_OVERRIDES
• S3_BUCKET_NAME
Relevant pipeline scripts (edX tubular):
1.2. Overriding Brand Specific Elements 7
Open edX Developer Documentation, Release 1.0.0
• https://github.com/edx/tubular/blob/master/tubular/scripts/frontend_utils.py
• https://github.com/edx/tubular/blob/master/tubular/scripts/frontend_build.py
• https://github.com/edx/tubular/blob/master/tubular/scripts/frontend_deploy.py
The pipeline scripts perform a routine like below:
• Parse .yml configuration
• Install requirements in the MFE source via npm install
• Check for NPM_OVERRIDES and install them via npm install @edx/pkg@npm:custom-pkg
• Collect APP_CONFIG and transform it into command line form (NODE_ENV=development BASE_URL=open.edx.org)
• Build the static output with the APP_CONFIG: NODE_ENV=development BASE_URL=open.edx.org npmrun build
• Deploy static output to s3 using S3_BUCKET_NAME
8 Chapter 1. Open edX Micro-frontend Developer’s Guide
CHAPTER
TWO
OPEN EDX NAMED RELEASES
The Open edX community can share knowledge and improvements more easily when most people use the same stable,consistent version of the Open edX codebase. To that end, edX creates “Open edX named releases”, which are distinctfrom the daily deployments to edx.org and have a longer release cycle (on the order of six months between each release).These releases will be tested both by edX and by the Open edX community.
Open edX releases are named alphabetically with botanical tree names.
2.1 Latest Open edX Release
The latest supported release line is Nutmeg, based on code from 2022-04-12.
The next release will be Olive.
2.2 All Open edX Releases
• Nutmeg
• Maple
• Lilac
• Koa
• Juniper
• Ironwood
• Hawthorn
• Ginkgo
• Ficus
• Eucalyptus
• Dogwood
• Cypress
• Birch
• Aspen
9
Open edX Developer Documentation, Release 1.0.0
Note that the latest release is the only supported release. We currently do not have the ability to support more than onerelease at a time.
For documentation on the latest release, please visit the Open edX Platform Release Notes.
Every release line (Ginkgo, Hawthorn, etc) has a branch that accumulates changes destined for that release(open-release/ginkgo.master, open-release/hawthorn.master, etc). Periodically, we tag that branch(open-release/hawthorn.1, open-release/hawthorn.2, etc). After a few releases, we might still add impor-tant fixes to the branch, but not make a new tagged release. At that point, someone installing that line will want toinstall from the branch, not the tags.
If an installation of a tag fails, try the corresponding release line master branch, it may have a fix.
2.2.1 Nutmeg
• Code cut date: 2022-04-12
• Status: supported
• Release Notes
Release Name Release Date Git TagNutmeg.1 2022-06-09 open-release/nutmeg.1
2.2.2 Maple
• Code cut date: 2021-10-15
• Status: unsupported
• Release Notes
Release Name Release Date Git TagMaple.1 2021-12-20 open-release/maple.1
2.2.3 Lilac
• Code cut date: 2021-04-09
• Status: unsupported
• Release Notes
Release Name Release Date Git TagLilac.2 2021-08-09 open-release/lilac.2Lilac.1 2021-06-09 open-release/lilac.1
10 Chapter 2. Open edX Named Releases
Open edX Developer Documentation, Release 1.0.0
2.2.4 Koa
• Code cut date: 2020-11-12
• Status: unsupported
• Release Notes
Release Name Release Date Git TagKoa.3 2021-04-07 open-release/koa.3Koa.2a 2021-02-10 open-release/koa.2aKoa.2 2021-02-09 open-release/koa.2Koa.1 2020-12-09 open-release/koa.1
2.2.5 Juniper
• Code cut date: 2020-05-27
• Status: unsupported
• Release Notes
Release Name Release Date Git TagJuniper.3 2020-08-25 open-release/juniper.3Juniper.2 2020-07-13 open-release/juniper.2Juniper.1 2020-06-09 open-release/juniper.1
2.2.6 Ironwood
• Code cut date: 2019-01-17
• Status: unsupported
• Release Notes
Release Name Release Date Git TagIronwood fixes 2019-06-26+ open-release/ironwood.masterIronwood.2 2019-06-05 open-release/ironwood.2Ironwood.1 2019-03-21 open-release/ironwood.1
2.2.7 Hawthorn
• Code cut date: 2018-07-03
• Status: unsupported
• Note: Devstack is now based on Docker.
• Release Notes
Release Name Release Date Git TagHawthorn.2 2018-09-26 open-release/hawthorn.2Hawthorn.1 2018-08-07 open-release/hawthorn.1
2.2. All Open edX Releases 11
Open edX Developer Documentation, Release 1.0.0
2.2.8 Ginkgo
A note about Vagrant box files:
• Ginko and earlier had Vagrant box files. Hawthorn and beyond do not.
• Not every release needed new box files.
• Box files the same as the previous release are marked with an asterisk *.
• Hashes are SHA1 hashes of the box file, not git commit hashes.
• Code cut date: 2017-07-06
• Status: unsupported
• Latest: open-release/ginkgo.master
• Release Notes
Release Name Release Date Git Tag Vagrant Box FilesGinkgo.2 2017-12-18 open-release/ginkgo.2
• devstack– ginkgo-
devstack-2017-07-14*
–a7e3fce6d0155cde28e9f3253103f3f66ba3ea54
• fullstack– ginkgo-
fullstack-2017-12-14
–c05fcd63df5fae452f0c8cb84720317449215472
Ginkgo.1 2017-08-14 open-release/ginkgo.1• devstack
– ginkgo-devstack-2017-07-14
–a7e3fce6d0155cde28e9f3253103f3f66ba3ea54
• fullstack– ginkgo-
fullstack-2017-08-14
–990d5fdb5bbc7683c158dd99d5732064932c9cdd
12 Chapter 2. Open edX Named Releases
Open edX Developer Documentation, Release 1.0.0
2.2.9 Ficus
• Code cut date: 2017-01-10
• Status: unsupported
• Latest: open-release/ficus.master
• Release Notes
2.2. All Open edX Releases 13
Open edX Developer Documentation, Release 1.0.0
Release Name Release Date Git Tag Vagrant Box FilesFicus.4 2017-08-10 open-release/ficus.4
• devstack– ficus-
devstack-2017-02-07*
–a7fb2200ccdb9f847bee7acd97f5e4e1434776b3
• fullstack– ficus-
fullstack-2017-08-10
–c9f59b27b39339d12fcf008f7c5721c2970a57bd
Ficus.3 2017-04-21 open-release/ficus.3• devstack
– ficus-devstack-2017-02-07*
–a7fb2200ccdb9f847bee7acd97f5e4e1434776b3
• fullstack– ficus-
fullstack-2017-04-20
–64eb0a247d99454bccf0eed7ec49b076cbb9cd69
Ficus.2 2017-03-29 open-release/ficus.2• devstack
– ficus-devstack-2017-02-07*
–a7fb2200ccdb9f847bee7acd97f5e4e1434776b3
• fullstack– ficus-
fullstack-2017-03-28
–fc6aa0d3b686c83e38e8c7fa1b1f172fcf7f71c1
Ficus.1 2017-02-23 open-release/ficus.1• devstack
– ficus-devstack-2017-02-07
–a7fb2200ccdb9f847bee7acd97f5e4e1434776b3
• fullstack– ficus-
fullstack-2017-02-15
–cd6310ffc1e6b374d2c3d59aab5191500f9d5d6f
14 Chapter 2. Open edX Named Releases
Open edX Developer Documentation, Release 1.0.0
2.2.10 Eucalyptus
• Code cut date: 2016-07-13
• Status: unsupported
• Latest: open-release/eucalyptus.master
• Release Notes
2.2. All Open edX Releases 15
Open edX Developer Documentation, Release 1.0.0
Release Name Release Date Git Tag Vagrant Box FilesEucalyptus.3 2017-01-10 open-release/eucalyptus.3
• devstack–
eucalyptus-devstack-2016-09-01*
–a26c8fdbb431279863654161d0145732ee36ed66
• fullstack–
eucalyptus-fullstack-2017-01-10
–64fd2a6efd656a7170127cccdf4458699ea04978
Eucalyptus.2 2016-09-02 open-release/eucalyptus.2• devstack
–eucalyptus-devstack-2016-09-01
• fullstack–
eucalyptus-fullstack-2016-09-01
Eucalyptus.1 2016-08-26 open-release/eucalyptus.1• devstack
–eucalyptus-devstack-2016-08-19
• fullstack–
eucalyptus-fullstack-2016-08-25
16 Chapter 2. Open edX Named Releases
Open edX Developer Documentation, Release 1.0.0
2.2.11 Dogwood
• Code cut date: 2015-12-15
• Status: unsupported
• Latest: named-release/dogwood.rc
• Release Notes
2.2. All Open edX Releases 17
Open edX Developer Documentation, Release 1.0.0
Release Name Release Date Git Tag Vagrant Box FilesDogwood.3 2016-04-25 named-release/dogwood.3
• devstack–
dogwood-devstack-2016-03-09*
• fullstack–
dogwood-fullstack-rc2 *
Dogwood.2 2016-04-14 named-release/dogwood.2• devstack
–dogwood-devstack-2016-03-09*
• fullstack–
dogwood-fullstack-rc2 *
Dogwood.1 2016-03-09 named-release/dogwood.1• devstack
–dogwood-devstack-2016-03-09
• fullstack–
dogwood-fullstack-rc2 *
Dogwood 2016-02-11 named-release/dogwood• devstack
–dogwood-devstack-rc2
• fullstack–
dogwood-fullstack-rc2
18 Chapter 2. Open edX Named Releases
Open edX Developer Documentation, Release 1.0.0
2.2.12 Cypress
• Code cut date: 2015-07-07
• Status: unsupported
• Latest: named-release/cypress.rc
• Release Notes
Release Name Release Date Git Tag Vagrant Box FilesCypress 2015-08-13 named-release/cypress
• devstack• fullstack
2.2.13 Birch
• Code cut date: 2015-01-29
• Status: unsupported
• Latest: named-release/birch.rc
• Release Notes
Release Name Release Date Git Tag Vagrant Box FilesBirch.2 2015-08-05 named-release/birch.2
• devstack• fullstack
Birch.1 2015-07-27 named-release/birch.1• devstack• fullstack
Birch 2015-02-24 named-release/birch• devstack• fullstack
2.2.14 Aspen
• Code cut date: 2014-09-05
• Status: unsupported
• Release notes: Not available
Release Name Release Date Git Tag Vagrant Box FilesAspen 2014-10-28 named-release/aspen
• devstack• fullstack
2.2. All Open edX Releases 19
Open edX Developer Documentation, Release 1.0.0
2.3 Future Releases
Upcoming releases have wiki pages for engineers to collect information that will be needed for their release on theOpen edX Release Planning page.
2.4 Security Updates
If security vulnerabilities or other serious problems (such as data loss) are discovered in the most recent Open edXrelease, edX will release a new version of that release that includes the fix. We will not make patches of any releasesbefore the most recent one. We are still working on the details of how often to update Open edX releases. We willpublicly announce the security issue, and encourage the Open edX community to update their installations to close thevulnerability. If you have found a security vulnerability in the Open edX codebase, please report it by sending an emailto [email protected]. Please do not post the vulnerability to the public mailing lists.
2.5 Feedback
If you find a problem in the release candidate, please report them on the mailing list (openedx-ops for operationsproblem, edx-code for other problems), or even better, create issues in JIRA. We are very interested to hear from thecommunity about what you value about Open edX releases. Please let us know what you would like to see in futurereleases. Discussion on the mailing list is always welcome, of course!
20 Chapter 2. Open edX Named Releases
CHAPTER
THREE
MICRO FRONTENDS IN OPEN EDX
This content has permanently moved to Open edX Micro-frontend Developer’s Guide.
21
Open edX Developer Documentation, Release 1.0.0
22 Chapter 3. Micro Frontends in Open edX
CHAPTER
FOUR
GETTING STARTED
In a hurry to start writing code? Go set up Devstack, our local Docker-based development environment.
23
Open edX Developer Documentation, Release 1.0.0
24 Chapter 4. Getting Started
CHAPTER
FIVE
NEW CONTRIBUTORS
Welcome contributors! There are many ways of contributing to the code and the goal of this documentation is to helpyou with just that!
25
Open edX Developer Documentation, Release 1.0.0
26 Chapter 5. New Contributors
CHAPTER
SIX
WAYS TO CONTRIBUTE
There are many different ways to contribute to the platform.
6.1 Translations
To be a useful platform for everyone everywhere, translations are critical. If you have knowledge or expertise in lan-guages other than English, we could use your help to translate the platform to other languages.
Getting Started with Translating.
6.2 Bug Fixes
Have you been using or operating or using an Open edX site and found a bug you want to fix? We would love yourhelp!
A few things you need to know:
• The contribution process.
• How to setup a development environment.
• How the code is laid out.
• How to ask for help.
6.3 New Features
Got a great idea for how to improve the platform? The more the merrier! The Open edX platform can be added to inmany different ways. Take a look at the options below and come talk to us if you’re not sure which one is the best foryou.
27
Open edX Developer Documentation, Release 1.0.0
6.3.1 Ways of Adding new Features to the Open edX Platform
New XBlock
XBlocks build on top of a well-defined interface in the Open edX platform and do not require review from the OpenedX team. If you want to add a new problem type or content presentation that would be shown to a learner as a part ofa course, you probably want to build a new XBlock.
Before you do that, check out XBlocks that others have built in case they fulfill your needs.
If you’re ready to build one, check out our Intro to XBlocks
New Plugin
Plugins can be built independently of the core platform and do not require review from the Open edX team to buildor use. If you want to add a new feature outside of courseware (learner/educator/operator experience) a new platformplugin might be a great option for you.
Check out this overview of our Django plugin design to get started.
New update to the core platform
If we don’t have extension points for the kind of change you want to make, you might need to make a change to thecore source. This can be complex and we encourage you to reach out to us to talk about the kind of changes you wantto make.
Other useful things you need to know:
• The contribution process.
• How to setup a development environment.
• How the code is laid out.
• How to ask for help.
28 Chapter 6. Ways to Contribute
CHAPTER
SEVEN
OTHER GENERAL DOCS
7.1 Architecture and Best Practices
Open edX Technology Radar A bird’s eye view of the decisions, tools and technologies that have been adoptedor rejected for Open edX development.
Open edX Proposals Technical decisions made by the Open edX community, in the form of best prac-tices, architecture design, or development processes.
Architecture and EngineeringConfluence page
Confluence page for notes, thoughts, and project-related documents on Open edXarchitecture and engineering.
Open edX Micro-frontendDeveloper’s Guide
General guidelines for developing micro-frontends in the Open edX platform.
(Legacy) Open edX Devel-oper’s Guide
General guidelines for developing on various parts of the Open edX code base.
7.2 Open edX Development
Devstack The local development environment for developing in the Open edX platform.Open edX Named Releases Information on each stable Open edX named release.Open edX Extensions and APIs Landing page for supported APIs and extensions to the Open edX platform.
29
