1. Understanding and designing web
application deployment for small
teams.
Lee Hambley
lee.hambley@gmail.com
github.com/leehambley
twitter.com/codebeaker
Sunday, October 16, 11

2. WHY DO WE DEPLOY?
Sunday, October 16, 11

3. WHY DO WE DEPLOY?
• Fundamentally, because we’ve done
some work, and we want to share it
Sunday, October 16, 11

4. WHY DO WE DEPLOY?
• Fundamentally, because we’ve done
some work, and we want to share it
• firstly with stakeholders, second with
users
Sunday, October 16, 11

5. WHY DO WE DEPLOY?
• Fundamentally, because we’ve done
some work, and we want to share it
• firstly with stakeholders, second with
users
• because we’ve fixed bugs and need to
make the improved code available
Sunday, October 16, 11

6. WHY DO WE DEPLOY?
• Fundamentally, because we’ve done
some work, and we want to share it
• firstly with stakeholders, second with
users
• because we’ve fixed bugs and need to
make the improved code available
• because the business interest needs
new features
Sunday, October 16, 11

7. WHY DO WE DEPLOY?
• Fundamentally, because we’ve done
some work, and we want to share it
• firstly with stakeholders, second with
users
• because we’ve fixed bugs and need to
make the improved code available
• because the business interest needs
new features
• because we need to test something
privately in a production-like
environment
Sunday, October 16, 11

8. WHY DO WE DEPLOY?
• Fundamentally, because we’ve done • because we’re professionals
some work, and we want to share it
• firstly with stakeholders, second with
users
• because we’ve fixed bugs and need to
make the improved code available
• because the business interest needs
new features
• because we need to test something
privately in a production-like
environment
Sunday, October 16, 11

9. WHY DO WE DEPLOY?
• Fundamentally, because we’ve done • because we’re professionals
some work, and we want to share it
• because interpreters like to load files into memory
for performance (& other good reasons)
• firstly with stakeholders, second with
users
• because we’ve fixed bugs and need to
make the improved code available
• because the business interest needs
new features
• because we need to test something
privately in a production-like
environment
Sunday, October 16, 11

10. WHY DO WE DEPLOY?
• Fundamentally, because we’ve done • because we’re professionals
some work, and we want to share it
• because interpreters like to load files into memory
for performance (& other good reasons)
• firstly with stakeholders, second with
users
• because we like to think about software in “versions”
• because we’ve fixed bugs and need to
make the improved code available
• because the business interest needs
new features
• because we need to test something
privately in a production-like
environment
Sunday, October 16, 11

11. WHY DO WE DEPLOY?
• Fundamentally, because we’ve done • because we’re professionals
some work, and we want to share it
• because interpreters like to load files into memory
for performance (& other good reasons)
• firstly with stakeholders, second with
users
• because we like to think about software in “versions”
• because we’ve fixed bugs and need to • because we prefer to be available to our customers
make the improved code available
• because the business interest needs
new features
• because we need to test something
privately in a production-like
environment
Sunday, October 16, 11

12. WHY DO WE DEPLOY?
• Fundamentally, because we’ve done • because we’re professionals
some work, and we want to share it
• because interpreters like to load files into memory
for performance (& other good reasons)
• firstly with stakeholders, second with
users
• because we like to think about software in “versions”
• because we’ve fixed bugs and need to • because we prefer to be available to our customers
make the improved code available
• because we prefer to be accountable to the business
people
• because the business interest needs
new features
• because we need to test something
privately in a production-like
environment
Sunday, October 16, 11

13. WHY DO WE DEPLOY?
• Fundamentally, because we’ve done • because we’re professionals
some work, and we want to share it
• because interpreters like to load files into memory
for performance (& other good reasons)
• firstly with stakeholders, second with
users
• because we like to think about software in “versions”
• because we’ve fixed bugs and need to • because we prefer to be available to our customers
make the improved code available
• because we prefer to be accountable to the business
people
• because the business interest needs
new features
• because we have things like migrations, seed tasks,
background workers and all the rest
• because we need to test something
privately in a production-like
environment
Sunday, October 16, 11

