Development, Testing, Staging and Production model

Question

I'm developing a run of the mill django powered website with a Postgres database. I develop locally and have 3 VPS servers for Testing, Staging and Production. Each VPS runs their own Linux / Apache / Python / Postgres stack, with it's own databases.

What I've begun to find is that with continuous deployment using git, staging has practically become redundant (moving from staging to production requires swapping IP addresses which requires a reboot of the VPS).

The only time I can forsee staging being useful is when a complex database migration needs to happen, and even then as the Postgres databases on staging and production arn't mirrored, there could be problems with losing data that has been input between migrations.

My question(s) is should I be mirroring Postgres between staging and production? (if so, how?) And am I doing it right? I can't really find very much documentation anywhere about web application deployment best practices.

Answer 1

I'd say that you should be mirroring Postgres between staging and production if you think you'll have to do a complex DB migration more than once. Doing migrations manually can be so error prone that you will almost certainly recoup the time investment in setting up the migration.

I'm not a Postgres expert, but here is an overview of replication options.

Answer 2

You can avoid data loss during migration by making live site read-only for the duration of the updgrade.

Answer 3

Presumably you have some backup system for your postgresql database? If so you can use these backups to populate your data in your staging / dev environment. I have some clients that use replication (mainly in MySQL space).

For backups/staging: Production --replication--> Staging --mysqldump --> backup

For development: Backup --mysqlimport--> development

When they need to test on the deployment, they simply break replication. This system is used infrequently (2-4 times per year). The drawback of this is that at some point you have to reset the replication which may require some downtime on the production system.

There are probably cleaner implementations, but they found this works well. The nice thing is that they simply promote the code to the staging system, break replication, and they have basically have a current, live box for regression and application testing.