Continuous Lifecycle 2013: Testgetriebenes Arbeiten im Betrieb
•
1 gostou•1,147 visualizações
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.
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a Continuous Lifecycle 2013: Testgetriebenes Arbeiten im Betrieb
Semelhante a Continuous Lifecycle 2013: Testgetriebenes Arbeiten im Betrieb (20)
Mais de Andreas Schmidt
Mais de Andreas Schmidt (6)
Continuous Lifecycle 2013: Testgetriebenes Arbeiten im Betrieb
- 1. Continuous Delivery bis zum Go-Live Testgetriebenes Arbeiten im Betrieb Andreas Schmidt © 2013 Cassini Consulting
- 2. @aschmidt75
- 3. Cassini Consulting Management- und Technologieberatung >130 Mitarbeiter an 6 Standorten Agile Methoden & SW-Entwicklung IT-Betrieb und –Prozesse @cassinigmbh
- 7. Die „Straße in die Produktion“ kann lang sein. Entwicklungsumgebung Integrationsumgebung Testumgebung Produktionsnahe Referenzumgebung Live-System
- 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
- 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
- 20. Cycle Time
- 25. + Einfach in der Nutzung Sehr schnelles Feedback Virtualisierung ist state-of-theart im Entwicklungsbereich. Vieles ist konfigurierbar, aber nicht alles.
- 27. chef chefspec
- 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 Abstraktionsniveau. Test reflektiert den Soll-, aber nicht notwendigerweise den Ist-Zustand.
- 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
- 42. Konfigurationsmanagement (Server/Repository) rspec-puppet test puppet code chefspec test chef code provisionieren vagrant erzeugen Host puppet chef
- 43. 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
- 44. 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
- 45. Virtualisierung und Containerization Erzeuge Instanzen on-the-fly. Provisioniere mit einem KM-Werkzeug. Senke die Cycle-Time zum Test.
- 46. 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.
- 47. 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.
- 52. Formale Audits und Abnahmen werden vereinfacht
- 55. 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
- 56. 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.