Neenu RobinAug. 12, 2019
Odoo.sh is the latest and much more improvised version of Odoo released in the Odoo Enterprise category.
It is Odoo Cloud platform especially designed for end users and is most appropriate for small business. Moreover, Odoo.sh is a full-stack platform with the top-notch features available that will ease the development of an ERP application suite.
With Odoo Enterprise and community versions, deploying Odoo applications on-premises is difficult. But with Odoo. sh Odoo deployment becomes easy. No need to worry about hardware, infrastructure, servers and its maintenance.
1.Github Integration
Odoo.sh use Github account with unique SSH keys. Every commit, pull request, merge or fork tested, and deployed automatically. It is quite evident to watch the odoo.sh transparently get integrated with Github development flow.
Odoo.sh basically needs:
2. Log maintenance
Odoo.sh maintains different types of logs.
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.
Filtering from the logs are possible.
short
3. Web shell
Get a shell access to a production server or a container related to a build, in one click. A shell access to your container. You can perform basic linux command (ls, top) and open a shell on your database by typing psql.
4. SSH
One can easily register their SSH public key and get connected to any server within few clicks. Connect to your builds using ssh. Provided you have the correct access rights on the project, you'll granted ssh access to the build.
5. Mail catcher
The mail catcher available for your development and staging branches as the emails of your production database really sent instead of intercepted.
6. Module dependencies.
Manage dependencies with third party modules with no pain; update when you want. With Odoo.sh, we can add new modules to satisfy our requirement. Moreover, Odoo.sh test the custom modules and add them to our project. We can take clone, fork and merge to our project through our GitHub account.
7. Server status
The status page shows statistics regarding the servers your project uses. It includes the servers availability.
8. Automated tests
With Odoo.sh each and every commits go through a number of automated tests. It helps the developers to save a lot of time, makes the project error free and provides stabilized performance.
9. Staging branches
Odoo.sh offers three different stages for your branches: production, staging and development.
● Development
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 projects settings.
Moreover, 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.
● Staging
Staging branches are meant to test your new features using the production data. Staging branches are built with production data, and stay alive a few weeks for testing. 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.
● Production
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.
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.
In addition to this, additional staging branches allow you to develop and test more features at the same time.
10. Track developments
Odoo.sh gives a detailed history and logs on all development branches to track progress in real time.
It provides 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.
For each event, a status displayed in the top right-hand corner. It can provide information about the ongoing operation on the database (installation, update, backup import, ...), or its result (tests feedback, successful backup import, ...). Above all, when an operation is successful, you can access the database thanks to the connect button.
11. Availability of all community modules
Firstly, Odoo. sh allows to install community modules to test them, in just a few clicks. Install all community modules in one central location.
12. Easy testing with staging server
Staging branches meant to test your new features using the production data. Staging branches are built with production data, and stay alive a few weeks for testing. Thus, 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.
13. Share test builds
Odoo.sh allows to Share your builds with your customer to ease testing (public or private URLs). Here a build 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.
14. System maintenance
In Odoo.sh all three staging servers maintained by Odoo. Monitoring, backups, emails, dns, ci, staging & production servers are also managed by Odoo.
15. Monitoring
This version keeps monitoring the status of all your servers, as well as KPIs about their availability and performance.
16. Incremental backups
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 file store (attachments, binary fields), logs and sessions.
Staging and development databases 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.
Hence, the list contains the backups kept on the server your production database hosted on. This server only keeps one month of backups: 7 daily and 4 weekly backups.
Dedicated backup servers keep the same backups, as well as 3 additional monthly backups. Moreover, you can make a backup manually before making big changes in your production database in case something goes wrong (those manual backups are available for about one week). To avoid abuse, Odoo limit manual backups to 5 per day.
17. Recovery
Recover any backup in just a few clicks, in a production or staging branch. You can contact odoo online service/Help desk to get or restore any of those backups on your live database.
18. DNS
Odoo.sh allows to use customer’s own domain for production server and DNS subdomains for development branches.
19. Great Performance
PostgreSQL and Odoo optimized for top maximum performance.
20. Disaster Recovery
In case of complete disaster, with a data center entirely down for an extended period, preventing the fail over to our local hot-standby (never happened so far, this is the worst-case plan), we have the following objectives:
● RPO (Recovery Point Objective) = 24h. This means you can lose max 24h of work if the data cannot be recovered and we need to restore your latest daily backup.
● RTO (Recovery Time Objective) = 24h for paid subscriptions, 48h for free trials, education offer, premium users, etc. Thus, it is the time to restore the service in a different data center if a disaster occurs and a data center is completely down.
Odoo actively monitor your daily backups, and they replicated in multiple locations on different continents. Odoo have automated provisioning to deploy their services in a new hosting location. Restoring the data based on the backups of the previous day can then be done in a few hours (for the largest clusters), with priority on the paid subscriptions.
In addition, Odoo routinely use both the daily backups and provisioning scripts for daily operations, so both parts of the disaster recovery procedure tested all the time.
21. Database Security
Customer data stored in a dedicated database - no sharing of data between clients. Data access control rules implement complete isolation between customer databases running on the same cluster, no access is possible from one database to another.
22. Password Security
Customer passwords protected with industry-standard PBKDF2+SHA512 encryption (salted + stretched for thousands of rounds). Odoo staff does not have access to your password, and cannot retrieve it for you, the only option if you lose it is to reset it.
Login credentials always transmitted securely over HTTPS. As of Odoo 12.0, customer database administrators even have the option to configure the rate limiting and cool down duration for repeated login attempts.
Password policies: as of Odoo 12 database administrators have a built-in setting for enforcing a minimum user password length. For older versions it is possible to achieve the same effect through customization. Other password policies like required character classes not supported by default because they proven counter-productive
Odoo help-desk staff may sign into your account to access settings related to your support issue. For this they use their own special staff credentials, not your password (which they have no way to know)
This special staff access improves efficiency and security: they can immediately reproduce the problem you are seeing, you never need to share your password, and we can audit and control staff actions separately!
Our Help desk staff strives to respect your privacy as much as possible, and only access files and settings needed to diagnose and resolve your issue.
23. System Security
All Odoo Cloud servers running hardened Linux distributions with up-to-date security patches.
Installations are ad-hoc and minimal to limit the number of services that could contain vulnerabilities (no PHP/MySQL stack for example).
Only a few trusted Odoo engineers have clearance to remotely manage the servers - and access is only possible using SSH key pairs (password authentication disallowed).
24. Physical security
Odoo Cloud servers hosted in trusted data centres in various regions of the world (e.g. OVH, Google Cloud), and they must all exceed our physical security criteria:
25. Credit card safety
Odoo never store credit card information on their systems. Customers credit card information always transmitted securely directly between customer and payment acquirers.
26. Communication
All web connections to client instances, protected with state-of-the-art 256-bit SSL encryption. Moreover, odoo servers kept under a strict security watch, and always patched against the latest SSL vulnerabilities, enjoying Grade A SSL ratings at all times. Odoo SSL certificates use robust 2048-bit modulus with full SHA-2 certificates chains.
27. Network Defense
All data center providers used by Odoo Cloud have very large network capacities, and have designed their infrastructure to withstand the largest Distributed Denial of Service (DDoS) attacks. Furthermore, Their automatic and manual mitigation systems can detect and divert attack traffic at the edge of their multi-continental networks, before it gets the chance to disrupt service availability.
Firewalls and intrusion prevention systems on Odoo Cloud servers help detect and block threats such as brute-force password attacks.
As of Odoo 12.0, customer database administrators even have the option to configure the rate limiting and cool down duration for repeated login attempts.
Odoo.sh support custom apps. Thus, it tests the custom modules automatically and can deploy to the development server. Then, We can take clone, fork and merge to our project through our GitHub account.
Odoo.sh works alongside an online git repository. By default, only free apps can be installed on it, because the underlying git repository is public. However, if the underlying repository set to be private instead, then paid apps can be install on an Odoo.sh instance.
In conclusion, hope you understood how Odoo.sh supports Third Party Applications.
0