Why Odoo.sh?
There is the previous version of Odoo such as Odoo Online or Odoo On-premise (Odoo Enterprise) where there were certain disadvantages of using these 2 solutions.
Odoo Online platform is very easy to set up without any technical knowledge but you cannot create any custom code or Custom development of the software which is required by almost every client as the processes are different, the business flow is different.
With Odoo On-premise Enterprise Edition, you can use the custom module or 3rd party applications with Odoo On-premise.
But you need to either have technical knowledge towards the installation of Odoo Enterprise edition and also need support from partners/ Developers for maintenance if you are not technical and programming knowledge.
To overcome these disadvantages Odoo introduced Odoo sh.
Services and Features
Continuous Integration, Testing and Deployment: Develop new features and test them with the production data in isolated staging environments. When ready, merge them into production in a few clicks.
Github Integration: Every commit will be tested and deployed in a separate environment.
Odoo Apps Integration: Apps from the appstore can be tested in staging environments and installed in a few clicks.
Shell Access: Access a shell to any of your environments from your browser.
Monitoring: Connect to any of your servers through SSH. Authentication is pre-configured based on your Github Account's SSH key(s).
Online Editor: View and edit files, start & stop your development servers while editing the source files, commit the changes when you're done. All this can be done through your browser.
DNS & Email: Automatically set up for you by Odoo. An email server and domain name is set up for you by default. You can configure additional domain names or use your own email servers as well.
Storage Replication: All data is replicated live multiple times to ensure no data is lost in case of hardware failure.
Backups: Every day your production database is backed up and kept on 3 different backup servers spread across multiple regions. Backups are kept up to 3 months.
Unlimited Accounts: You can have an unlimited amount of developers, testers and other that log into Odoo.sh and use its features.
Unlimited Dev Branches: Have as many branches in development as you like, each commit will be tested and deployed.
Stages For Branch in Odoo.sh
Odoo.sh offers three different stages for your branches
Production
Staging
Development
You can change the stage of a branch by drag and dropping it on the stage section title.
Production Branch
This is the branch holding the code on which your production database run. There can be only one production branch.
When you push a new commit in this branch, your production server is updated with the code of the new revision and is then restarted.
If your changes require the update of a module, such as a change in a form view, and you want it to be performed automatically, increase the version number of the module in its manifest (__manifest__.py). The platform will then take care to perform the update during which the instance will be held temporarily unavailable for maintenance reason.
This method is equivalent to perform an upgrade of the module through the Apps menu, or through the -u switch of the command line.
In the case, the changes in the commit prevent the server to restart, or if the modules update fails, the server is automatically reverted to the previous successful code revision and the database is roll-backed as it was before the update. You still have access to the log of the failed update, so you can troubleshoot it.
The demo data is not loaded, as it is not meant to be used in a production database. The unit tests are not performed, as it would increase the unavailability time of the production database during the updates.
Partners using trial projects should be aware of their production branch, along with all the staging branches, will automatically be set back to the development stage after 15 days.
Staging Branch
Staging branches are meant to test your new features using the production data.
Pushing a new commit in one of these branches will either * start a new server, using a duplicate of the production database and the new revision of the branch * or update the previous database running on the branch, depending on the push behavior configured in the branch's settings.
You can, therefore, test your latest features using the production data without compromising the actual production database with test records.
The outgoing emails are not sent: They are intercepted by the mail catcher, which provides an interface to preview the emails sent by your database. That way, you do not have to worry about sending test emails to your contacts.
Scheduled actions are disabled. If you want to test them, you have to enable them or trigger their action manually. Be careful though: If these actions perform changes on third-party services (FTP servers, email servers, ...) used by your production database as well, you might cause unwanted changes in your production.
The latest database will be kept alive indefinitely, older ones may get garbage collected automatically. If you make configuration changes or view changes in these branches, make sure to document them or write them directly in the modules of the branch, using XML data files overriding the default configuration or views.
The unit tests are not performed as, in Odoo, they currently rely on the demo data, which is not loaded in the production database. In the future, if Odoo supports to run the unit tests without the demo data, Odoo.sh will then consider running the tests on staging databases.
Development Branch
Development branches create new databases using the demo data to run the unit tests. The modules installed and tested by default are the ones included in your branches. You can change this list of modules to install in your project's settings.
You can change this list of modules to install in your project's settings.
When you push a new commit in one of these branches, a new server is started, with a database created from scratch and the new revision of the branch. The demo data is loaded, and the unit tests are performed. This verifies your changes do not break any of the features tested by them.
Similar to staging branches, the emails are not sent: They are intercepted by the mail catcher.
The databases created for development branches are meant to live around three days. After that, they can be garbage collected automatically.
Builds
In Odoo.sh, a build is considered as a database loaded by an Odoo server running on a specific revision of your project repository in a containerized environment. Its purpose is to test the well-behavior of the server, the database and the features with this revision.
In this view, a row represents a branch, and a cell of a row represents a build of this branch.Most of the time, builds are created following pushes on your Github repository branches. They can be created as well when you do other operations, such as importing a database on Odoo.sh or asking a rebuild for a branch in your project.
Merging Your Branches
You can merge your branches easily by drag and dropping them on each other.
When you want to test the changes in your development branches with the production data, you can either:
- Merge the development branch into your staging branch, by drag and drop it onto the desired staging branch
- Drag and dropping the development branch on the staging section title, to make it become a staging branch
Merging a staging branch in the production branch only merges the source code: Any configuration changes you made in the staging databases are not passed to the production database.
History Tab
An overview of your branch history
The messages of the commits and their authors
The various events linked to the platform, such as stage changes, database imports, backup restores.
Mails Tab
This tab contains the mail catcher. It displays an overview of the emails sent by your database.
The mail catcher is available for your development and staging branches as the emails of your production database are really sent instead of being intercepted.
Shell-Tab
Shell access to your container.
You can perform basic Linux command (ls, top) and open a shell on your database by typing psql.
Logs Tab
Different logs are available:
- install.log: The logs of the database installation. In a development branch, the logs of the tests are included.
- pip.log: The logs of the Python dependencies installation.
- odoo.log: The logs of the running server.
- update.log: The logs of the database updates. This is available only for the production database.
If new lines are added in the logs, they will be displayed automatically. If you scroll to the bottom, the browser will scroll automatically each time a new line is added. You can pause the logs fetching by clicking on the according button in the upper right corner of the view. The fetching is automatically stopped after 5 minutes. You can restart it using the play button.
Backups
A list of the backups available for download and restore, the ability to perform a manual backup and to import a database.
Odoo.sh makes daily backups of the production database. It keeps 7 daily, 4 weekly and 3 monthly backups. Each backup includes the database dump, the filestore (attachments, binary fields), logs and sessions.
Staging and development databases are not backed up. You nevertheless have the possibility to restore a backup of the production database in your staging branches, for testing purposes, or to manually recover data that has been deleted by accident from the production database.
Feel free to contact us anytime and get the proper knowledge on Odoo ERP system.
We will help you in creating a complete Odoo ERP system for your organization and fulfill all your requirements for an ERP system