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.

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
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
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.