Odoo’s Take on Keeping a Massive Project Clean

The codebase of the Odoo platform is incredibly massive, sizing up to 1.3 million lines of code (calculated with cloc1, excluding POT files which are mostly translations), aggregated since 2005. Keeping this code clean is a difficult task, especially since it’s written mainly in Python and Javascript—languages that do not offer so much compile-time checking as C# or Java for example. In this article, we investigate how Odoo controls the project to keep its quality high.

Development Process

The development process of Odoo consists of a few key concepts. This section examines these concepts.

Automation is Key

Odoo has automated much of its development processes, which everyone can experience when submitting a pull request (PR) to their repository. They created a pipeline of quality assurance checks which are executed by a specially set up service mergebot2. These checks validate if:

  1. authors of commits signed the Contributor License Agreement3;
  2. tests succeed;
  3. version upgrade will succeed on master;
  4. code is styled correctly;
  5. security checks are valid;
  6. specified merge method is correct;
  7. PR was approved.

The first 6 checks are performed automatically by different services in parallel. If they succeed, a developer will review the change and either suggest further work or trigger an automatic merge process.

Release Management

Odoo releases its software also to be installed on client’s machines (much like a desktop application). This means that it doesn’t have the option of frequent updates as it has in the cloud-hosted case. Because of that extra care from the testers and QAs is being put to make the released versions stable. Looking at the deployments of Docker images4 we can see that Odoo has made a shift towards monthly deployments in August 2020 and even to weekly deployments this year.

Besides the frequent update, Odoo also releases major versions when new big features are introduced or behaviour of old apps is changed 5. This however means that many versions of the product are simultaneously installed in the world. To allow maintenance of them Odoo is keeping a branch for every released version. The figure below (image from 6) shows what changes can go on which branch. Odoo 14 is the latest version released in October 2020 and version 11 has recently lost technical support.

Figure: What changes go in which Odoo Branch

Testing

As mentioned in the previous post, the Odoo project supports three types of tests, designed to be implemented and executed on a test database:

Python unit tests for testing the logic, Javascript unit tests for testing javascript code in isolation, and integration tests (tours) to simulate real situations. Within these tests, there are also different appropriate test classes available. For example, the TransactionCase7 where every test contains an independent transaction that is not committed. In turn, the SavepointCase is used for executing a set of tasks using one transaction, making it well suited for test classes that require a large setup. This is useful because the savepoint rolls back every side effect of the test setup.

As for the realisation, every module has a test folder with class names containing the test_ prefix. During the development process, developers can run these tests locally on an Odoo server, or by runbot8. Runbot is a hosted environment, working with mergebot (see the Automation is Key section), that automatically runs all tests contained within every module every time the project is built. Merging a pull request is not possible if any tests fail. This ensures that modules act like expected because any addon could modify the behaviour of other parts of the system7. While Odoo tries to facilitate an infrastructure built for testing, they do not evaluate or assign a minimum test coverage.

Future and Past Hotspot Components

Within the Human Resources (HR) module, which was discussed in the previous post, the past hotspots are the hr, hr_holidays, hr_recruitment, and hr_expense addons. These components were mostly changed in the view component, meaning that the client view was often altered. Together with the views, models also needed to be adapted frequently because of their compatibility. The HR toolkit consists of a variety of hr addons and thus the code must be altered to keep it compatible. As there is no real roadmap for this module, the future hotspots within it are hard to predict.

Within the whole project, the most modified files are in the i18n (internationalization) maps. These contain translations for all the text parts within a module. In order to change parts of these files, Odoo employs a different platform: Transifex9. Transifex allows for easy line-by-line translation that is accessible to inexperienced programmers. Changing these lines costs relatively low effort and commits are handled within the Odoo project. This internationalization was also part of increasing the accessibility from the roadmap of Odoo (see Odoo Product Vision). In addition, the most changed modules are the accounting, stocks, mail, and website builder modules. Looking at the open issues, these modules will probably remain hotspots in the future, as many bugs have been reported within these apps.

Code Quality

Code quality is one of the most important aspects of software projects. It is determinant for many requirements of the system. By structuring their code and dividing functionality, Odoo ensures that their system is maintainable and highly usable for developers, with the possibility for high interoperability.

As has been mentioned in a previous essay10, Odoo structures their code by using addons. Every application within Odoo’s suite of applications consists of certain addons. By dividing their functionality this way, the codebase is more modular. This increases maintainability and usability; changes in the code will not affect the whole codebase and since the code is modular, it is easier for (new) developers to understand its structure.

The usage of XML-RPC or JSON-RP makes it possible for applications to communicate with each other. This allows applications to work with each other, as well as with software outside of the Odoo codebase, which increases interoperability and therefore the compatibility of the software.

