Continuous Delivery bis zum Go-Live
Testgetriebenes Arbeiten im Betrieb

Andreas Schmidt

© 2013 Cassini Consulting
@aschmidt75
Cassini Consulting
Management- und
Technologieberatung
>130 Mitarbeiter an 6 Standorten

Agile Methoden & SW-Entwicklung
I...
Infrastructure
Infrastructure
IS
code
Applikations-Deployment
innerhalb der

Leitplanken
der Infrastruktur
Die „Straße in die Produktion“ kann lang sein.

Entwicklungsumgebung

Integrationsumgebung

Testumgebung

Produktionsnahe
...
http://devopsreactions.tumblr.com/post/41776196984/first-test

14.11.20 -
Hauptspeicher und Filesystemgrößen
Konnektivität zwischen Systemen
Routen und Firewallregeln
Effekte bei Skalierung

Siche...
Coda Hale, „Metrics, Metrics Everywhere“ http://bit.ly/PjGYRi 2:28
Wie könnte es aussehen?
Wie könnte es aussehen?

Möglichst geringe

Cycle Time
Wie könnte es aussehen?

Ein Team stellt auf

einheitliche
Art und Weise
Infrastruktur bereit
Wie könnte es aussehen?

Umgebungen

gemeinsam
definieren
Wie könnte es aussehen?

Gemeinsame

testbare
Spezifikation
Was
kann getestet werden?
Ausstattung wie Anzahl CPUs, Speichergrößen,
Betriebssysteme
Art und Umfang von Dateisystemen
Korrekte Netzwerkeinstellung...
Virtualisierung

Konfigurationsmanagement

Infrastruktur
testen
Virtualisierung
Containerization
Cycle
Time
Der

Container
ersetzt die VM
http://karlgrz.com/testing-salt-states-rapidly-with-docker/
https://twitter.com/docker/status/397854039125143552
+
Einfach in der Nutzung
Sehr schnelles Feedback

Virtualisierung ist state-of-theart im Entwicklungsbereich.

Vieles ist ...
Konfigurationsmanagement
chef

chefspec
Puppet

Rspec-puppet
+
Die Konfigurations-Codebasis
lässt sich umfassend testen.
Größere Sicherheit bei
Refactorings (Regressionstests)
In Buil...
Infrastruktur
testen
Servers
pec

serverspec.org
github.com/serverspec/serverspec
facts
+
Viele Aspekte testbar.
Näher an der Realität
geht’s nicht.
Spec beschreibt das
Zielsystem im Ergebniszustand.

Spec ist ...
facts
context
vagrant

erzeugen

Host
Konfigurationsmanagement (Server/Repository)

rspec-puppet

test
puppet code

provisionieren

vagrant

erzeugen

Host
puppe...
Konfigurationsmanagement (Server/Repository)

rspec-puppet

test
puppet code

chefspec

test
chef code

provisionieren

vag...
Konfigurationsmanagement (Server/Repository)

rspec-puppet

chefspec

test
puppet code

test
chef code

provisionieren

vag...
Konfigurationsmanagement (Server/Repository)

rspec-puppet

chefspec

test
puppet code

test
chef code

provisionieren

vag...
Virtualisierung und
Containerization

Erzeuge Instanzen on-the-fly.
Provisioniere mit einem KM-Werkzeug.
Senke die Cycle-T...
Virtualisierung und
Containerization

Erzeuge Instanzen on-the-fly.
Provisioniere mit einem KM-Werkzeug.
Senke die Cycle-T...
Virtualisierung und
Containerization

Erzeuge Instanzen on-the-fly.
Provisioniere mit einem KM-Werkzeug.
Senke die Cycle-T...
Warum

testgetriebene
Infrastruktur?
Testgetriebene
Umgebungen sind

selbstbeschreibend
Fähigkeit zu

Regressionstests
Geringere

Cycle time
=
Höhere

Geschwindigkeit
Formale Audits und
Abnahmen werden

vereinfacht
Bessere Kommunikation
zwischen

Dev
&

Ops
Links / Ressourcen

Coda Hale, „Metrics, Metrics Everywhere“ http://bit.ly/PjGYRi 2:28
Vagrant
Docker

www.vagrantup.com
w...
Cassini Consulting
Niederlassung Düsseldorf
Andreas Schmidt
Alle Angaben basieren auf dem derzeitigen Kenntnisstand. Änder...
Continuous Lifecycle 2013: Testgetriebenes Arbeiten im Betrieb
Continuous Lifecycle 2013: Testgetriebenes Arbeiten im Betrieb
Continuous Lifecycle 2013: Testgetriebenes Arbeiten im Betrieb
Continuous Lifecycle 2013: Testgetriebenes Arbeiten im Betrieb
Continuous Lifecycle 2013: Testgetriebenes Arbeiten im Betrieb
Continuous Lifecycle 2013: Testgetriebenes Arbeiten im Betrieb
Nächste SlideShare
Wird geladen in …5
×

Continuous Lifecycle 2013: Testgetriebenes Arbeiten im Betrieb

1.023 Aufrufe

Veröffentlicht am

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

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.

