Deployment & DevOps
Overview
Deployment & DevOps covers the tooling, standards, and processes the Open edX community uses to build, test, and ship software — cookiecutter templates for new services and MFEs, shared webpack/jest build configuration, CI/CD standards, repository health checks, and end-to-end testing.
This is the developer experience layer: what it feels like to create a new Open edX project, maintain it over time, and contribute upstream.
Current State (2026)
- Cookiecutters:
edx-cookiecuttersprovides templates for IDAs (Django), MFEs (React), XBlocks, and Django plugins;npx @openedx/frontend-buildsets up MFE build tooling frontend-build: Shared webpack, jest, and ESLint configuration for all Open edX MFEs; MFEs depend on it for consistent toolingedx-repo-health: Automated checks that repositories meet Open edX standards (CI config, license, dependencies, etc.)- Cypress:
cypress-e2e-testsprovides end-to-end test infrastructure for platform-level integration testing - CI standard: GitHub Actions used for all openedx org repos; common workflows defined in
.github/templates
Architecture
- Cookiecutter templates: Python-based project generators; developers run
cookiecutter gh:openedx/edx-cookiecutterswith a template name frontend-build: NPM package providing shared webpack, jest, Babel, ESLint config; MFEs extend it rather than configuring from scratch- Repo health:
pytest-repo-healthruns checks as pytest tests; GitHub Actions enforce standards across all repos - E2E tests: Cypress tests run against a full Tutor-deployed platform; used for regression testing across releases
Relevant Repositories
| Repository | Role in This Feature | Activity Level | Notes |
|---|---|---|---|
| openedx/edx-cookiecutters | Project templates for IDAs, MFEs, XBlocks, plugins | Medium | Onboarding tool |
| openedx/frontend-build | Shared webpack/jest/ESLint for MFEs | High | Build foundation |
| openedx/frontend-template-application | Starter MFE template | Medium | MFE scaffold |
| openedx/edx-repo-health | Repository standards checker | Medium | CI enforcement |
| openedx/cypress-e2e-tests | End-to-end test suite | Medium | Platform regression |
| openedx/code-annotations | PII and toggle annotation tooling | Low | Compliance tooling |
Recent Changes
frontend-buildongoing updates for React 19 / webpack modernization- Cypress test suite expanding coverage
History
Origin
- Year introduced: ~2014–2015 (cookiecutters first used; build tooling evolved with edX)
- Initial implementation: Shell scripts and manual setup; cookiecutters introduced for consistency as the number of repos grew
- Context: As edX decomposed from a monolith to many services and MFEs, consistent tooling became critical for developer productivity
Key Milestones
| Year | Milestone | Teams / People Involved |
|---|---|---|
| ~2015 | edx-cookiecutters introduced | Unknown |
| ~2018–2019 | frontend-build created for MFE tooling consistency | Unknown |
| ~2020 | edx-repo-health for automated standards checking | Unknown |
| ~2022 | Cypress e2e tests established | Unknown |
People Who Shaped This Area
- Engineering: Unknown — open question for interview
- Product: N/A (infrastructure/tooling)
- Design: N/A
Open Questions
- [ ] When were cookiecutter templates introduced and who standardized them?
- [ ] What drove the creation of
frontend-buildas a shared config package? - [ ] What are the most common deviations from the cookiecutter standards in practice?
- [ ] How does the CI pipeline work for testing MFEs against different Open edX named releases?
- [ ] What are the biggest friction points in the Open edX developer onboarding experience?