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

Deployment ohne Ziepen

9a8d72e6f77c291093276b0cb9277f36?s=47 bascht
September 18, 2013

Deployment ohne Ziepen

Trotz push-to-deploy und CI via travis.yaml werden unsere Projekte schnell zu groß für »einfache« Deployment-Lösungen. Sobald die eigene App aus den Heroku-Schuhen wächst, beginnen sich die technischen Schulden zu häufen. Lasst uns versuchen, den Spaß zurück ins Deployment zu bringen. Egal ob ihr Chef, Puppet oder die gute alte Doppelläufige verwendet: Mit wenigen Handgriffen und den richtigen Ruby Werkzeugen könnt ihr euch eine Deployment-Pipeline zurechtbiegen, auf die sogar Fowler stolz wäre.

9a8d72e6f77c291093276b0cb9277f36?s=128

bascht

September 18, 2013
Tweet

Transcript

  1. Deployment. Ohne Ziepen RedFrog Conf - FrOSCon 8 Sebastian Schulze

    @bascht
  2. about:me Sebastian Schulze @bascht 28.years Leipzig & Köln Berlin. (Von

    Zeit zu Zeit) Vogtland
  3. None
  4. about:me Freiberuflicher Software- und Infrastruktur-Entwickler. Begleite Unternehmen entlang des kritischen

    Pfades. (Das klang in den englischen Slides wesentlich professioneller)
  5. None
  6. Dieser Talk.

  7. Stellt euch vor… …es ist Freitag.

  8. Euer Deployment-Graph…

  9. None
  10. …skaliert nicht

  11. Metriken Wer versteht l i b / c o m

    m o n / h e l p e r s / b a s e / d o m a i n . r b noch? Wer versteht euer Deployment?
  12. Busnumber

  13. None
  14. Warum nicht… So oft wie möglich? Die neuen Mitarbeiter machen

    lassen? Still und leise im Hintergrund?
  15. Galileo Galilei - 1636

  16. © 2013 — theprofoundprogrammer.com

  17. 2013 Behandelt sie auch wie Code!

  18. Wo entstehen die Probleme? Im Code? In der Serverkonfiguration? Beim

    Rollout? Im Zusammenspiel?
  19. None
  20. Keine Ausreden mehr! Infrastruktur Problem? Bug-Ticket Infrastruktur Änderung? Feature-Ticket Großer

    Feature-Rollout steht bevor? Story-Ticket
  21. Kein Commit ohne Ticket. Kein Release ohne Ticket.

  22. Code-Reviews! Auch für Infrastruktur. Erst recht für Infrastruktur.

  23. Kopplung Gibt es Release-Branches für euer Infrastruktur-Repository? Zu welchem Infrastruktur-Branch

    gehört Application-Branch f e a t u r e / g h - 1 3 8 2 ? Läuft Software 4 . 2 . 2 3 auch noch mit Migrations-Stand 2 . 4 . 2 1 - h o t f i x ? Wie geht es eurem Frontend, wenn es kein Backend mehr gibt?
  24. Rollout (Donnergrollen)

  25. Effing Package Management

  26. None
  27. $ g e m i n s t a l

    l f p m
  28. $ c u r l - s h t t

    p : / / s e m v e r . o r g | s e d ' s / < [ ^ > ] * > / / g ' | s a y
  29. Dokumentation (Donnergrollen)

  30. Wiki > Code > CLI

  31. Das Firmenwiki Neue Mitarbeiter? Alte Hostnamen? Kreuz-Referenzen! Makros? Kopierbare Kommandos?

  32. Eure Toolchain

  33. versioniert korrekt benamt dokumentiert selbsterklärend umgebungsunabhängig

  34. Y.A.G.N.I! vs. A.Y.G.N.I.A.L.O.?

  35. Hübsch verpacken.

  36. # ! / b i n / b a s

    h
  37. # ! / u s r / b i n

    / e n v r u b y
  38. Ruby?

  39. --Chet Ramey Ja, Ruby! “ ... there are dark corners

    in the Bourne shell, and people use all of them. ” [ 1 - e q 1 ] & & [ - n " ` e c h o t r u e 1 > & 2 ` " ] # t r u e [ 1 - e q 2 ] & & [ - n " ` e c h o t r u e 1 > & 2 ` " ] # ( n o o u t p u t )
  40. Seid genügsam. Und robust. 1.8, 1.8, 1.8 stayin' alive Manchmal

    geht's auch ohne Gem
  41. 1.8 vs. Rubygems RVM vs. sudo

  42. r o o t @ m y f u n

    k y f u n k y . e n t e r p r i s e . b o x : ~ $ b u n d l e l i s t - b a s h : b u n d l e : c o m m a n d n o t f o u n d
  43. Zwei neue Freunde: b u n d l e p

    a c k a g e b u n d l e i n s t a l l - - s t a n d a l o n e
  44. bundle/bundler/setup.rb r e q u i r e ' r

    b c o n f i g ' # r u b y 1 . 8 . 7 d o e s n ' t d e f i n e R U B Y _ E N G I N E r u b y _ e n g i n e = d e f i n e d ? ( R U B Y _ E N G I N E ) ? R U B Y _ E N G I N E : ' r u b y ' r u b y _ v e r s i o n = R b C o n f i g : : C O N F I G [ " r u b y _ v e r s i o n " ] p a t h = F i l e . e x p a n d _ p a t h ( ' . . ' , _ _ F I L E _ _ ) t h o r = " # { p a t h } / . . / # { r u b y _ e n g i n e } / # { r u b y _ v e r s i o n } / g e m s / t h o r - 0 . 8 / l i b " $ : . u n s h i f t F i l e . e x p a n d _ p a t h ( t h o r )
  45. r e q u i r e ' b u

    n d l e / b u n d l e r / s e t u p ' r e q u i r e ' t h o r ' c l a s s M y T h o r C o m m a n d < T h o r d e s c " f o o " , " P r i n t s f o o " d e f f o o p u t s " f o o " e n d e n d M y T h o r C o m m a n d . s t a r t
  46. Migrationen Look, I don't know what you're yelling at me

    for, I wouldn't have dropped those tables if you hadn't told me to. 11:00 PM - 13 Aug 2013 Sad Server @sadserver Follow Follow 49 RETWEETS 17 FAVORITES
  47. Reversible migrations are migrations that know how to go down

    for you. You simply supply the up logic, and the Migration system will figure out how to execute the down commands for you.
  48. Deal?

  49. Für den Fehlerfall bauen Wie sehen eure Fehlerseiten aus? Kann

    jeder Layer kaputt gehen? Wie schnell könnt ihr zurückrollen? Könnt ihr Features deaktivieren? Könnt ihr stale content ausliefern?
  50. Deployment-Scripte werden wertvoller, je öfter ihr sie ausführt.

  51. None
  52. Mitarbeiter des Monats

  53. Deployment ist nicht der letzte Schritt!

  54. Lebenszeichen direkt nach dem Deployment einsammeln.

  55. Puls fühlen $ c u r l - X G

    E T ' h t t p : / / l o c a l h o s t : 9 2 0 0 / _ c l u s t e r / h e a l t h ? p r e t t y = t r u e ' { " c l u s t e r _ n a m e " : " p r i s m _ e u r o p e " , " s t a t u s " : " g r e e n " , " t i m e d _ o u t " : f a l s e , " n u m b e r _ o f _ n o d e s " : 2 4 2 , " n u m b e r _ o f _ d a t a _ n o d e s " : 2 4 2 " a c t i v e _ p r i m a r y _ s h a r d s " : 5 0 , " a c t i v e _ s h a r d s " : 1 0 0 , " r e l o c a t i n g _ s h a r d s " : 0 , " i n i t i a l i z i n g _ s h a r d s " : 0 , " u n a s s i g n e d _ s h a r d s " : 0 }
  56. Lebenszeichen checken v a r c a s p e

    r = r e q u i r e ( ' c a s p e r ' ) . c r e a t e ( ) ; v a r b a s e u r l = c a s p e r . c l i . g e t ( " b a s e u r l " ) | | ' h t t p : / / b a s c h t . c o m ' ; c a s p e r . s t a r t ( b a s e u r l , f u n c t i o n ( ) { t h i s . c a p t u r e ( ' s h o t s / h o m e p a g e . p n g ' ) ; t h i s . t e s t . a s s e r t T i t l e ( ' b a s c h t . c o m ' ) ; t h i s . t e s t . a s s e r t E x i s t s ( ' i n p u t [ a c t i o n $ = " / s e a r c h " ] ' , ' Y a y . S u c h e ! ' ) ; t h i s . c l i c k L a b e l ( ' B l o g ' , ' a ' ) ; } ) ;
  57. — Timothy Fitz (IMVU) “Treat staging failures like as if

    they were production failures.”
  58. — Bascht (RedFrog Con 2013) “Das Frühstücks-Deployment ist die wertvollste

    Mahlzeit des Tages”
  59. Kleiner Lackmustest Vielen Dank! Twitter / Github / ADN: @bascht

    # ~ / . b a s h _ l o g i n r m ~ / . b a s h _ h i s t o r y & & s y n c ; e c h o " T h e y n e v e r f a i l w h o d i e , I n a g r e a t c a u s e ! - - L o r d B y r o n " ; e c h o " W e l c o m e t o $ ( h o s t n a m e ) . " ;