There have been several recent efforts to improve the Open edX development environment, but it’s sometimes unclear how they fit together or which areas are most important to focus additional effort on. In order to assist with planning and prioritization in this area, I’ve written up a draft Development Environment Vision document in Confluence to suggest a possible target end state and start prioritizing work to get us there.
Please add comments to the document or in this thread if you have any questions, concerns, or suggestions for improvement. About 10 people have provided useful feedback on an earlier draft of this document, but I’d now like to open it up for broader review and feedback.
Overall I think it’s a great document! We all have an intuitive understanding of what a good development environment should be, but this document converts this intuition into more precise words, so thanks for that.
I got some good feedback on this and after an edit today regarding Kubernetes vs. docker-compose usage, I think I’ve addressed all the points that were raised. If I missed anything or you haven’t provided your feedback yet, please speak up. But otherwise I think we have consensus on generally what we want to accomplish, if not necessarily the details of how to do it.
To that end, the following efforts aligned with the next steps outlined in the doc are already in progress:
The Development Experience Working Group is coordinating efforts to iteratively improve Tutor. One desired outcome of this is that it becomes easier to use Tutor for development on the main/master branches across more Open edX services.
The Arbi-BOM team is making good progress on Switch to Ansible-free Docker images · Issue #943 · openedx/devstack · GitHub to make sure each service repository has a Dockerfile which produces useful orchestration-independent Docker images for both production and development (and switching devstack over to using these).
The remaining next steps are currently queued up for the Arch-BOM team to work on primarily due to lack of development bandwidth to do them in parallel: