Odoo Release Pipeline
How to Make Sure Your Odoo Server is Always Up
Maintaining an ERP is important because if the system stops, the company will stop as well. To safely manage the development process we have to keep some golden rules untouched.
First, do not deploy anything without passing through a staging instance where you can run tests using secured production data. You can even involve the customers and staff during the process.
Maintaining an ERP is important because if the system stops the company will stop as well.
QA instances should be as similar as possible to 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 vary.
- Same server for Postgresql plus 3 Odoo instances (production, staging and development).
- Separate server for Postgresql + one server for production instance + another server for staging and development.
- Separate server for Postgresql + several servers (load balanced) for the production instance + another server for staging and development.
We usually start with option A and grow according to our customers’ needs, but the bottom line is that Odoo is 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 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 important that the developments we do are used as soon as possible to get feedback from the users. Furthermore, it’s equally important to get the expected return on our clients’ investments. Following the planning, we will complete the releases and a few days before the deployment we will release to QA/Staging.
It’s important that the developments we do are used as soon as possible to get feedback from the users. It’s equally important to get the expected return on our clients’ investments.
After staging the release, we might need to fine tune the last details. Subsequently we’ll 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 because it allows us to have a clear notion of the sequence of coding events. Additionally, it has the advantage of creating less disruptions for 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. As a result, it 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 developments that target future releases. After we patch QA we’ll also rebase the development branch to make sure everything is tight and clean.