Veröffentlicht in: Technologie
0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.023
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
2
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Continuous Lifecycle 2013: Testgetriebenes Arbeiten im Betrieb

  1. 1. Continuous Delivery bis zum Go-Live Testgetriebenes Arbeiten im Betrieb Andreas Schmidt © 2013 Cassini Consulting
  2. 2. @aschmidt75
  3. 3. Cassini Consulting Management- und Technologieberatung >130 Mitarbeiter an 6 Standorten Agile Methoden & SW-Entwicklung IT-Betrieb und –Prozesse @cassinigmbh
  4. 4. Infrastructure
  5. 5. Infrastructure IS code
  6. 6. Applikations-Deployment innerhalb der Leitplanken der Infrastruktur
  7. 7. Die „Straße in die Produktion“ kann lang sein. Entwicklungsumgebung Integrationsumgebung Testumgebung Produktionsnahe Referenzumgebung Live-System
  8. 8. http://devopsreactions.tumblr.com/post/41776196984/first-test 14.11.20 -
  9. 9. Hauptspeicher und Filesystemgrößen Konnektivität zwischen Systemen Routen und Firewallregeln Effekte bei Skalierung Sicherheitspolicies ... uvm ...
  10. 10. Coda Hale, „Metrics, Metrics Everywhere“ http://bit.ly/PjGYRi 2:28
  11. 11. Wie könnte es aussehen?
  12. 12. Wie könnte es aussehen? Möglichst geringe Cycle Time
  13. 13. Wie könnte es aussehen? Ein Team stellt auf einheitliche Art und Weise Infrastruktur bereit
  14. 14. Wie könnte es aussehen? Umgebungen gemeinsam definieren
  15. 15. Wie könnte es aussehen? Gemeinsame testbare Spezifikation
  16. 16. Was kann getestet werden?
  17. 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. 18. Virtualisierung Konfigurationsmanagement Infrastruktur testen
  19. 19. Virtualisierung Containerization
  20. 20. Cycle Time
  21. 21. Der Container ersetzt die VM
  22. 22. http://karlgrz.com/testing-salt-states-rapidly-with-docker/
  23. 23. https://twitter.com/docker/status/397854039125143552
  24. 24. + Einfach in der Nutzung Sehr schnelles Feedback Virtualisierung ist state-of-theart im Entwicklungsbereich. Vieles ist konfigurierbar, aber nicht alles.
  25. 25. Konfigurationsmanagement
  26. 26. chef chefspec
  27. 27. Puppet Rspec-puppet
  28. 28. + Die Konfigurations-Codebasis lässt sich umfassend testen. Größere Sicherheit bei Refactorings (Regressionstests) In Build- und Deploychain integrierbar. Spec und Code auf ähnlichem Abstraktionsniveau. Test reflektiert den Soll-, aber nicht notwendigerweise den Ist-Zustand.
  29. 29. Infrastruktur testen
  30. 30. Servers pec serverspec.org github.com/serverspec/serverspec
  31. 31. facts
  32. 32. + 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.
  33. 33. facts
  34. 34. context
  35. 35. vagrant erzeugen Host
  36. 36. Konfigurationsmanagement (Server/Repository) rspec-puppet test puppet code provisionieren vagrant erzeugen Host puppet
  37. 37. Konfigurationsmanagement (Server/Repository) rspec-puppet test puppet code chefspec test chef code provisionieren vagrant erzeugen Host puppet chef
  38. 38. Konfigurationsmanagement (Server/Repository) rspec-puppet chefspec test puppet code test chef code provisionieren vagrant erzeugen Host puppet chef OS-Fakten (facter | ohai | Shell) test serverspec
  39. 39. Konfigurationsmanagement (Server/Repository) rspec-puppet chefspec test puppet code test chef code provisionieren vagrant erzeugen Host puppet chef OS-Fakten (facter | ohai | Shell) test serverspec test infrastructure-by-story
  40. 40. Virtualisierung und Containerization Erzeuge Instanzen on-the-fly. Provisioniere mit einem KM-Werkzeug. Senke die Cycle-Time zum Test.
  41. 41. Virtualisierung und Containerization Erzeuge Instanzen on-the-fly. Provisioniere mit einem KM-Werkzeug. Senke die Cycle-Time zum Test. Konfigurationsmanagement Teste den KM-Code. Stelle sicher, dass der Code das tut was er soll. Build things right.
  42. 42. Virtualisierung und Containerization Erzeuge Instanzen on-the-fly. Provisioniere mit einem KM-Werkzeug. Senke die Cycle-Time zum Test. Konfigurationsmanagement 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.
  43. 43. Warum testgetriebene Infrastruktur?
  44. 44. Testgetriebene Umgebungen sind selbstbeschreibend
  45. 45. Fähigkeit zu Regressionstests
  46. 46. Geringere Cycle time = Höhere Geschwindigkeit
  47. 47. Formale Audits und Abnahmen werden vereinfacht
  48. 48. Bessere Kommunikation zwischen Dev & Ops
  49. 49. Links / Ressourcen Coda Hale, „Metrics, Metrics Everywhere“ http://bit.ly/PjGYRi 2:28 Vagrant Docker www.vagrantup.com www.docker.io Puppet Rspec-puppet www.puppetlabs.com http://rspec-puppet.com/ | https://github.com/rodjek/rspec-puppet Chef Chefspec http://www.opscode.com/chef/ https://github.com/acrmp/chefspec Serverspec www.serverspec.org Infrastructure-by-story | https://github.com/serverspec/serverspec https://github.com/aschmidt75/infrastructure-by-story
  50. 50. Cassini Consulting Niederlassung Düsseldorf Andreas Schmidt Alle Angaben basieren auf dem derzeitigen Kenntnisstand. Änderungen vorbehalten. Bennigsen-Platz 1 40474 Düsseldorf Deutschland andreas.schmidt@cassini.de visit www.cassini.de 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.

×