Using animated gifs of various forms of ‘shipping’ and ‘launching’ (from epic fail to epicly successful), Robert Douglass (who I last saw – albeit far less beardy – at DrupalCamp Scotland) outlined how developers should practice OCD deployment.
While this could mean having obsessive compulsive disorder (and this did confuse my twitter friends who work in medicine) he was actually suggesting that deployments should be orchestrated, consistent, and deterministic.
He also separated deployments into three separate elements – the code, infrastructure, and data (the latter one if often a pain!)
While at first glance it might seem that most Drupal deployment have local, staging, and live, Douglass pointed out that the reality can be far more complicated.
— Rachel Lawson (@rachel_norfolk) March 1, 2015
He broke OCD deployment into the folllowing:
- Orchestrated: planned with provision servers etc, has features and configurations transferred etc.
- Consistent: use Git! And MAMP/devdestkop, puppet/chef/ansible/saltstack or acquia/pantheon/platform.sh
- Deterministic: all changes should be reversible!
He noted a number of elements we should aspire to with good deployments such as it being reversible, with examples of how this works with platform.sh.
He also suggested that one problem not addressed is inconsistent local environments with teams working together (few people in the room had environments prescribed from their agency) – though there was at least one comment from the backchannel that this wasn’t necessarily an issue.
Trying to remember once in six years as a Drupal team lead where custom developers' envs caused a serious, unspotted problem #dclondon
— J-P Stacey (@jpstacey) March 1, 2015
While Douglass did a lot of his examples using his product platform.sh, he did provide considerations for people who wanted to roll their own including using such things as docker, ansible (which was mentioned a lot at this camp), cloudfoundry, kalabox, puppet / chef / saltstack.
Header image CC-BY-SA by Amazee Labs.