14. WHY DO WE DEPLOY?
• Fundamentally, because we’ve done • because we’re professionals
some work, and we want to share it
• because interpreters like to load files into memory
for performance (& other good reasons)
• firstly with stakeholders, second with
users
• because we like to think about software in “versions”
• because we’ve fixed bugs and need to • because we prefer to be available to our customers
make the improved code available
• because we prefer to be accountable to the business
people
• because the business interest needs
new features
• because we have things like migrations, seed tasks,
background workers and all the rest
• because we need to test something
privately in a production-like • because there’s usually more than one machine
environment
Sunday, October 16, 11

15. WHY DO WE DEPLOY?
• Fundamentally, because we’ve done • because we’re professionals
some work, and we want to share it
• because interpreters like to load files into memory
for performance (& other good reasons)
• firstly with stakeholders, second with
users
• because we like to think about software in “versions”
• because we’ve fixed bugs and need to • because we prefer to be available to our customers
make the improved code available
• because we prefer to be accountable to the business
people
• because the business interest needs
new features
• because we have things like migrations, seed tasks,
background workers and all the rest
• because we need to test something
privately in a production-like • because there’s usually more than one machine
environment
• because very often there’s more than one moving
piece has changed. (code & database, code &
configuration, etc)
Sunday, October 16, 11

16. WHAT SHOULD WE DEPLOY?
• How do we decide if a project really needs deployment?
• How do we decide what to deploy?
• Where does infrastructure end, and the application begin?
• How can the what change depending on the application?
• What don’t we deploy?
• Uploaded assets, the database, the system packages, the Ruby Gems, your own log files.
Sunday, October 16, 11

17. INFRASTRUCTURE VS. APPLICATION
operating system
rubygems.org
SSL Certificates
github.com
SSH keys
logrotate configuration
nginx virtual hosts configuration
scheduled jobs application code
log files
cache configuration
database configuration
Infrastructure Application
Sunday, October 16, 11

18. BENCHMARK
gadget-showdown.co.uk
Comparing the latest gadgets in ultimate-
fighting style reviews, ending with a “Will it
blend?” teardown. Request your own review of
any two devices, and we’ll get right on it!
• User registration
• User comments
• Requests
• RSS feed
• Notifications
• Daily posts
• Non-technical writing team
Sunday, October 16, 11

19. BENCHMARK
gadget-showdown.co.uk
Comparing the latest gadgets in ultimate-
fighting style reviews, ending with a “Will it
blend?” teardown. Request your own review of
any two devices, and we’ll get right on it!
• User registration
PostgreSQL
• User comments
• Requests
• RSS feed
• Notifications
Memcache
• Daily posts
• Non-technical writing team
Sunday, October 16, 11

20. BENCHMARK
gadget-showdown.co.uk
Comparing the latest gadgets in ultimate-
fighting style reviews, ending with a “Will it
blend?” teardown. Request your own review of
any two devices, and we’ll get right on it!
• User registration
PostgreSQL
• User comments
• Requests
• RSS feed
• Notifications
Memcache
• Daily posts
• Non-technical writing team
Sunday, October 16, 11

21. BENCHMARK
gadget-showdown.co.uk
Comparing the latest gadgets in ultimate-
fighting style reviews, ending with a “Will it
blend?” teardown. Request your own review of
any two devices, and we’ll get right on it!
• User registration
PostgreSQL
• User comments
• Requests
• RSS feed
• Notifications
Memcache
• Daily posts
• Non-technical writing team
MRI v1.8.7
Sunday, October 16, 11

22. BENCHMARK
gadget-showdown.co.uk
Comparing the latest gadgets in ultimate-
fighting style reviews, ending with a “Will it
blend?” teardown. Request your own review of
any two devices, and we’ll get right on it!
• User registration
PostgreSQL
• User comments
• Requests
• RSS feed
• Notifications
Memcache
• Daily posts
• Non-technical writing team
MRI v1.8.7
Unicorn
Sunday, October 16, 11

