Joe Ferguson discusses his experiences and insights on DevOps specifically for small teams, emphasizing the importance of version control, testing, and continuous integration. He advocates for using tools like Vagrant to standardize development environments and stresses abandoning outdated practices like FTP access. The document outlines practical tips for scaling teams and optimizing workflows, while highlighting the significance of automation and feedback in development processes.

1. DevOps For Small Teams
Joe Ferguson
https://joind.in/16020

2. Who Am I?
Joe Ferguson
PHP Developer
Twitter: @JoePFerguson
Organizer of @MemphisPHP
@NomadPHP Lightning Talks
Passionate about Community

3. My first “dev” job
Hired to convert PSDs to HTML

4. My first “dev” job
Hired to convert PSDs to HTML
Ended up building / hacking at web
apps

5. My first “dev” job
Hired to convert PSDs to HTML
Ended up building / hacking at web apps
We had no DevOps (was it even a thing then?)

6. My first “dev” job
Hired to convert PSDs to HTML
Ended up building / hacking at web apps
We had no DevOps (was it even a thing then?)
We invested in metal

7. My first “dev” job
Hired to convert PSDs to HTML
Ended up building / hacking at web apps
We had no DevOps (was it even a thing then?)
We invested in metal
Just started using “the cloud”

8. My second dev job
Yay I'm not alone!

9. My second dev job
Yay I'm not alone!
I was still "the server person"

10. Yay I'm not alone!
I was still "the server person”
Scaling a team
We needed to scale up (and skill
up) our team
My second dev job

11. Scaling a team
Version control is NOT renaming files
Version control EVERYTHING

12. Teaching our team VCS
https://try.github.io

13. Teaching our team VCS
https://guides.github.com

14. Trial & Error is ok!

15. Scaling a team
Stop Editing In
Production!

16. No more edit
& uploading!
Everything
goes into
version control!

17. Disable FTP Access*!
# echo troy >> /etc/ftpuser
# echo andy >> /etc/ftpuser
# echo joe >> /etc/ftpuser
Better yet, disable FTP completely*

18. *If you can

19. Scaling a team
Development environments

20. MAMP, LAMP, WAMP, WAT?
Mac/Linux/Windows Apache MySQL PHP
These are all great tools

21. Do you deploy to
MAMP/WAMP?

22. Why develop on a
different configuration?

23. Catch those environment
bugs earlier

24. Remove the phrase
“…It works on my machine…”
From your team

25. Stop using WAMP/MAMP
and start using Vagrant!

26. Vagrant allows you to:
• Create a server
• Configure a server
• Delete a server
…over and over and over..

27. Not sure how to create a
Vagrant box?

28. PuPHPet.com

29. Guided path to create your own Vagrant
Supports common Distributions
Customize users, firewall rules, cron jobs
Add databases, virtual hosts
Supports Ruby, PHP, Python, NodeJS,
HHVM
Beanstalkd & RabbitMQ
Elastic Search & Apache Solr
PuPHPet.com

30. PuPHPet.com
Great for learning HOW to build boxes
Especially useful if you’d like to learn
Puppet

31. Other Provisioners
Shell
Chef - use existing Cookbooks
Docker - used if your app is in Docker
SaltStack

32. Vagrant Cookbook
https://leanpub.com/vagrantcookbook

33. Ansible for DevOps
https://leanpub.com/ansible-for-devops

34. Learning Budget

35. Learning Budget

36. Scaling a team
Test your code!
Testing was the hardest part for us.
The payoffs in catching regression bugs
and confidence in our deployments was
well worth it

37. Is your code testable?
If unit testing is hard, your code may not
have been written to be testable.

38. Testing Resources
http://grumpy-learning.com

39. Testing Resources
https://laracasts.com/collections/testing-in-php

40. Continuous Integration
Continuous Delivery

41. Continuous Integration
Frequently integrate code changes into the
existing code repository
Merging branches to master/production
Automated build tests to ensure issues found
quickly
Does not have to be deployed

42. Continuous Delivery
Produce valuable changes in code in short
cycles to be released at any time.
AKA: Continuous Deployment
Automated build tests to ensure issues
found quickly
Deployment happens on successful build

43. Which is right for you?
Your goal should be Continuous
Integration (at least!)
Strive for Continuous Delivery if it makes
sense
Applications with a live event component
may not be suited for Continuous
Delivery

44. There are a lot of CI
solutions out there

45. ServersForHackers.com

46. What is your process?

47. Create your workflow

48. Optimize your time
in the console

49. Work smarter not harder

50. Stop typing the same
commands
git status
git pull origin master
git branch —set-upstream-to=origin/master
vagrant global-status | grep running
redis-server /usr/local/etc/redis.conf
php -S localhost:8000
ssh svpernova@joeferguson.me -t screen -dR irc
gs
gpm
gsu
vgr
startredis
startphp
irc

51. Make use of aliases
alias gs=“git status”
alias gpm=“git pull origin master”
alias gsu=“git branch —set-upstream-to=origin/master”
alias vgr=“vagrant global-status | grep running”
alias startredis=“redis-server /usr/local/etc/redis.conf”
alias startphp=“php -S localhost:8000”
alias irc=“ssh svpernova@joeferguson.me -t screen -dR irc"

52. Use Screen for long
running processes
https://www.mattcutts.com/blog/a-quick-tutorial-on-screen/

53. Think of screen as a
detachable window that
contains your console

54. Screen Demo

55. Want more Power?
https://tmux.github.io

56. Bash isn’t the only shell!

57. http://ohmyz.sh
Uses zsh
180+ Plugins
700+ Contributors
140+ Themes

58. myZsh

59. Why do I use myzsh
over oh-my-zsh?

60. Why do I use myzsh
over oh-my-zsh?

61. Customize your shell
• Local IPs
• Date
Green Text
because this is
the local machine
• User
• Hostname
• Current Path
• Current time

62. Customize your shell
• User
• Hostname
• Current Path
• Current time
• Local IPs
• Date
Red Text
because this is
a remote machine

63. Customize your shell
Tab completion on steroids
+ Git branch info because we are in a repo

64. Tab Completion Demo

65. .zshrc

66. Automate Common Tasks
Alias long commands
Shell script sequential commands
Use cron to run your scripts at specific times
Create installers for your settings

67. Version Control Configs

68. Do NOT version control
your SSH keys!

69. Do NOT version control
your API keys!

70. Recap
Version Control everything you can
Create a process that works for your team
Practice how you play
Test everything you can
Automate everything you can

71. Feedback!
https://joind.in/16020
Joe Ferguson
Twitter: @JoePFerguson
Email: joe@joeferguson.me
Freenode: joepferguson
Contact Info: