Exporting admin panel settings that are saved to the database

Question

When handling different environments for dev and live sites, how to pass on changes that are only saved to the database to the other environment without having to export the whole database? Say for example I disabled an extension, changed the content of a static block, created a new static cms page, added a new shipping method, tax rule, or what have you. How do I pass on small changes like this to the live site without having to export and import the entire database? Obviously there is information on the live site that I wouldn't want overridden.

I'm sure someone else must have run into this, specially when using version control. We have implemented git, but that only works for file level changes. The files in both environments can be exactly the same but some config in the database can change so they behave differently.

I could keep track of all the changes I make in the admin panel, and then reproduce them in the other environment, but that seems very unpractical. The number of changes can be quite large as we are continuously tweaking the site to our satisfaction. Besides, other developers are working as well, and we even set up an environment for outsourced developers and technical support from Magento extension providers. I can't keep track of everything they do.

I've seen tons of posts on exporting products only, so that is not really the problem. I would like the other way around. Maybe someone has made a list of all tables required to clone a Magento site without products and orders and customer information. Just everything that is configurable in the admin panel.

Has anybody done this before?

---

UPDATE: For the readers, I'm marking @mbalparda's answer on manual deploy files as accepted until something else comes up that does as required. I will enforce rules to keep logs on the changes in the admin panel from all developers involved so we have one unified list at the end. It isn't actually the answer to the question but it is the method I will use to solve this until I find a better process.

Answer 1

core_config_data and core_resources are two good places to start. cms_* should have most of the relevant information about blocks, cms and widgets. Beside those tables, most of the core_* tables have some relevant information about the website you are running.

The list is far from complete.

Another good option is to keep a version of the database in GIT and use a diff tool to see what changed between releases but it might have some security issues since personal info might be in the repo.

A good practice i often use is to have a manual deploy file to save all the changes we made in another environment and once the code is deployed, the next step is to check the manual deploy file to see if something needs to be done. This is used in cases where not all the changes can be made with sql/data updates, the regular Magento way to make sql/data changes.

As a note, moving the databases between environments is not always the best choice since changes an admin might have made in the live site will be lost if they are not replicated in the DB you are using in the other environment.

Answer 2

The Magento database is not your usual database. It's large and complicated.
Moving parts of it from one environment to an other is no small task.
That's why I usually avoid changing config settings or adding blocks and/or pages manually.
I let the client do that only on the live server.

What I need to do while developing I do it via upgrade scripts.
This way everything is versioned and portable.
I know it's kind of a drag to write an upgrade script just for removing the list display mode for product pages for example, but I didn't find a better way so far.

Here is a small example of how you can change a config setting via upgrade script.

The following enables the flatrate shipping:

$path = 'carriers/tablerate/active';
$config = Mage::getModel('core/config_data')->load($path, 'path');
$config->setValue('1')->setPath($path);
$config->save();

I guess this could work if you put it in an upgrade script inside sql/[resource_name_here] but for data manipulation I use data/[resource_name_here].

Here is an other script that adds a static block.

$block = Mage::getModel('cms/block');
$block->setTitle('Some title here');
$block->setIdentifier('identifier_here');
$block->setContent('This is the content');
$block->setStatus(1);//enabled
$block->setStores(array(0)); //make it available in all stores
$block->save();

You can basically do this for every entity you have.

Answer 3

I found a lovely tool to export and import configuration settings https://github.com/Zookal/HarrisStreet-ImpEx

This does a lot of what you guys and me are looking for I think.