Question

I have a Django site running django-cms, and three environments: local dev (currently a sqlite DB that's committed to the repo), staging (mysql), and prod (mysql). There are other django apps in the project that have their own tables in the DB(s), and schema changes are managed through South migrations.

We do development using a "git flow" process, meaning that features are developed in branches and merged into a "develop" branch when complete. From a deployment standpoint, the develop branch maps to the staging version of the website.

I'd like a way to manage data in these environments that doesn't involve manually crafting data migrations for django-cms, or blowing away the staging/prod databases to loaddata in changes.

What's a good working strategy for this? Is there a quasi-automated way to generate South data migrations? Or a way to have django-cms publish pages to different environments?

Was it helpful?

Solution

I run the exact same setup on multiple projects but almost never look to migrate data between dev, stage or production.

Development environments get messy with test data, stage environments get messy with development code and data which doesn't make it to production. Meaning that hopefully production stays clean and tidy.

Following on from this moving data between them should be done carefully and I'd almost never look to automate this in case of erroneous data making it to the production database.

If there is important information which you put in to your staging environment to demo to a client or perform 'final' testing on before deploying to production then I'd suggest performing a data migration with south on that specific app and deploying with that data migration.

For any other types of data migration, like CMS page setup etc, I'd recommend setting things up in CMS draft mode as you need them, them publishing.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top