1. Dev-Staging-Prod Environment Guidelines
Valentin GUIGNON
September 2015

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

3. Disclaimer

4. Starter

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

6. 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

7. 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?

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

9. Guidelines

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

11. 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?

12. 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

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

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

15. 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)

16. 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

17. 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!

18. 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

19. Guidelines
Rule #10: Don’t give up!

20. Setup

21. 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

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

23. 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

24. 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

25. Implementation

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

27. 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

28. Example Implementation
srv ├── www │ └── drupal │ ├── *current  drupal │ ├── drupal │ ├── drupal │ │ ├── *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:

29. 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 \{\} \;

30. 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

31. Example Implementation
srv ├── www │ ├── *prod  prod_XXX │ ├── prod_XXX │ ├── prod_YYY │ │ └── staging │ └── drupal │ ├── *current  drupal │ │ └── 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:

32. 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

33. 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

34. 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

35. 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

36. 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

37. 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,…)

38. To Conclude

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

40. THANK YOU/FINAL SLIDE

41. SearchReplaceDB
script root-like chmod
ssh key authentication