23. BENCHMARK
gadget-showdown.co.uk
Comparing the latest gadgets in ultimate-
fighting style reviews, ending with a “Will it
blend?” teardown. Request your own review of
any two devices, and we’ll get right on it!
• User registration
PostgreSQL
• User comments
• Requests
• RSS feed
• Notifications
Memcache
• Daily posts
• Non-technical writing team
MRI v1.8.7
Unicorn
Sunday, October 16, 11

24. WHO?
Our hypothetical, inexperienced team.
Unlike us, they are not misunderstood masters of the forbidden
and subtle arts. They’re not Jedi top-gun warlocks, like we are
either, they’re just regular job people, and they’re never going to
win a Nobel prize for their deployment efforts, and further
more, they probably don’t even care.
Sunday, October 16, 11

25. WHO?
Our hypothetical, inexperienced team.
Unlike us, they are not misunderstood masters of the forbidden
and subtle arts. They’re not Jedi top-gun warlocks, like we are
either, they’re just regular job people, and they’re never going to
win a Nobel prize for their deployment efforts, and further
more, they probably don’t even care.
Sunday, October 16, 11

26. WHO?
Our hypothetical, inexperienced team.
Unlike us, they are not misunderstood masters of the forbidden
and subtle arts. They’re not Jedi top-gun warlocks, like we are
either, they’re just regular job people, and they’re never going to
win a Nobel prize for their deployment efforts, and further
more, they probably don’t even care.
• Three person development team
• No dedicated “ops”
• No deployment experience
• No Unix experience
Sunday, October 16, 11

27. WHO?
Our hypothetical, inexperienced team.
Unlike us, they are not misunderstood masters of the forbidden
and subtle arts. They’re not Jedi top-gun warlocks, like we are
either, they’re just regular job people, and they’re never going to
win a Nobel prize for their deployment efforts, and further
more, they probably don’t even care.
• Three person development team
• No dedicated “ops”
• No deployment experience
• No Unix experience
• They want fast, reliable deployments
• They don’t want phone calls at 3am because the
servers are choking
• They don’t want to have to learn about unix to do
their job
• They want it to be impossible to break something
accidentally
• They don’t want to have to deal with passwords
• They expect things to “Just Work” because they’re
hipster macbook using nancy boys.
Sunday, October 16, 11

28. WHERE DO WE DEPLOY?
✝ That’s not a condonation, just an observation
Sunday, October 16, 11

29. WHERE DO WE DEPLOY?
• Almost certainly to VPS
✝ That’s not a condonation, just an observation
Sunday, October 16, 11

30. WHERE DO WE DEPLOY?
• Almost certainly to VPS
• Almost certainly, not to EC2
(that is, at least not in a way that makes the most of
the elastic infrastructure)
✝ That’s not a condonation, just an observation
Sunday, October 16, 11

31. WHERE DO WE DEPLOY?
• Almost certainly to VPS
• Almost certainly, not to EC2
(that is, at least not in a way that makes the most of
the elastic infrastructure)
• Almost certainly to Ubuntu ✝
(because it has a convenient package manager)
✝ That’s not a condonation, just an observation
Sunday, October 16, 11

32. WHERE DO WE DEPLOY?
• Almost certainly to VPS
• Almost certainly, not to EC2
(that is, at least not in a way that makes the most of
the elastic infrastructure)
• Almost certainly to Ubuntu ✝
(because it has a convenient package manager)
• Probably to a VPS provider
in the USA
✝ That’s not a condonation, just an observation
Sunday, October 16, 11

33. WHERE DO WE DEPLOY?
• Almost certainly to VPS • Probablyto a 32 bit
operating system
• Almost certainly, not to EC2
(that is, at least not in a way that makes the most of
the elastic infrastructure)
• Almost certainly to Ubuntu ✝
(because it has a convenient package manager)
• Probably to a VPS provider
in the USA
✝ That’s not a condonation, just an observation
Sunday, October 16, 11

