Odoo Release Pipeline
How to make sure your Odoo server is always up?
Maintaining an ERP it's a very serious business, if the system stops all the company will stop as well. In order to be able to safely manage the development process we have to keep some golden rules untouched.
First one if not deploy anything without passing through a staging instance where we will be able to run tests using secured production data and even involving the customer staff.
Maintaining an ERP it's a very serious business, if the system stops all the company will stop as well.
QA instances should be as similar as possible as the production instance in order to anticipate any differences that can produce different results while doing the tests.
At OdooGAP we have several types of customers, from the smallest to the biggest. Depending on the client size, the server architecture can be very different:
- Same server for Postgresql plus 3 Odoo instances (production, staging and development).
- Separate server for Postgresql plus one server for Production instance and another server for staging and development.
- Separate server for Postgresql plus several servers (load balanced) for Production instance and another server for staging and development.
We usually start with option a) and grow according to customer needs, but the bottom line is that Odoo it's quite scalable. There is also a fourth option deploying Postgresql in a cluster, quite frequently we use AWS RDS. Since we also work with clients that have their own teams, we can manage the deployment on their infrastructure or we can also host it ourselves.
The release cycle
While doing development all new features will be tested on the DEV instance, that's where we make sure that all details are implemented as expected.
It’s very important that the developments we do are used as soon as possible to be able to have feedback from the users and equally important to get the expected return on our client investment. Following the planning, we will complete the releases and a few days before the deployment we will release to QA / Staging.
It’s very important that the developments we do are used as soon as possible to be able to have feedback from the users and equally important to get the expected return on our client investment.
After staging the release we might need to fine tune the last details and then we will be able to merge the release in the production branch and proceed with the planned deployment.
Our GIT workflow
At OdooGAP we like to keep the GIT history linearized as that allows us to have a clear notion of the sequence of coding events, but also has the advantage of disrupting less the Odoo ORM. The Odoo ORM implements changes on the database level. When we create a field in Python code, the ORM will also change the respective database table. Having to switch between different branches that have huge differences on the data model will create misleading instructions at the ORM / Database level and that will make the developers drop and restore databases losing precious development time.
During the release period we separate development between stabilization patches for the staging branch or simply development that targets future releases. After we patch QA we will also rebase the development branch to make sure everything is tight and clean.