• Publikation
  • Testgetriebene Infrastrukturentwicklung mit Ansible und Molecule
  • Testgetriebene Infrastrukturentwicklung mit Ansible und Molecule

iX

04/19

Testgetriebene Infrastrukturentwicklung mit Ansible und Molecule

Autor:
Jonas Hecht

Wenn die IT-Infrastruktur mit Code gemanagt wird, muss dieser Code automatisiert testbar sein. Molecule ermöglicht die testgetriebene Entwicklung und somit auch Continuous Integration für das beliebte DevOps-Werkzeug Ansible.

Das Beschreiben und Steuern von Infrastruktur durch Code (Infrastructure as Code, IaC) bietet viele Vorteile: Die Dokumentation kann nicht veralten, denn sie liegt als Quellcode versioniert vor. Dabei ist sie direkt automatisiert ausführbar und erzeugt die gewünschte Infrastruktur. Außerdem werden so Kopfmonopole vermieden, bei denen wichtiges Know-how zum Betrieb der Infrastruktur lediglich in den Köpfen weniger Leute steckt. Gleichzeitig ist endlich für das ganze Team transparent, wer was wann wie an den Infrastrukturkomponenten verändert hat – sogar über Teamgrenzen hinweg. Nicht zuletzt abstrahieren moderne IaC-Werkzeuge wie Ansible mit ihren Modulen von vielen kleinen Details. Das reduziert den Entwicklungs- und vor allem den Wartungsaufwand.

Doch wenn nur noch Quellcode geschrieben wird, unterscheidet sich die Infrastrukturentwicklung nicht mehr von der „normalen“ Softwareentwicklung. Das wirft die Frage auf, wie es eigentlich um die Grundsätze der modernen Softwareentwicklung beim Thema Infrastructure as Code bestellt ist. Heute wird wohl kaum jemand ein Softwareprojekt beginnen und dabei auf die Vorzüge des Einsatzes von agilen Methoden, testgetriebener Entwicklung (Test-driven Development, TDD) und Continuous Integration (CI) verzichten wollen.

Warum eigentlich testgetrieben?
Und das hat gute Gründe: Wird Quellcode nicht regelmäßig ausgeführt, veraltet er sehr schnell. Das gilt für Software- wie
Infrastrukturcode gleichermaßen. So kann ein Update einer genutzten Bibliothek den ganzen Code nutzlos machen. Das gilt analog für Betriebssystem-Updates. Ein Refaktorisieren des Codes, um neue Anforderungen umzusetzen, ist fehleranfällig und wird ohne Testabdeckung immer riskanter. Wer schon mal ein paar Zeilen Infrastrukturcode geschrieben hat, kennt das Problem: Nach einem halben Jahr funktioniert unter Umständen kaum noch etwas davon.

Durch das Ausführen von Tests lässt sich jederzeit überprüfen, ob die bisherigen Funktionen nach der Implementierung neuer Anforderungen weiterhin laufen. Fehler fallen so möglichst früh auf, was bekanntermaßen die Kosten für ihre Behebung senkt. Im zweiten Schritt laufen die Tests bei jeder Codeänderung im Versionskontrollsystem automatisiert auf einem Continuous-Integration-Server. Schlägt dort ein Test fehl, gibt es sofort Feedback. Das hilft auch, Fehler in der Zusammenarbeit zu vermeiden, wenn mehrere Entwickler gleichzeitig an derselben Komponente arbeiten.

Vollständiger Artikel

Cookies erleichtern die Bereitstellung unserer Dienste. Mit der Nutzung unserer Dienste erklären Sie sich damit einverstanden, dass wir Cookies verwenden. Weitere Informationen

Hinweis: In Ihrem Browser ist JavaScript deaktiviert. Für eine bessere und fehlerfreie Nutzung dieser Webseite, aktivieren Sie bitte JavaScript in Ihrem Browser.