Читать книгу Handbuch Infrastructure as Code - Kief Morris - Страница 59

Definieren Sie Ihre Elemente als Code, ist es einfach und sehr hilfreich, diesen Code in einer Versionsverwaltung (VCS, Version Control System) abzulegen. Dadurch wird Folgendes möglich:

Nachverfolgbarkeit

In der Versionsverwaltung findet sich die Historie der Änderungen, einschließlich der ändernden Person und des Kontexts.¹ Diese Historie ist unbezahlbar, wenn es um das Debuggen von Problemen geht.

Rollback

Geht durch eine Änderung etwas kaputt – insbesondere, wenn mehrere Änderungen etwas kaputt machen –, ist es nützlich, Dinge wieder auf den alten Stand zurücksetzen zu können.

Korrelation

Indem Sie Skripte, Spezifikationen und die Konfiguration unter Versionsverwaltung halten, können Sie knifflige Probleme besser verfolgen und beheben. Sie können mit Tags und Versionsnummern Verbindungen zwischen Elementen herstellen.

Sichtbarkeit

Jeder kann jede Änderung sehen, die in die Versionsverwaltung eingecheckt wurde, sodass das gesamte Team ein Lagebewusstsein bekommt. Vielleicht fällt jemandem auf, dass in einer Änderung etwas Wichtiges fehlt. Kommt es zu einem Vorfall, denken die Teammitglieder darüber nach, ob die letzten Commits dafür gesorgt haben könnten.

Aktionsfähigkeit

Die Versionsverwaltung kann für jede eingecheckte Änderung automatisch eine Aktion auslösen. Solche Trigger ermöglichen CI-Jobs und CD-Pipelines.

Was Sie nicht in die Versionsverwaltung stecken sollten, sind unverschlüsselte Secrets, wie zum Beispiel Passwörter und Schlüssel. Auch wenn Ihr Quellcode-Repository privat ist, sickern die Historie und die Revisionen des Codes doch allzu leicht durch. Secrets, die über Quellcode bekannt werden, sind eine der häufigsten Ursachen für Sicherheitslecks. In »Secrets als Parameter nutzen« auf Seite 133 beschreibe ich bessere Möglichkeiten für den Umgang mit Secrets.