This blog post was written by our team member Aayush Agrawal
At OpenCraft, we do a lot of feature development for our clients. While the Open edX platform is great and feature-packed out of the box, the best part is its extensibility. And we take full advantage of that when we need to develop a new feature.
When developing a new feature, we believe the following two considerations are the most important of all:
So, usually, in addition to internal reviews, our code is reviewed by edX. To ease this process, our instance manager monitors repositories and automatically creates sandboxes, allowing testing of the feature without installing the platform locally.
It’s worth mentioning that we are members of edX's prestigious Core Committers program, which means we are involved in the process of designing, implementing, and reviewing new features for the global platform roadmap.
We aim to help our clients with the design process: We talk with them so that we can understand their needs, and then we envision how to fill the gap with a new feature.
At OpenCraft, developing a new feature starts with a technical discovery. This is where we create a document that lays down the scope of the work to be done, a description of our approach as to how to do it, a list of tasks, and how much time it will take. We then send this document to our clients to review and approve, and we’re off!
As already mentioned, we put a lot of effort into designing new features in a way that they can be included in the Open edX codebase. This allows us to keep sources open and guarantees the best possible quality, because edX keeps standards high and reviews contributions rigorously. That’s why discussions with edX and other members in the community are an important part of our work. For example, we participate in Open edX releases preparation, are active on community forums and in Slack, and maintain some popular Open edX extensions.
After having signed off on the scope of the work, it’s a simple task of getting to it!
A good practice in this step is getting all code covered with tests, and reviewed by another developer before merging. We make a lot of use of our open source instance manager and create testing sandboxes for everything. Only after ensuring that everything works as expected, we deploy changes using blue / green strategy, so we can easily roll back in case of unexpected issues.
At OpenCraft, we believe in Open Source. Depending on the work done here, we might be creating new modules like XBlocks and Django Apps in which case we’d upstream them by uploading them to our public GitHub or GitLab accounts for everybody to use and improve.
But some changes require changes to the Open edX platform itself. In this case, after a ticket has been through our thorough internal quality control, we’ll submit it to Open edX Core Committers for review. Core Committers are trusted, long-standing members of the Open edX community who have been granted permission to review and merge code into the Open edX codebase. OpenCraft has multiple Core Committers within its team, which is a great token of trust from edX!
Finally, delivery! Once the work is done, approved, and merged into the platform if needed, we are ready to deliver the finished product. This might mean installing a new XBlock or App that was created, or it might be as simple as redeploying the client’s Open edX instance to include the latest changes.
While the roadmap above is the standard process, it’s not always a straight line. Sometimes we work with features that are interconnected, or maybe we have multiple review passes, or requirements change down the line etc. But no matter what happens, we are always committed to the two pillars of OpenCraft’s success: Quality Code and Open Source.
If you’re interested in having a feature developed for your OpenEdX deployment, feel free to drop us a note! You can contact OpenCraft at this link.