Upgrade to Pro — share decks privately, control downloads, hide ads and more …

How build and deployment should shape software ...

How build and deployment should shape software architectures

Build and deployment concerns can help us to avoid some architecture anti-patterns, and enable some useful system properties.

Matthew Skelton

September 10, 2012
Tweet

More Decks by Matthew Skelton

Other Decks in Technology

Transcript

  1. How build and deployment should shape software architectures Matthew Skelton

    CEng | thetrainline.com IASA UK Ignite 2, London | #iasaignite 10 September 2012
  2. Systems engineering (robotics, control theory, sensors, neuroscience) Software development (finance,

    insurance, travel, pharma, media, medical imaging) now Build & Deployment at thetrainline.com @matthewpskelton
  3. BUILDABLE Small pipelined builds on generic build machines Seconds, not

    minutes or hours Short feedback cycles (Dan Worthington-Bodart, @danielbodart - http://bit.ly/M85wsX)
  4. TESTABLE Test (separation, harnesses, points) IDENTIFIABLE Meaningful versions, packages, defined

    dependencies, artefact management (think component boundaries)
  5. DEPLOYABLE Rapid, scriptable, simple failure modes MONITORABLE Logging, metrics, transaction

    tracing CONFIGURABLE Inject settings – no ‘black boxes’ LIGHTWEIGHT Keep things small and easily comprehendible
  6. INSTANTIABLE No snowflakes or singletons RECOVERABLE No nasty zombies after

    failures MTTR more important than MTBF* * for most kinds of F
  7. architecture = f (build & deploy) (for some systems) thank

    you IASA: www.iasaglobal.org matthewskelton.net | @matthewpskelton Thanks to: Attila S, Jack R and Owain P for feedback. Picture credits: Petra: Wikimedia/Berthold Werner; army engineers: US DoD; ball of mud: pwern.blogspot.co.uk; sports car: xarj.net; zombie: bjj.org; feather: Wikipedia; punch: thelegalblitz.com; passport: coverpalace.com; dogs: reluctantmemsahib.wordpress.com; Meccano: dalefield.com