$30 off During Our Annual Pro Sale. View Details »

DevOps for Small Teams WavePHP 2018

Joe Ferguson
September 21, 2018

DevOps for Small Teams WavePHP 2018

DevOps is a large part of a company of any size. In the 9+ years that I have been a professional developer I have always taken an interest in DevOps and have been the "server person" for most of the teams I have been a part of. I would like to teach others how easy it is to implement modern tools to make their everyday development and development processes better. I will cover a range of topics from "Stop using WAMP/MAMP and start using Vagrant", "version control isn't renaming files", "Automate common tasks with shell scripts / command line PHP apps" and "From Vagrant to Production".

Joe Ferguson

September 21, 2018
Tweet

More Decks by Joe Ferguson

Other Decks in Technology

Transcript

  1. DevOps For Small Teams
    Joe Ferguson

    View Slide

  2. Who Am I?
    Joe Ferguson
    PHP Developer
    PHP Architect @ Ministry Brands
    Twitter: @JoePFerguson
    OSMI Board Member
    Drone Racing Pilot

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

  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”

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  14. Teaching our team VCS
    https://gettinggit.com/

    View Slide

  15. Teaching our team VCS
    https://leanpub.com/gitworkbook

    View Slide

  16. Trial & Error is ok!

    View Slide

  17. Scaling a team
    Stop Editing In
    Production!

    View Slide

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

    View Slide

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

    View Slide

  20. *If you can

    View Slide

  21. Scaling a team
    Development environments

    View Slide

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

    View Slide

  23. Do you deploy to
    MAMP/WAMP?

    View Slide

  24. Why develop on a
    different configuration?

    View Slide

  25. Catch those environment
    bugs earlier

    View Slide

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

    View Slide

  27. Or learn the phrase
    “We’re putting your
    machine into production”

    View Slide

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

    View Slide

  29. Virtualbox
    VMware Fusion & Desktop
    Parallels Desktop
    Virtual Machine Providers
    Hyper-V

    View Slide

  30. API Magic

    View Slide

  31. Runs Anywhere (almost)

    View Slide

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

    View Slide

  33. What’s a box?

    View Slide

  34. Not sure how to create a
    Vagrant box?

    View Slide

  35. View Slide

  36. View Slide

  37. What’s in Homestead
    •Ubuntu 18.04
    •PHP 5.6->7.2
    •Nginx
    •MySQL
    •MariaDB
    •Sqlite3
    •Postgres
    •Composer
    •Yarn
    •NodeJS
    •Bower
    •Grunt
    •Gulp
    •Beanstalkd
    •Memcached
    •Redis

    View Slide

  38. What if Homestead doesn’t
    fit your application?

    View Slide

  39. PuPHPet.com

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  45. Vagrant is so 2013!
    CONTAINERS!

    View Slide

  46. Source: docker.com/what-docker
    Virtual Machines Containers

    View Slide

  47. Docker For Developers
    https://leanpub.com/dockerfordevs

    View Slide

  48. Learning Budget

    View Slide

  49. Learning Budget

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  53. Testing Resources
    https://laracasts.com/skills/testing

    View Slide

  54. Continuous Integration
    Continuous Delivery

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  58. ServersForHackers.com

    View Slide

  59. There are a lot of CI
    solutions out there

    View Slide

  60. Getting CI Working
    https://twitter.com/sebdedeyne/status/842011393364791296

    View Slide

  61. What is your process?

    View Slide

  62. Create your workflow

    View Slide

  63. Optimize your time
    in the console

    View Slide

  64. Work smarter not harder

    View Slide

  65. 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 [email protected] -t screen -dR irc
    gs
    gpm
    gsu
    vgr
    startredis
    startphp
    irc

    View Slide

  66. 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 [email protected] -t screen -dR irc"

    View Slide

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

    View Slide

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

    View Slide

  69. Screen Demo

    View Slide

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

    View Slide

  71. Bash isn’t the only shell!

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  76. Tab Completion Demo

    View Slide

  77. .zshrc

    View Slide

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

    View Slide

  79. Version Control Configs

    View Slide

  80. Do NOT version control
    your SSH keys!

    View Slide

  81. Do NOT version control
    your API keys!

    View Slide

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

    View Slide

  83. Feedback!
    https://joind.in/talk/68798
    Joe Ferguson
    Twitter: @JoePFerguson
    Email: [email protected]
    Freenode: joepferguson
    Contact Info:

    View Slide