Deploy like nobody is watching

Slide 1

Slide 1 text

Deploy like nobody is watching. March 11th, 2015 @bascht

Slide 2

Slide 2 text

Ye olde DevOps

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

Silos

Slide 5

Slide 5 text

Distribution of roles

Slide 6

Slide 6 text

Creative Commons Attribution 4.0 International (http://commons.wikimedia.org/wiki/File:The_Devil_and_Dr._Faustus_meet._Wellcome_L0031469.jpg)

Slide 7

Slide 7 text

…the »old world« software developer…

Slide 8

Slide 8 text

…the »old world« system administrator…

Slide 9

Slide 9 text

So – let's swap roles. (Can't be that hard, no?)

Slide 10

Slide 10 text

* { /* No idea what I'm cascading here… */ color: 'Kornblumenblau' !important; }

Slide 11

Slide 11 text

$$('I'){ $('will#wrap').each(function('until'){ return this.self._self.that['crap'].works; }); };;;; // eat ._this, jslint!

Slide 12

Slide 12 text

$ sudo sudo su -c "sudo do --what 'I want'"

Slide 13

Slide 13 text

Small castles CC BY-NC-ND 2.0 — Jos van Wunnik

Slide 14

Slide 14 text

Galileo Galilei - 1636

Slide 15

Slide 15 text

nginx::resource::upstream { 'here_be_dragons': members => [ 'lolcathost:8080', 'lolcathost:8081', 'lolcathost:8082', ], } nginx::resource::vhost { 'app.yournextstartup.com': proxy => 'http://here_be_dragons', }

Slide 16

Slide 16 text

Tools ansiblebcfg2cdistchefcfengineisconfjujulcfg ocsinventoryngwithglpiopsipikt puppetquattorradmindrex rundecksmartfrogsaltspacewalk

Slide 17

Slide 17 text

docker docker docker docker docker docker docker docker docker docker docker docker docker docker

Slide 18

Slide 18 text

Being responsible for the artefact that is shipped. Every step of the pipeline.

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

MANAGEMENT = :mediocre CUSTOMER = :opinionated def my_little_farm(requirements) engineering = :truly_optimistic trap("SIGINT") { ignore_those_admins } pray_for(some.kind_of? Wonder) ship! end

Slide 21

Slide 21 text

Releases.

Slide 22

Slide 22 text

Imagine… …it's friday.

Slide 23

Slide 23 text

Your deployment plan… …doesn't scale very well.

Slide 24

Slide 24 text

gut metrics Who truly understands every base / helper / tools / domain class? Who understands your deployment process?

Slide 25

Slide 25 text

busnumber

Slide 26

Slide 26 text

Why not… deploy as often as possible? let the new employee deploy on her first day? deploy when nobody is watching?

Slide 27

Slide 27 text

2015 Infrastructure code is code as well!

Slide 28

Slide 28 text

Are your problems bubbling up… …from app code? …from your server configuration? …during rollout? …because of poor orchestration?

Slide 29

Slide 29 text

Slide 30

Slide 30 text

No more excuses. Infrastructure problem? File an issue Infrastructure change? Hand in a story App Changes need infrastructure changes? Orchestrate your rollouts.

Slide 31

Slide 31 text

No commit without an issue id / feature branch. No major release without documentation in an issue.

Slide 32

Slide 32 text

Do code reviews. Yes. for infrastructure. Yes. Even for infrastructure.

Slide 33

Slide 33 text

Sorry, but there is no one-size-fits-all solution. Quelle: GFDL image by user Fanghong. Creative Commons Attribution-Share Alike 3.0 Unported

Slide 34

Slide 34 text

Well, turns out there is.

Slide 35

Slide 35 text

Documentation (imagine rolling thunder)

Slide 36

Slide 36 text

CLI > Code > Wiki $ bin/deploy --wat?

Slide 37

Slide 37 text

Actually use your Wiki! New employees? Old hostnames? Cross references! Macros? Copy / Paste commands?

Slide 38

Slide 38 text

Your toolchain? in version control useful names well documented self-explanatory independent from the environment

Slide 39

Slide 39 text

Use some nice wrapping.

Slide 40

Slide 40 text

#!/bin/(da|ba)sh #nope

Slide 41

Slide 41 text

#!/usr/bin/env ruby

Slide 42

Slide 42 text

--Chet Ramey “ ... there are dark corners in the Bourne shell, and people use all of them. ”

Slide 43

Slide 43 text

Build for the worst. Do your error pages cover every layer? Will every layer fail gracefully? Can you roll back? Should you roll back? Can you deactivate features? Can you afford to deliver stale content?

Slide 44

Slide 44 text

restore > backup

Slide 45

Slide 45 text

employee of the month

Slide 46

Slide 46 text

Updating artefacts isn't the last step!

Slide 47

Slide 47 text

Monitor every deployment. Gather health checks.

Slide 48

Slide 48 text

Steal good ideas! $ curl -XGET 'lolcathost:9200/_cluster/health?pretty=true' { "cluster_name" : "prism_europe", "status" : "green", "timed_out" : false, "number_of_nodes" : 242, "number_of_data_nerds" : 242 "active_primary_shards" : 50, "active_shards" : 100, "people_actually_reading_this_slide": 1, "relocating_shards" : 0, "initializing_shards" : 0 }

Slide 49

Slide 49 text

Use obvious tools. var casper = require('casper').create(); var baseurl = casper.cli.get("baseurl") || 'http://bascht.com'; casper.start(baseurl, function() { this.capture('shots/homepage.png'); this.test.assertTitle('bascht.com'); this.test.assertExists('input[action$="/search"]', 'Yay!'); this.clickLabel('Blog', 'a'); });

Slide 50

Slide 50 text

— Timothy Fitz (IMVU) “Treat staging failures like as if they were production failures.”

Slide 51

Slide 51 text

We're almost done.

Slide 52

Slide 52 text

-- Robert A. Heinlein “Specialization is for insects.”

Slide 53

Slide 53 text

See how things work out. # ~/.bash_login rm ~/.bash_history && sync; echo "They never fail who die, In a great cause! Lord Byron"; echo "Welcome to $(hostname).";

Slide 54

Slide 54 text

Sebastian Schulze (@bascht / @bscht) , 29.years Software- & infrastructure developer Vogtland, Leipzig, Köln, Berlin, Munich Thank you! Twitter / Github / ADN: @bascht