The most common model of development these days will include at least 3 environments: dev, test and live (A -> B -> C). Perhaps, if you are a single developer working on a site, this will be much less bureaucratic, but you should always have, at least, dev and live (A -> B).

Configuration Management (CM) allows you to move configurations from environment A to B by using files and, basically, you will have to choose to migrate or synchronize (using the tracking functionality).

Migrating configurations between environments

Migrating will skip CM Datastore, since you will simply be importing configurations in the files directly into the Activestore. The workflow for this type of usage is:

• Make the actual tweak of configurations in site A.
• Select the components you have changed and export them as a tar file (only from UI for now).
• Import the tar file from the UI (or from a folder using a drush command) in site B.

The value here is that you can make a lot of configuration changes, export them in bulk, test them and finally import them in a destination environment. It's important to notice that working this way all your configuration changes will be exactly as if they were made manually in the destination site.

Synchronizing configurations between environments

To use this feature you will have to keep track of the components you want to modify in your source site (A). Then in your destination site (B) you will need to update the files in the Datastore so CM will give you relevant information about differences between the Datastore and the Activestore, for you to choose how to deal with them.

Using this feature with some version control system will allow you to fully monitor the file changes in your Datastore as they happen in time, beyond the simple difference between the current DB (Activestore) and the current Datastore itself.

• (Prerequisite) all pertinent components must be tracked in Site A.
• Write all your tracked configuration to Site A Datastore.
• Copy or push / pull (version control) the files from Site A Datastore to overwrite Site B Datastore.
• In Site B check the status for your tracked components to get information about the changes in the Datastore.
• Synchronize configurations. This process will update Site B Activestore to match exactly all the configurations in Datastore, including information about which components you are tracking.

This method is the only way to ensure full consistency between configurations and their dependencies in different environments, but it obviously forces you to deal with all the configuration at once.