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.