Odoo Migrations

My question is: What is the best way to update modules/apps on production(if we have many changes in fields of models and views)?

While this question has been around for a while I cannot see any canonical answer therefore here are my two cents.

The problem of migration from one version to another in Odoo is rather common and definitely complicated. With that in mind the OpenUpgrade project has been created. OpenUpgrade is basically an upgrade path that will help you transform your data and models from version A to version B. For example if a field named fieldA has had its type changed on version 9 and you are on version 8, OpenUpgrade will take care of this by doing the necessary transformations.

OpenUpgrade also gives you the possibility to create your own migration scripts that will do whatever needs to be done in order for your module to be forward ported (or back ported) in various versions. For the standard modules these scripts have already been written to an extend, but for your own you might need to do some writing.

I suggest that you take a look at the documentation above, this is basically your first stop when we talk about migrations in Odoo.

First you have to dump the production database and then restore it in your local system.

Once restored in local system, develop your custom modules to expand the existing model features.

Install the developed modules in local system(restored database) and see the changes you made. If everything is perfect with existing data, then Install that module in production database.

To dump the production database execute the below command in postgres.Command : pg_dump dbname > outfileExample : pg_dump prod_db > prod_db.sql

Before restoring the database, you have to create fresh database in your local system. To create fresh database execute the below command,command : createdb --owner owner_name --encoding utf-8 dbnameExample : createdb --owner odoo --encoding utf-8 prod_db

To restore the production database execute the below command in postgres.Command : psql dbname < infile pathExample : pg_dump prod_db > prod_db.sql

Restart the server from the command line once with the -u and -d flagseg.

sudo service odoo stop/path/to/odoo/odoo.py -d <your_db_name> -u custom_module1,custom_module2

If you're dealing with a production server, I would test this locally, on your development machine with a fresh dump of the production DB make sure it works, tweak it if needed (eg some fields might need defaults, whatever), test it again on yet another fresh dump, until the point that all I need to do is restart the server as above to make the changes happen.Once that happens, back up the database, datastore and even the affected modules on the production server, upload the new module(s) and restart the production server as above (no dumping databases from test to production here) the module update should take care of database changes.

If you're trying to change the structure of a table considerably (eg changing fields datatype) and retain data in tables the only way I can think of doing this is to create add NEW fields first with the new datatype, populate them with data from old fields (either directly with postgres queries or within your "interim version module") and this really depends on the changes, a change from selection to many2one involves inserting selection values into a new table, two very different things from the database point of view the actual field type on the table will be a integer, the ID from the row that holds the selection value in a relational table...

Once your new fields are populated, make the final version of the module removing all the fields you no longer need (keep the other version for the production database).

I would probably test the database population manually on the development server first either in postgres or with some tool like pgadminIII, but plan on creating a script for doing it on the production server (or better yet build it all into the new module version) as it will have to be down while that happens.

I would also look at my postgres tables after it's all done, some fields might still be there even if the new module doesn't use them.

Sorry, I don't know of any simpler, more automatic way of doing it, there just is too many variables...