Zero to hero - Geoff Webb
Upcoming SlideShare
Loading in...5
×
 

Zero to hero - Geoff Webb

on

  • 490 views

 

Statistics

Views

Total Views
490
Views on SlideShare
490
Embed Views
0

Actions

Likes
0
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Zero to hero - Geoff Webb Zero to hero - Geoff Webb Presentation Transcript

  • Zero to Hero Pragmatic steps on the path to continuous delivery @geoffnettaglich
  • Continuous Delivery : Theory ed at build / deploy / feedback 10 20 30 40 50 60 a om ut have idea implement idea measure effectiveness refine idea GOTO 10 PROFIT
  • Continuous Delivery : Reality ● Everyone is doing it (apparently) ○ Amazon, Etsy, Facebook, Netflix ■ N deploys per day / min (where N > 0) ○ Great idea (in theory) ● What about me? ○ Existing codebase (smells and all) ○ Existing systems & environments (no access) ○ Existing team and politics (no idea) e in ia rt
  • Continuous Delivery : Practice Suck less tomorrow! ● Focus on the journey ○ it will be ongoing anyway ○ simplify / automate ● Crawl / Walk / Run ○ Find a place to start ■ most painful ■ simplest entry point
  • Build : Theory ● Dependencies : what we need lib of Jars / Maven / Ivy ● Artifacts : what we produce tgz / jar / war ● Reproducible : scripted Ant / Maven / Gradle ● Automatable Jenkins
  • Build : Reality ● GOOD ○ Using ant + ivy + sh + junit ● NOT SO GOOD ○ ○ ○ ○ ○ Issues with build dependencies No output artifact No easy way to create DB Only worked on developers machine Took a day or two to get new team members working
  • Build : Practice checkout / build / run ● Tidy up existing ant build (based on intent) ○ clean / compile / test / package ○ create / bootstrap DB locally ● Bundle build properties ● Run app locally ● Generate reports ○ Unit tests (JUnit) ○ Static analysis (FindBugs et al)
  • Deploy : Theory ● Push button / Zero downtime ○ Not always easy: Java != rails != php/apache ● Deploy from developers machine is FAIL ○ Shared env or jump box ○ Then automate (via Jenkins) ● What version is running where ○ Build page ○ All servers up to date with latest version
  • Deploy : Reality ● GOOD ○ Scripted (somewhat) ● NOT SO GOOD ○ ○ ○ ○ ○ Only from developers machine [FAIL!] Ignored errors (FULL STEAM AHEAD) Rsync of build outcome Manual stop / start Customers may see errors during rollout
  • Deploy : Practice ● bash script (Capistrano or similar) ○ stop / upload / unpack / restart ○ similar structure to capistrano on filesystem ● Verify ○ Build page with stats (bundled in artifact) ● DB changes ○ Backwards compatible changes (process) ○ Liquibase is great ● Automated (via Jenkins of course)
  • Run : Theory ● Elastic scaling ○ Dynamic provisioning ○ Automated service management ● Automated monitoring and alerting ○ Sensu / Nagios / ganglia ○ LogStash / GrayLog2 ● Dashboards for EVERYTHING!
  • Run : Reality ● ssh to servers ○ to start stop services ○ monitor perf via top and ps ○ grep and tail -f of log files ● Only ‘qualified’ admins allowed ● No business metrics (manual reports) ● No visibility ● RESTART ! G N I N R A W Prone to human ERORS
  • Run : Practice ● New Relic ○ servers for free ○ app with paid ○ great insight ● Centralized logging ○ rsyslog:unification/collection ○ papertrail:aggregation & display
  • Run : Practice ● Health Metrics (in app) ○ home rolled exposed via web ○ Metrics by CodaHale / Pingdom ● Biz Metrics ○ DucksBoard ■ simple funnel ■ attrition and activity ● Monit ○ alert and restart (if needed)
  • Environments : Theory ‘Works on my machine’ ● Scale – vertically or horizontally ● automatable, reproducible ○ Green / Blue deploys FTW ● Chef / Puppet / Ansible ... just pick one ● If a server fails, can you rebuild it? ● If an environment fails, can you rebuild it?
  • Environments : Reality You won’t always know what you inherit! ● ● ● ● ● Private cloud hosting Limited upgrade ability Manual updates Uncertain/misunderstood foundation SSH and rsync to update and deploy ○ overwrote existing codebase
  • Environments : Practice ● Picked Chef (Vi vs Emacs …) ○ Roles for baseline / Web / App / DB nodes ○ Environments for DEV / STG / PRD ● Vagrant for testing recipes locally ○ config checked into app project ● Automate (via Jenkins of course) ○ validate cookbooks via FoodCritic ○ upload to hosted chef ○ rollout / reprovision via bash / ssh
  • Environments : Practice ● DB backup / restore ○ do it and test it regularly ○ scripted ○ hire an expert Delegate to others ● Mandrill for outgoing SMTP ● DNSimple for managed DNS ● Pingdom for simple uptime ○ custom health check endpoint
  • Environment : Current State Rackspace Cloud Hosted chef Managed by Jenkins ○ Re-Create dev / staging / production ○ deploy staging / production Monitored via ○ Pingdom ○ New Relic ○ PaperTrail app Rolled out to iOS app dev TOO! ○ Xcode CLI / OCUnit / Testflight via Jenkins
  • OH: I deployed to production, nobody noticed and nothing went wrong FTW!