Dev-Staging-Prod Environment Guidelines Valentin GUIGNON September 2015

Example Implementation Summary Starter For Who? What is it all about? Guidelines Setup Example Implementation

Disclaimer

Starter

? For who? single developer vs. team 0, 1, 2 or more servers any admin control (DNS) people without deployment procedure ?

What is it all about? A time investment that can be profitable We are talking about websites To offer reliable services Reliable means user trust

What is it all about? Ever published a tool not working properly? How long to figure it out? How long to solve the problem? Ever needed to go back in time when some feature was working a certain way? Ever wanted to share improvements but continue developments at the same time? Ever shared a development space?

What is it all about? Still doing live changes?! live changes STOP DOING THIS! Please!

Guidelines

Guidelines Rule #1: Have automated backups development & prod files config files databases daily, weekly, monthly rsync is your friend

Guidelines Rule #2: Use versioning software Subversion (SVN), Mercurial, Git,… what can/should be versioned? use branching when to commit? is it compatible with a live site?

Guidelines Rule #3: Separate dev, staging and prod dev: can be broken staging: not public but stable, for testers prod: always fully functional dev physically separated from staging & prod staging & prod share the same environment

Guidelines Rule #4: Have cheat sheet system admin operations, command lines SQL queries pieces of code access codes did I say “access codes”? …Security!

Guidelines Rule #5: Write procedures transferring dev to staging, staging to prod, etc. rolling back update tools, modules, data …and stick to them!

Guidelines Rule #6: Log what you do use flat text files (with backup), with dates outside the servers, maybe on a shared space config changes file manipulations (mv, chmod,…) admin operations (install, update,…) error messages (c&p) and how solved basically everything you think is relevant don’t forget security (clear password, log access)

Guidelines Rule #7: Have automated tests run them as needed on dev run them before having a staging reviewed run them periodically on prod report by mail/RSS report both errors and success have a smart report management

Guidelines Rule #8: Use things the right way dev: for development staging: to let your reviewers test your work in a stable production environment prod: for live site, no hazardous changes!

Guidelines Rule #9: Use a project manager/bug tracker Redmine, JIRA, Mantis, GForge,… use tracker IDs for your branches/commits have a TODO list follow up on issues

Guidelines Rule #10: Don’t give up!

Setup

Setup – Dev server Dev server can be: your own dev station using a VM a development server shared between projects More than one on a same project? use virtual machines or different directories / host names / DBs /srv/projects/mgis/dev_valentin dev-val.crop-diversity.org tripal_mgis_dev_val /srv/projects/mgis/dev_alexis dev-alexis.crop-diversity.org tripal_mgis_dev_alexis

Setup About DNS: dev.server.com, dev-toto.server.com, staging.server.com, www.server.com,... You don’t need admins! System Administrator Windows: C:\Windows\System32\drivers\etc\hosts Linux: /etc/hosts Mac: /private/etc/hosts

Setup - Staging Share same environment as the prod server: validates production server settings external access for testers live conditions without being live developers have no access to staging file system / DB dev-to-staging should be done by an admin

Setup - Prod Production server: developers have no access to prod file system / DB staging-to-prod should be done by an admin switching old-prod / new-prod = symlink change

Implementation

Example Implementation Context: 4 (virtual) servers: dev: 1 web + 1 DB staging & prod: 1 web + 1 DB Several projects Drupal sites with common core

Example Implementation Dev server setup: www directory + www-writeable directory includes Drupal core (common) project directory includes dev* directories, tools, data, docs,… individual user accounts, project groups, project groups with web ex.: dubois banana banana-www chmod g+s, umask 002

Example Implementation srv ├── www │ └── drupal │ ├── *current  drupal-7.38 │ ├── drupal-7.37 │ ├── drupal-7.38 │ │ ├── *sites  ../sites │ │ … │ └── sites │ ├── *banana.com  /srv/projects/banana/dev/banana.com │ … ├── www-writeable │ └── banana │ ├── dubois │ │ ├── files │ │ └── private_files │ └── dupont ├── projects │ ├── banana │ │   ├── data │ │   ├── *dev  dev_dubois │ │   ├── dev_dubois │ │   │   ├── banana.com │ │   │   │   ├── *files  /srv/www-writeable/banana/dubois/files │ │   │   │   … │ │   │   └── others │ │   ├── dev_dupont │ │   ├── docs │ │   └── tools │ ├── coffee ... ... ... Dev server setup:

Example Implementation Dev server setup: # chown –R root:www /srv/www # chmod –R ug+rX,g-w,o-rwx /srv/www # chown –R www:banana-www /srv/www-writeable/banana # chmod –R ug+rwX,o-rwx /srv/www-writeable/banana # find /srv/www-writeable/banana –type d –exec chmod g+s \{\} \; # chgrp –R banana /srv/projects/banana # chmod –R ug+rwX,o-rwx /srv/projects/banana # find /srv/projects/banana –type d –exec chmod g+s \{\} \;

Example Implementation Staging & prod server setup: www directory + www-writeable directory includes Drupal core (common) project directory staging, prod_XXX, prod_YYY,… no developer or project accounts, only a drupal account with an ssh key file authentication use a key file because the server is exposed to outside and password-login should be forbidden the only way to transfer dev to staging is from dev because staging can not see dev

Example Implementation srv ├── www │ ├── *prod  prod_XXX │ ├── prod_XXX │ ├── prod_YYY │ ... │ └── staging │ └── drupal │ ├── *current  drupal-7.38 │ ... │ └── sites │ ├── banana.com │          │ ├── *files  /srv/www-writeable/banana/staging/files │ ... ... ├── www-writeable │ └── banana │ ├── prod_XXX │ ├── prod_YYY │ ... │ └── staging │ ├── files │ └── private_files ├── projects │ ├── banana │ │   ├── common │ │   ├── prod_XXX │ │   ├── prod_YYY │ │   ... │ │   └── staging │ │      ├── *www  /srv/www/staging/sites/banana.com │ │      ├── tools ... ... ... Prod server setup:

Example Implementation Prod server setup: # useradd –G www drupal # chown –R root:www /srv/www # chown –R drupal:www /srv/www/*/drupal # chmod –R ug+rX,g-w,o-rwx /srv/www # chown –R www:www /srv/www-writeable # chmod –R ug+rwX,o-rwx /srv/www-writeable

Example Implementation Workflows & use cases: dev  staging: when ready to be tested staging  prod: when staging validated prod  staging: when need to update prod prod  dev: when need to work on last data

Example Implementation What happens really? website = config + database + data files + code + tools + … dev side evolves but prod side also evolves! How to update/merge?! patches lock prod

Example Implementation Dev to staging process: prod data  staging (config changes  staging) dev code  staging dev additional data  staging automated tests on staging testers can test

Example Implementation Staging to prod process: lock prod dev to staging process automated tests on staging clone staging to prod_YYY prod symlink  prod_YYY automated tests on prod; if not ok, prod symlink  prod_XXX

Some little details how to tell if dev / staging / prod? database containing hardcoded serialized values files with absolute references (databases, path,…) optimizations & prod-only stuff (analytics, mails,…) shared core / modules (version issues) specificities (external tools, indexed data,…)

To Conclude

Conclusion quality approach to provide reliable tools simple in theory, complex in practice… but feasible time investment rewarding only really rewards if complete

THANK YOU/FINAL SLIDE

SearchReplaceDB script root-like chmod ssh key authentication