Quality Culture

An important factor to ensure high-quality code in the codebase is by having a good quality culture. This represents the mindset of contributors. It is the way they interact with each other in order to ensure that the codebase is of high quality. After analyzing many issues and pull requests (PR’s), we have made some observations about the quality culture within Odoo. The contributors within Odoo communicate very well with each other and seem efficient and critical. We also noticed that there are many issues and PR’s that have never been closed.

When going through the issues and pull requests in Odoo, the discussions that take place in the comments consist of messages that are often clear and precise. The contributors often tag each other, asking their peers to have a look at a certain issue/pr. There seems to be a lot of communication and collaboration between the contributors of Odoo.

Another thing that was noticed was that all of the messages that were seen were related to Odoo. This suggests that the overall culture agrees to be efficient when interacting. Most of the messages that are exchanged have to do with fixing the issue or verifying whether it is a valid one.

That brings us to the next observation. Many comments have been seen where contributors tried to examine if an issue/pr was really necessary. This has a positive impact on the quality culture, as being critical filters out contributions that would not benefit the software.

Finally, we also observed that a lot of issues and PR’s have never been closed. This can have many reasons. For example, it could be the code that was targeted with some issue/pr has gotten obsolete or maybe developers could not find a fix for it.

Technical Debt

Within the Odoo HR toolkit, it’s apparent that the main developers took great care in ensuring all the modules have little technical debt. Each module in the toolkit has roughly the same structure and the structure is mindful of the separation of concerns. For example, a module can contain an “i18n” folder that contains the translated text used in the module, a “models” folder that contains all files related to the business logic of the module, and many others. As a result of the neat separation introducing changes to the module is easier, and it’s harder to accumulate technical debt because the module structure is clear and explicit. Nonetheless, the code is not perfect. The code doesn’t contain comments on functions and classes to explain them or their larger interaction in the module. This is a form of technical debt as newcomers will have a harder time modifying or extending the module. In fact, even existing developers might have a hard time as they might have forgotten what exactly intent was behind certain functions and classes. This lack of commenting is consistent across all modules in the toolkit. Furthermore, the larger Odoo eco-system (beyond the HR toolkit) could benefit from a folder restructuring. Albeit individual modules (which are a part of a toolkit) do have a clear folder structure, all modules (across all toolkits) are placed in a single folder which is a major technical debt issue. Any developer wanting to change a particular module will first have to find the module in a list of over 100 modules. Working across multiple modules becomes cumbersome as developers have to spend time finding the module in a long list. As a result of this type of structuring, it becomes harder and time-costly to modify or extend the system. This folder structuring issue can be resolved by placing each toolkit with all its modules related within a single toolkit folder.

Conclusion

Throughout its history, the Odoo project, as all large projects, accumulated some technical debt. Some examples are the bad directory structure and lack of comments. Odoo developers addressed some of those issues with a well-designed automated pipeline that maintains a level of code quality. This way, the debt does not increase. Finally, the developers—both the Odoo employees and the open-source contributors—share the care to keep the quality high.

  1. AlDanial. (n.d.). Aldanial/cloc. https://github.com/AlDanial/cloc. ↩︎

  2. Odoo. (n.d.). mergebot dashboard | mergebot.odoo.com. Odoo Runbot. https://mergebot.odoo.com/runbot_merge ↩︎

  3. Odoo. (n.d.). odoo/odoo. GitHub. https://github.com/odoo/odoo/blob/14.0/doc/cla/sign-cla.md. ↩︎

  4. Docker-Library. (n.d.). docker-library/official-images. GitHub. https://github.com/docker-library/official-images/commits/master/library/odoo. ↩︎

  5. Odoo. (2020, October). Odoo 14 Release Notes. Odoo S.A. https://www.odoo.com/odoo-14-release-notes. ↩︎

  6. Odoo. (2020, October). odoo/odoo. GitHub. https://github.com/odoo/odoo/wiki/Contributing. ↩︎

  7. Odoo. (2020, October). Testing Odoo. https://www.odoo.com/documentation/14.0/reference/testing.html. ↩︎

  8. Odoo. (n.d.). Runbot R&D. https://runbot.odoo.com/. ↩︎

  9. Transifex. (2020, October). The Odoo 14.0 Translation Project on Transifex. Localization Platform for Translating Digital Content. https://www.transifex.com/odoo/odoo-14/dashboard/. ↩︎

  10. El Attar, B., El Haji, K., Westfalewicz, A., & Bharos, A. (2021, March 15). Odoo - Modified web architecture of the HR toolkit. DESOSA. https://2021.desosa.nl/projects/odoo/posts/essay_2/. ↩︎