Downloaded 29 times
Uploaded byJoe Ferguson
DevOps For Small Teams
The document discusses the evolution of DevOps practices for small development teams, highlighting the importance of version control, development environments, and continuous integration and delivery. It emphasizes using tools like Vagrant for environment management, testing code to catch bugs early, and automating workflows to streamline processes. The author also shares personal experiences and resources to help teams adopt these practices effectively.
More Related Content
![php[world] 2015 Laravel 5.1: From Homestead to the Cloud](https://cdn.slidesharecdn.com/ss_thumbnails/phpworld-2015-laravelhomestead-4x3-151118212002-lva1-app6891-thumbnail.jpg?width=640&height=640&fit=bounds)
![php[world] 2015 Training - Laravel from the Ground Up](https://cdn.slidesharecdn.com/ss_thumbnails/phpworld-2015-training-151117190847-lva1-app6892-thumbnail.jpg?width=640&height=640&fit=bounds)
DevOps For Small Teams
- 1. DevOps For SmallTeams Joe Ferguson https://joind.in/13966
- 2. My first “dev”job Hired to convert PSDs to HTML
- 3. My first “dev”job Hired to convert PSDs to Ended up building / hacking at web apps
- 4. My first “dev”job Hired to convert PSDs to Ended up building / hacking at web apps We had no DevOps (was it even a thing then?)
- 5. My first “dev”job Hired to convert PSDs to Ended up building / hacking at web apps We had no DevOps (was it even a thing then?) We invested in metal
- 6. My first “dev”job Hired to convert PSDs to 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”
- 7. My second devjob Yay I'm not alone!
- 8. My second devjob Yay I'm not alone! I was still "the server person"
- 9. Yay I'm notalone! I was still "the server person” Scaling a team We needed to scale up (and skill up) our team My second dev job
- 10. Scaling a team Versioncontrol is NOT renaming files Version control EVERYTHING
- 11. Teaching our teamVCS https://try.github.io
- 12. Teaching our teamVCS https://guides.github.com
- 13. Trial & Erroris ok!
- 14. Scaling a team StopEditing In Production!
- 15. No more edit &uploading! Everything goes into version control!
- 16. Disable FTP Access! #echo troy >> /etc/ftpuser # echo andy >> /etc/ftpuser # echo joe >> /etc/ftpuser Better yet, disable FTP completely
- 17. Scaling a team Developmentenvironments
- 18. MAMP, LAMP, WAMP, WAT? Mac/Linux/WindowsApache MySQL PHP These are all great tools
- 19. Do you deployto MAMP/WAMP?
- 20. They why devon it?
- 21. Catch those envbugs earlier
- 22. Remove the phrase “…Itworks on my machine…” From your team
- 23. Stop using WAMP/MAMP andstart using Vagrant!
- 24. Vagrant allows youto: • Create a server • Configure a server • Delete a server …over and over and over..
- 25. Not sure howto create a Vagrant box?
- 26.
- 27. https://puphpet.com Guided path tocreate 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
- 28.
- 29. Scaling a team Testyour code! Testing was the hardest part for us. The payoffs in catching regression bugs and confidence in our deployments was well worth it
- 30.
- 31.
- 32. Continuous Integration Frequently integratecode 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
- 33. Continuous Delivery Produce valuablechanges 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
- 34. Which is rightfor 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
- 35. There are alot of CI solutions out there
- 36.
- 37. What is yourprocess?
- 38.
- 39. Optimize your timein the console
- 40. Work smarter notharder
- 41. Stop typing thesame 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
- 42. Make use ofaliases 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"
- 43. Use Screen forlong running processes
- 44. Think of screenas a detachable window that contains your console
- 45. Bash isn’t theonly shell!
- 46. http://ohmyz.sh Uses zsh 180+ Plugins 700+Contributors 140+ Themes
- 47. Customize your shell •Local IPs • Date • Current time Green Text because this is the local machine • User • Hostname • Current Path • Current time
- 48. Customize your shell •User • Hostname • Current Path • Current time • Local IPs • Date • Current time Red Text because this is a remote machine
- 49. Customize your shell Tabcompletion on steroids + Git branch info because we are in a repo
- 50.
- 51. Automate Common Tasks Alias longcommands Shell script sequential commands Use cron to run your scripts at specific times Create installers for your settings
- 52.
- 53. Do NOT versioncontrol your SSH keys!
- 54. Recap Version Control everythingyou can Create a process that works for you Practice how you play Test everything you can Automate everything you can
- 55. Feedback! https://joind.in/13966 Joe Ferguson Twitter: @JoePFerguson Email:joe@joeferguson.me Freenode: joepferguson Contact Info: