Odoo ERP Continuous Integration and Project Management

Hieu Le

As you may know, ERP stands for Enterprise Resource Planning, typically a suite of integrated applications that an organization can use to collect, store, manage and interpret data from many business activities, including: Marketing and Sales, Supply Chain Management, Materials Requirements Planning, Customer Relationship Management and so on. Implementation of ERP projects, especially long-term projects, requires the ability to scale up, to extend gradually depending on the initial requirements of clients and their increasing needs through the time. In this article, I would like share with you some experiences that may help you to achieve it.
 
Thanks to the source code of Odoo which is open source and designed for scalability, each application is a separate module which can be installed when needed. For instance, initially, an organization just need a small app to manage their human resources, we just install module “HR”. Afterwards, they realize Odoo is good and want to benefit from other Odoo features that help them to manage their customers and sales more efficiently, then we can install more modules such as “Sales”, “CRM” ...

  

As I said above, Odoo is itself an open source, it has a large community of developers and users as well. This is how we can organize source code of an Odoo project to inherit the power of Odoo and its community.

  • bin/: bash scripts to start, stop server, upgrade Odoo modules ...

  • config/: config file for Odoo server

  • extra_addons/: other modules from community

    • git subtree add --prefix extra_addons/purchase-workflow https://github.com/OCA/purchase-workflow.git 8.0 --squash

    • git subtree pull --prefix extra_addons/purchase-workflow https://github.com/OCA/purchase-workflow.git 8.0 --squash

    • git subtree add --prefix extra_addons/sale-workflow https://github.com/OCA/sale-workflow.git 8.0 --squash

    • git subtree pull --prefix extra_addons/sale-workflow https://github.com/OCA/sale-workflow.git 8.0 --squash

  • odoo/: native Odoo modules

    • git subtree add --prefix odoo https://github.com/odoo/odoo.git 8.0 --squash

    • git subtree pull --prefix odoo https://github.com/odoo/odoo.git 8.0 --squash

  • OCB/: OCB Odoo modules from OCA

    • git subtree add --prefix OCB https://github.com/OCA/OCB.git 8.0 --squash

    • git subtree pull --prefix OCB https://github.com/OCA/OCB.git 8.0 --squash

  • project/: specific modules for your project

 

With this structure, we have better quality of source code from Odoo Community Association (OCA) - Odoo Community Backports (OCB) repository. It is based on native Odoo but has more hot fixes and commits from experienced Odoo developers around the world. Also, it has some available cool open source modules developed by the community (for instance, I put some in extra_addons folder) that can be reused and extended to reduce development time. If we prefer very pure and native Odoo, we use Odoo repo. But we can choose only one of them. And Git Subtree technique allows us to pull the code from other GIT repository and to push it back if we want contribute back to the community. Let’s share to be shared! :)
 
Let’s talk a little bit about coding naming convention in source code of an Odoo module. You can also refer to this post and this post for a template module. This is to help to manage and maintain source code more easily and professionally.

  • controllers/: contains controllers (http routes)

  • data/: data xml files

  • demo/: demo xml

  • i18n/: translation *.po files

  • models/: model definitions

  • report/: reporting models (BI/analysis), Webkit/RML print report templates, QWeb report, XLS report

  • security/: access rights, user groups

  • static/: contains the web assets, separated into css/, js/, img/, lib/, ...

  • tests/: unit tests

  • views/: contains the views and templates

  • wizards/: wizard model and views

  • __init__.py: this is used to import python files

  • __openerp__.py: this is used to defind your Odoo module

 

I suggest using SCRUM methodology and GIT source code management system. Normally, a big project is splitted into smaller milestones. Each milestone handles a complete feature or a set of complete features. Deliverables are usually delivered to clients every sprint in a duration from 1 to 4 weeks. SCRUM helps to understand our clients’ requirements more clearly, to perfect the system by collecting their feedbacks for each milestone, and to reach closer to their needs.

 

With the power of GIT, we can easily achieve SCRUM principles. For each milestone, I create a GIT branch to package a set of complete features. I also can create many sub branches I want to do hotfixes. Each branch will be delivered once it becomes perfect enough. There are some GIT tools such as GitHub, GitLab, Bitbucket, … here I use Gitlab. For example, below is one of my projects organized in several branches.

 

Moreover, each task should be committed in a separate branch, then developer should create a GIT merge request to the main branch. Team leader will review code, require adjustments before its quality is good enough to be merged.

During the review and merge code, there might be some conflicts in source code due to the fact that several developers for some reasons can edit the same file. Then we will need a very convenient tool called GIT MergeTool + Meld Diff Viewer.

 

To ensure the high quality, testing phase is also very important for any project. Normally we have 3 instances. Their names can be whatever you want.

  • Development: for internal use, this is where testers manually test the system. Functional consultants can use it to prepare guidelines for end-users.

  • Demo: end-users will validate the system here. They test and give feedbacks to make sure there is no problems when the system will be delivered to Production.

  • Live: this is where the real system takes place. End-users use it everyday to support their business activities.

GIT branches and those 3 instances support continuous integration. For example, we can develop milestone 3.0 in Development, while clients test milestone 2.5 in Demo and use milestone 2.0 in Live. There will be no conflicts and impacts during the development, testing, and going live. 
 
There are several testing techniques can be applicable for Odoo projects. Manual Test is necessary for User Acceptance Testing (UAT). It validates the system from the business and functional users’ point of view. Besides, Automation Test is also very important to validate the system from the developer's point of view. In the chapters below, I will talk about it.
 
The first Automation Test is to use the built-in feature of GitLab called GitLab Continuous Integration (GitLab CI). You can find the full instruction here. In this article, I just list out main steps to run GitLab CI to test each commit on a project in a pre-defined environment, to ensure the project is installable, upgradable and that all tests run without errors. 

  • Step 1: follow this instruction to prepare  the .gitlab-ci.yml to define the jobs, scripts and add it at the root of the project repository.

  • Step 2: follow this instruction to configure a Runner. Connect Runner to Project using CI token at menu Project Settings > Advanced Settings.

  • Step 3: seeing the status of your builds at every commit.

Another Automation Test is the built-in tools in Odoo. The Unittest and the YAML test. There is already a presentation by Alexandre Fayolle, Camptocamp about it here. I suggest using Python files because of its familiar syntax and its integration with Odoo framework.

  • Step 1: developers prepare their test scripts as in the screenshot above.

  • Step 2: start your Odoo server with option --test-enable.

  • Step 3: Tests are automatically run when installing or updating modules if --test-enable was enabled when starting the Odoo server.

This class from openerp.tests.common import TransactionCase is for test cases in which each test method is run in its own transaction, and with its own cursor. The transaction is rolled back and the cursor is closed after each test. So it does not commit anything into your database. As you see on the script, we can use Odoo ORM API such as self.env, self.env.create, self.env.write, self.env.unlink … just like when we build an Odoo module.
 
Some notes if you use YAML test, please check it yourself because I did it in Odoo 7 a long time ago. Now it might be different. There is also an article about it here.

  • In your __openerp__.py file, do not forget to add section 'test' to import your YAML files:

  • Start your Odoo server with option --test-enable -d {your_testing_database_name}

  • Use option --test-commit if you want to Commit database changes performed by YAML or XML tests.

Besides the techniques above, Nils Hamerlinck also spent some time to research about Odoo Robot Framework and Selenium to test Odoo, so I don’t write about it in this article. You can refer to his interesting article here. You can also visit Odoo Runbot server by Odoo.
 
In conclusion, nowadays Odoo is more and more popular in the world because there are a lot of Small and Medium Enterprises, and Odoo is open-source, low cost and designed for them. But some big companies love Odoo, following by big and long-term projects, so Odoo is improved day by day. For those kinds of project, continuous integration and high quality assurance are very important to the project success. Personally, I love working in Odoo projects. I work much more efficiently in management and analysis roles because it is my strengths, and it is suitable for my career objective to become a truly professional Project Manager or Business Analyst. But for me it is also interesting to spend some time on some technical parts, as long as my projects can move smoothly with high quality to satisfy my clients.