34. WHERE DO WE DEPLOY?
• Almost certainly to VPS • Probablyto a 32 bit
operating system
• Almost certainly, not to EC2
(that is, at least not in a way that makes the most of
the elastic infrastructure) • Probably to more than one
machine
• Almost certainly to Ubuntu ✝
(because it has a convenient package manager)
• Probably to a VPS provider
in the USA
✝ That’s not a condonation, just an observation
Sunday, October 16, 11

35. WHERE DO WE DEPLOY?
• Almost certainly to VPS • Probablyto a 32 bit
operating system
• Almost certainly, not to EC2
(that is, at least not in a way that makes the most of
the elastic infrastructure) • Probably to more than one
machine
• Almost certainly to Ubuntu ✝
(because it has a convenient package manager)
• Probably
using something
• Probably
from AWS, because it’s hip
to a VPS provider
in the USA
✝ That’s not a condonation, just an observation
Sunday, October 16, 11

36. WHERE DO WE DEPLOY?
• Almost certainly to VPS • Probablyto a 32 bit
operating system
• Almost certainly, not to EC2
(that is, at least not in a way that makes the most of
the elastic infrastructure) • Probably to more than one
machine
• Almost certainly to Ubuntu ✝
(because it has a convenient package manager)
• Probably
using something
• Probably
from AWS, because it’s hip
to a VPS provider
in the USA • Probably not using a CDN
✝ That’s not a condonation, just an observation
Sunday, October 16, 11

37. A SHORTLIST OF REQUIREMENTS FOR A SANE
DEPLOYMENT
Speedy
Secure
Accessible
Transactional
Accountable
Parallell
Hookable
Sunday, October 16, 11

38. A SHORTLIST OF REQUIREMENTS FOR A SANE
DEPLOYMENT
Speedy
Secure
Accessible
Transactional
Accountable
Parallel
Hookable
Sunday, October 16, 11

39. A SHORTLIST OF REQUIREMENTS FOR A SANE
DEPLOYMENT
Speedy •Fast starting
•Fail fast
Secure •Using a fast protocol (SSH, with keys)
•Not wasting bandwidth or capacity
Accessible •Not relying on passwords
Transactional
Accountable
Parallel
Hookable
Sunday, October 16, 11

40. A SHORTLIST OF REQUIREMENTS FOR A SANE
DEPLOYMENT
Speedy •Using a secure protocol
•Using a secure, trustworthy source
Secure •Secure from workstation to server
•Secure deployment result by design
Accessible •No shared sign-ons
Transactional •Robust
Accountable •Resilient
Parallel •No .rc~ files
Hookable
Sunday, October 16, 11

41. A SHORTLIST OF REQUIREMENTS FOR A SANE
DEPLOYMENT
Speedy •Any member of the dev’ team can deploy
•They can do it without using root (or other) passwords
Secure •Secure from workstation to server
•Secure deployment result by design
Accessible
Transactional
Accountable
Parallel
Hookable
Sunday, October 16, 11

42. A SHORTLIST OF REQUIREMENTS FOR A SANE
DEPLOYMENT
Speedy •When a deploy fails on one machine, we fail it across the board
•We know when a deploy starts, is in progress, and ends
Secure •We can inform our customers that there’s a deploy in progress,
without falling back to a maintenance page.
Accessible •We can recover from errors.
Transactional
Accountable
Parallel
Hookable
Sunday, October 16, 11

43. A SHORTLIST OF REQUIREMENTS FOR A SANE
DEPLOYMENT
Speedy •We know who deployed what, and when
•We know exactly what happened during the deployment
Secure •We know which version of the code is in production
Accessible •We know how many servers are online
Transactional
Accountable
Parallel
Hookable
Sunday, October 16, 11

44. A SHORTLIST OF REQUIREMENTS FOR A SANE
DEPLOYMENT
Speedy •We need to operate on our machines in parallel
•Except when we don’t
Secure •Sequential parallel deployment
Accessible
Transactional
Accountable
Parallel
Hookable
Sunday, October 16, 11

