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

Continuous Lifecycle 2013: Testgetriebenes Arbeiten im Betrieb

Continuous Lifecycle 2013: Testgetriebenes Arbeiten im Betrieb

http://www.continuouslifecycle.de/lecture.php?id=290
#ConLi2013

Continuous Delivery bis zum Go-Live – testgetriebenes Arbeiten im Betrieb
Ein Ziel von Continuous Delivery ist die beschleunigte Bereitstellung von Software. Die Software ist ausgeliefert – aber erst erfolgreich ausgerollt gilt als "delivered". Entwickler und Betriebler treffen an der Infrastrukturfront aufeinander: Wie viele Server, CPUs, Speicher und welche Netze werden benötigt? Und wie reden alle miteinander? Während testgetriebene Softwareentwicklung als Standard gilt, wird Infrastruktur trotz DevOps häufig manuell "hochgezogen" und selten automatisiert getestet. Der Vortrag gibt einen Überblick über Möglichkeiten und Tools, Infrastruktur testbar zu machen. Er zeigt, wie Entwicklung und Betrieb gemeinsam Infrastrukturkomponenten planen und umsetzen sollten.

F28d4f1634bce85c90b76b197b1413d4?s=128

Andreas Schmidt

November 12, 2013
Tweet

Transcript

  1. © 2013 Cassini Consulting Andreas Schmidt Continuous Delivery bis zum

    Go-Live Testgetriebenes Arbeiten im Betrieb
  2. @aschmidt75

  3. Cassini Consulting   Management- und Technologieberatung   >130 Mitarbeiter an

    6 Standorten   Agile Methoden & SW-Entwicklung   IT-Betrieb und –Prozesse   @cassinigmbh
  4. Infrastructure

  5. Infrastructure IS code

  6. Applikations-Deployment innerhalb der Leitplanken der Infrastruktur

  7. Die „Straße in die Produktion“ kann lang sein. Entwicklungs- umgebung

    Integrations- umgebung Test- umgebung Produktionsnahe Referenzumgebung Live-System
  8. 14.11.13 - http://devopsreactions.tumblr.com/post/41776196984/first-test

  9.   Hauptspeicher und Filesystemgrößen   Konnektivität zwischen Systemen   Routen

    und Firewallregeln   Effekte bei Skalierung   Sicherheitspolicies   ... uvm ...
  10. Coda Hale, „Metrics, Metrics Everywhere“ http://bit.ly/PjGYRi 2:28

  11. Wie könnte es aussehen?

  12. Wie könnte es aussehen? Möglichst geringe Cycle Time

  13. Wie könnte es aussehen? Ein Team stellt auf einheitliche Art

    und Weise Infrastruktur bereit
  14. Wie könnte es aussehen? Umgebungen gemeinsam definieren

  15. Wie könnte es aussehen? Gemeinsame testbare Spezifikation

  16. Was kann getestet werden?

  17.   Ausstattung wie Anzahl CPUs, Speichergrößen, Betriebssysteme   Art und

    Umfang von Dateisystemen   Korrekte Netzwerkeinstellungen (IP-Adressen, Netzmasken, Routen)   Verfügbarkeit von Backendsystemen (Ping)   Dateien und Verzeichnisse liegen mit korrekten Rechten vor   Features sind eingeschaltet (selinux, Firewall, ...)   ...uvm
  18. Virtualisierung Konfigurations- management Infrastruktur testen

  19. Virtualisierung Containerization 1

  20. Cycle Time

  21. Der Container ersetzt die VM

  22. None
  23. http://karlgrz.com/testing-salt-states-rapidly-with-docker/

  24. https://twitter.com/docker/status/397854039125143552

  25. + - Einfach in der Nutzung Sehr schnelles Feedback Virtualisierung

    ist state-of-the- art im Entwicklungsbereich. Vieles ist konfigurierbar, aber nicht alles.
  26. Konfigurations- management 2

  27. chefspec chef

  28. Rspec-puppet Puppet

  29. + - Die Konfigurations-Codebasis lässt sich umfassend testen. Größere Sicherheit

    bei Refactorings (Regressionstests) In Build- und Deploychain integrierbar. Spec und Code auf ähnlichem Abstraktions- niveau. Test reflektiert den Soll-, aber nicht notwendiger- weise den Ist-Zustand.
  30. Infrastruktur testen 3

  31. Serverspec serverspec.org github.com/serverspec/serverspec

  32. facts

  33. None
  34. None
  35. None
  36. None
  37. + - Viele Aspekte testbar. Näher an der Realität geht’s

    nicht. Spec beschreibt das Zielsystem im Ergebniszustand. Spec ist teilweise aber umgebungsspezifisch. Spec liegt auf Implementierungsniveau.
  38. facts

  39. context

  40. Host vagrant erzeugen

  41. Host puppet Konfigurationsmanagement (Server/Repository) puppet code rspec-puppet test vagrant erzeugen

    provisionieren
  42. Host puppet chef Konfigurationsmanagement (Server/Repository) puppet code chefspec chef code

    rspec-puppet test test vagrant erzeugen provisionieren
  43. Host puppet OS-Fakten (facter | ohai | Shell) chef Konfigurationsmanagement

    (Server/Repository) puppet code chefspec chef code rspec-puppet test test serverspec test vagrant erzeugen provisionieren
  44. Host puppet OS-Fakten (facter | ohai | Shell) chef Konfigurationsmanagement

    (Server/Repository) puppet code chefspec chef code rspec-puppet test test serverspec test vagrant erzeugen provisionieren infrastructure-by-story test
  45. Virtualisierung und Containerization Erzeuge Instanzen on-the-fly. Provisioniere mit einem KM-Werkzeug.

    Senke die Cycle-Time zum Test. 1
  46. Virtualisierung und Containerization Erzeuge Instanzen on-the-fly. Provisioniere mit einem KM-Werkzeug.

    Senke die Cycle-Time zum Test. Konfigurations- management Teste den KM-Code. Stelle sicher, dass der Code das tut was er soll. Build things right. 1 2
  47. Virtualisierung und Containerization Erzeuge Instanzen on-the-fly. Provisioniere mit einem KM-Werkzeug.

    Senke die Cycle-Time zum Test. Konfigurations- management Teste den KM-Code. Stelle sicher, dass der Code das tut was er soll. Build things right. Werkzeuge zum Infrastrukturtest und Infrastruktur-Stories Beschreibe Infrastrukturaspekte von Instanzen. Teste die laufenden Instanzen. Build things right. Build the right things. 1 2 3
  48. Warum testgetriebene Infrastruktur?

  49. Testgetriebene Umgebungen sind selbst- beschreibend

  50. Fähigkeit zu Regressionstests

  51. Geringere Cycle time = Höhere Geschwindigkeit

  52. Formale Audits und Abnahmen werden vereinfacht

  53. Bessere Kommunikation zwischen Dev & Ops

  54. ?

  55. Links / Ressourcen " Coda Hale, „Metrics, Metrics Everywhere“ http://bit.ly/PjGYRi

    2:28 " Vagrant www.vagrantup.com " Docker www.docker.io " Puppet www.puppetlabs.com " Rspec-puppet http://rspec-puppet.com/ | https://github.com/rodjek/rspec-puppet " Chef http://www.opscode.com/chef/ " Chefspec https://github.com/acrmp/chefspec " Serverspec www.serverspec.org | https://github.com/serverspec/serverspec " Infrastructure-by-story https://github.com/aschmidt75/infrastructure-by-story
  56. Cassini Consulting Niederlassung Düsseldorf Andreas Schmidt Bennigsen-Platz 1 40474 Düsseldorf

    Deutschland andreas.schmidt@cassini.de visit www.cassini.de Alle Angaben basieren auf dem derzeitigen Kenntnisstand. Änderungen vorbehalten. Dieses Dokument von Cassini Consulting ist ausschließlich für den Adressaten bzw. Auftraggeber bestimmt. Es bleibt bis zur einer ausdrücklichen Übertragung von Nutzungsrechten Eigentum von Cassini. Jede Bearbeitung, Verwertung, Vervielfältigung und/oder gewerbsmäßige Verbreitung des Werkes ist nur mit Einverständnis von Cassini zulässig.