DevOpsDownUnder – Day 2 – John Ferlio

John Ferlio – Commit Early, Deploy Often

Flickr claim to deploy multiple times per day, not for everybody

Various ways to deploy, tarballs, versions control, packages

Usaing Package management to deploy

  • Treat internal apps same as external apps
  • Works with config management
  • Use CM and VMs to give devs a sample of production on their laptop
  • Devs can then develop directly to what prod looks like

Example for Deploy for Ruby Apps

  • Use bundle to setup ruby dependencies for app
  • Simple makefile to install install bundle and run it. Bundle installs apps and then compiles them. Then files put in right dirs (prod and stating versions)
  • dh_make to create base deb env
  • delete unwanted extra debian template files.
  • create staging and a production package, basic fill in of debian control files to buuild packages
  • Package contains whole website and files. Maybe 200MB. More advanced users might want to split some stuff off.
  • He has little bit to put the bzr revision in a file in the package for later reference.

Lauchpad PPAs – lets you build your source for various debian distributions/archetectires. He Blogged about a simplier system he created (you can host locally) this a month or two back.

Use to deploy rubu-on-rails and WordPress apps.

  • Don’t have to compile things on box, don’t have to install gems, don’t have to svn update.
  • Maybe use pre-init script to stop app server during the upgrade nd restart afterwards
  • Some talk about how to sync deployment of updated app and new database schema that it requires. Thoughts seem to be that new app version should be able to handle the old schema during the transition.
  • Rails libararies evolve so fast which is why libraries need to be bundled. Other languages can sometimes use OS provided libraries