One goal of DevOps is to create reproducible, production-like environments from source-code repositories. To achieve this, I believe it's necessary to also restore all the data that is needed to setup the environment, so that automated & manual tests can be run there.

For example, let's take a CMS product that provides content (labels, images, rich-text) to a user-facing web application. We want to run integrations tests or explorative UI tests against that web application using production-like data from the CMS. Due to the nature of the product, the data itself can be manipulated at any time by users using the UI of the CMS.

There are two main use cases

• Developers create example content or add required label translations for new features
• Content managers publish new content for production

In a typical setup, there are at least two environments, let's say staging and production. Due to the use cases described above, the CMS databases where the contents are stored will deviate quite quickly between these environments.

Without taking any measures here, after a while, the two databases will be completely out-of-sync and the staging database will not be "production-like" anymore. Additionally, each release of a new feature will require manual steps to add data like label translations into the production database, a step that is neither verified nor tested before the release.

So my question is: What is a good way to bring new "baseline" data from a staging database into a production database without overriding the changes there. And was is a good way to bring back data from production into the staging environment, to provide production-like data for testing purposes. Ideally, all automated and all part of version-control.

Side Note: If we say "different CMS content doesn't change anything about testing", let's think of another use-case where the data behaves even more like configuration. For example, payment or delivery options that are offered on an e-Commerce site.

One goal of DevOps is to create reproducible, production-like environments from source-code repositories. To achieve this, I believe it's necessary to also restore all the data that is needed to setup the environment, so that automated & manual tests can be run there.

For example, let's take a CMS product that provides content (labels, images, rich-text) to a user-facing web application. We want to run integrations tests or explorative UI tests against that web application using production-like data from the CMS. Due to the nature of the product, the data itself can be manipulated at any time by users using the UI of the CMS.

There are two main use cases

• Developers create example content or add required label translations for new features
• Content managers publish new content for production, which may include static content like label translations

In a typical setup, there are at least two environments, let's say staging and production. Due to the use cases described above, the CMS databases where the contents are stored will deviate quite quickly between these environments.

Without taking any measures here, after a while, the two databases will be completely out-of-sync and the staging database will not be "production-like" anymore. Additionally, each release of a new feature will require manual steps to add data like label translations into the production database, a step that is neither verified nor tested before the release.

So my question is: What is a good way to bring new "baseline" data from a staging database into a production database without overriding the changes there. And was is a good way to bring back data from production into the staging environment, to provide production-like data for testing purposes. Ideally, all automated and all part of version-control.

Side Note: If we say "different CMS content doesn't change anything about testing", let's think of another use-case where the data behaves even more like configuration. For example, payment or delivery options that are offered on an e-Commerce site.