Odoo Help

Welcome!

This community is for beginners and experts willing to share their Odoo knowledge. It's not a forum to discuss ideas, but a knowledge base of questions and their answers.

3

Development / Production

By
dave ellis
on 3/7/13, 9:56 AM 4,201 views

I have been thinking about the development of an OpenERP instance. What I want to do, is to have two databases. One is development database, I will duplicate that for live initially.

That part is easy, but what I want to do is to develop on the seperate database, but push changes over to the product server automatically, where possible. Has anyone tried a dev/prod environment before? If so, how were the changes push across?

Or do most people just document the changes and do the same on the PROD server?

2
agb80
On 3/7/13, 11:31 AM

Personally I don't have tried this https://pypi.python.org/pypi/oerpenv/1.7.61 but seems to me as the most promising option for make exactly what you want: easy setup of diferent environments with diferent/same databases.

Ah, that sounds like the tool that might do the job.

dave ellis
on 3/7/13, 11:47 AM

From what I can tell, oerpenv creates different versions of servers, but not necessarily databases. It doesn't look like it can pull database changes from a test db to production.

Brendan Clune
on 3/7/13, 12:14 PM

Also, I see no way to tell it to use V7 or V6.1, without digging into the Python code.

Martin
on 3/10/13, 8:48 AM
4
Jānis
On 3/7/13, 10:48 AM

Hi thanks for your response. How I can use Bazaar to push database changes over my existing production server? I understood Bazaar to be a project/version control system?

dave ellis
on 3/7/13, 10:56 AM

Use a versioning system for a database never would be a good idea because at the end you are going to make lot of manual merges.

agb80
on 3/7/13, 11:30 AM

"Use bazaar" + a link is not really an answer.

Daniel Reis
on 3/8/13, 5:43 AM
3

Martin

--Martin--
1978
| 5 6 8
Cornwall, Canada
--Martin--

Analysing, designing, coding and mentoring since 1975. Kilobytes to terabytes. Punch cards to punchy sites. My OpenERP video series: http://www.youtube.com/playlist?list=PLq7op4J183lX44ZlXPiHxUpRvmmRDtxye My Google Speadsheets --> OpenERP Data Pump project: http://martinhbramwell.github.io/GData_OpenERP_Data_Pump My email (with spaces removed) : mhb . warehouseman @ gmail . com

Martin
On 3/9/13, 7:23 PM

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.

2
Brendan Clune
On 3/7/13, 12:11 PM

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.

Your Answer

Please try to give a substantial answer. If you wanted to comment on the question or answer, just use the commenting tool. Please remember that you can always revise your answers - no need to answer the same question twice. Also, please don't forget to vote - it really helps to select the best questions and answers!

About This Community

This community is for professionals and enthusiasts of our products and services. Read Guidelines

Question tools

2 follower(s)

Stats

Asked: 3/7/13, 9:56 AM
Seen: 4201 times
Last updated: 3/16/15, 8:10 AM