45. A SHORTLIST OF REQUIREMENTS FOR A SANE
DEPLOYMENT
Speedy •We need to know how it worked out
•We often need to share that information
Secure •with business people
•with automated systems (issue tracker, status board, monitoring)
Accessible
Transactional
Accountable
Parallel
Hookable
Sunday, October 16, 11

46. THAT’S A LONG LIST
Sunday, October 16, 11

47. AND NOBODY DOES
EVERYTHING
Sunday, October 16, 11

48. SO WHERE DO WE BEGIN?
Sunday, October 16, 11

49. $ CAP PRODUCTION DEPLOY
Sunday, October 16, 11

50. # > touch /tmp/some-file
$ > touch /tmp/some-file
Sunday, October 16, 11

51. $ > su someotheruser
$ > su - someotheruser
Sunday, October 16, 11

52. The Dreyfus Model
Sunday, October 16, 11

53. UNIX 101
Sunday, October 16, 11

54. USERS AND GROUPS
Sunday, October 16, 11

55. $ CAP PRODUCTION PERMISSIONS:FIX
Sunday, October 16, 11

56. $ CAP PRODUCTION PERMISSIONS:FIX
desc “fix permissions”
task :fix, :roles => [:web, :app] do
run “chown nobody:apache /var/www/otb/“
run “chmod -R 666 #{current_release}”
run “chmod -R 777 #{current_release}/
bin/”
end
Sunday, October 16, 11

57. Sunday, October 16, 11

58. $ whoami
Sunday, October 16, 11

59. $ whoami
codebeaker
Sunday, October 16, 11

60. $ whoami
codebeaker
$ groups
Sunday, October 16, 11

61. $ whoami
codebeaker
$ groups
codebeaker staff deploy sudo
Sunday, October 16, 11

62. $ whoami
codebeaker
$ groups
codebeaker staff deploy sudo
$ echo $PATH
Sunday, October 16, 11

63. $ whoami
codebeaker
$ groups
codebeaker staff deploy sudo
$ echo $PATH
/usr/bin:/bin:/usr/sbin
Sunday, October 16, 11

64. Sunday, October 16, 11

65. $ id
Sunday, October 16, 11

66. $ id
uid=501(codebeaker) gid=20(staff)
groups=20(staff)12(everyone),
33(_appstore),80(admin),
204(_developer)
Sunday, October 16, 11

67. Sunday, October 16, 11

68. $ id
Sunday, October 16, 11

69. $ id
uid=1000(codebeaker)
gid=1000(codebeaker)
groups=60(staff)90(deploy),50(sudo)
Sunday, October 16, 11

70. $ id
uid=1000(codebeaker)
gid=1000(codebeaker)
groups=60(staff)90(deploy),50(sudo)
$ touch example
Sunday, October 16, 11

71. $ id
uid=1000(codebeaker)
gid=1000(codebeaker)
groups=60(staff)90(deploy),50(sudo)
$ touch example
$ newgrp -l deploy
Sunday, October 16, 11

72. I/O
Sunday, October 16, 11

73. PROCESSES
Sunday, October 16, 11

74. PERMISSIONS
Sunday, October 16, 11

75. 37SIGNALS
Sunday, October 16, 11

76. SHELLS, LOGIN AND NON-LOGIN
Sunday, October 16, 11

77. ENVIRONMENTAL VARIABLES
Sunday, October 16, 11

78. SSH
Sunday, October 16, 11

79. SOURCES OF TRUTH
Sunday, October 16, 11

80. DISTRIBUTION OF
RESOURCES
Sunday, October 16, 11

81. HOW?
There isn’t any software on the planet for doing this correctly.
Sunday, October 16, 11

82. HELP ME WRITE IT…
Sunday, October 16, 11

83. I’M @CODEBEAKER
Thanks for your time and attention, any questions?
Sunday, October 16, 11