It is generally agreed that cloning the database downstream (that is, from development toward production) is a bad idea, if only because by doing so all production content is lost; most developers use Features, Context, Configuration management (Drupal 8), some variation on a site deployment module, or a rudimentary written procedure to move new configuration downstream.
However, in a dev-stage-production workflow, the database is often still periodically cloned back upstream from production to development.
This is a bad idea because your database is not under version control; if our code depends on a database to do anything useful, we think we are using version control, but we are not really using version control at all.
In this talk I will discuss:
- How you can use a site deployment module and dummy content to reproduce a reliable, versioned dev or testing environment without cloning the database.
- How to use Drupal 8's new, and excellent, configuration management system, which replaces a Features-based workflow.
- Three recent project on which I worked, where the database was never cloned upstream, including a very large project (and winner of the Acquia partner site of the year, transit), Société de transport de Montréal; also including my very own blog, a tiny project (this method is scalable!)
- How to bring new developers online in minutes with a dev environment.
- How continuous integration and DevOps methods are made more robust by not cloning the database upstream.
- Three cases in which cloning the database upstream is useful.
- How to use a two-line script to install a fully-functional new environment of your website, with or without realistic dummy content.
Please note that this talk will not touch on content staging.
Further reading:
- Log in to post comments