Use bazaar:

http://bazaar.canonical.com/

You might like to take a step back for a minute and consider that there is an entire Information Technology discipline devoted to this kind of problem -- DevOps!

It's goal is to achieve zero delay between completion of a task in development and final deployment in production!! Not achievable in any organization larger than one person of course, but the intention is of vital importance nevertheless.

Tools involved :

• Continuous Integration (CI) servers, such as Jenkins
• Functional Integration Testing (FIT) and Behaviour Driven Development (BDD) tools, such as Fitnesse, Cucumber or Freshen
• Configuration Management Servers (CMS), such as Chef, Puppet and Vagrant
• Process automation servers, such as RunDeck, Ansible and Salt
• Browser automation tools like Geb or Selenium
• Version contol servers like Bazaar/Launchpad and Git/GitHub
• Server virtualization, like KVM & VirtualBox

Where Brendan (answer above) says . . .

For those changes, manual propagation seems like the best option. For these changes, make them on the development database, create a document showing your changes, and have another developer attempt to recreate the changes on a copy of production.

. . . DevOps would reply . . .

Every development-to-operations task must be described by executable documentation and tested automatically. Manually tasks on a production server are forbidden. The development process must include development, testing and approval of the automation steps. The steps and the tests of the steps must themselves be version controlled as integral parts of the full system.

I agree with Brendan that it doesn't look like oerpenv can pull database changes from a test db to production. That does not mean it would not be a very useful arrow in your DevOps quiver. I was unaware of it and will begin to use it. But, not manually. I'll call it from RunDeck, which allows me to build a library of scenarios of tasks and keeps gives a permanent log of tasks performed.

The real issue is the number of, and scale of, the sites you have to manage. A small operation (like me :-) ) might just automate a few tasks through Rundeck. A medium team might see a need to have Jenkins build the app, execute unit tests and then call RunDeck jobs to apply data transformations. A large organization might have a team of experts just preparing Cucumber tests for delivery to the Jenkins admin, while the operations sysadmins deploy and provision servers with Chef.

Some of the tools above are a bit like the game Othello -- "Minutes to learn. Years to master." -- so be careful.

Keeping database changes in sync is definitely a challenge when developing for OpenERP. Changes made and tested in a development database need to be well documented and manually propagated to production. Of course, this manual propagation is prone to error when documentation doesn't quite line up with actions taken on the development database.

To combat this, our development team makes as many changes as possible in custom modules, which can then be tested on a clean copy of the production database. While this incurs more development overhead, it also results in fewer errors during deployment.

That said, there's still changes to configurations and other data that can't be cleanly captured in a module (or are small enough that module boilerplate doesn't make sense). For those changes, manual propagation seems like the best option. For these changes, make them on the development database, create a document showing your changes, and have another developer attempt to recreate the changes on a copy of production. Any discrepancy between actions and documentation should hopefully show up during this step.