Git Workflow

Mittels der Versionskontrolle durch Git bieten sich mit Puppet folgende Vorteile:
 

  • Historie – Änderungen an der Infrastruktur sind nachvollziehbar und einem Administrator zuzuordnen.
  • Rollback – Bei Problemen mit neuen Changes kann jederzeit der alte Zustand wiederhergestellt werden.
  • Qualitätskontrolle – Über die Git Hooks wird eine automatische Prüfung auf Fehler durchgeführt.
  • Change Management – Mittels der verschiedenen Branches lässt sich sehr leicht ein Change Management implementieren.

 

Vorbereitungen

Bevor wir mit Git loslegen können sind noch einige Vorbereitungen zu treffen um den Administratoren Zugriff auf das Repository zu ermöglichen.

 

Berechtigungen

Jeder Administrator benötigt einen SSH Key, welcher auf dem zentralen Puppet Repository freigeschaltet werden muss. Unter Linux ist dies wie folgt möglich.

Windows Benutzer müssen Ihren Public Key zunächst auf den Server kopieren und dort mittels cat in die Datei /home/git/.ssh/authorized_keys eintragen. Alternativ ist dieser Schritt auch mit einem Editor möglich, hier ist allerdings darauf zu achten, dass keine Zeilenumbrüche eingefügt werden.

 

Git Client

Jeder Administrator benötigt auf seinem lokalen Endgerät einen passenden Git Client. Für alle gängigen Plattformen stehen entsprechende Lösungen zur Verfügung. Windows Benutzer empfehlen wir hier die Verwendung von TortoiseGit als Frontend. Im ersten Schritt wird das zentrale Git Repository geklont.

Alle Anpassungen werden nun im lokalen Verzeichnis puppet.git vorgenommen (auch Working Copy) genannt.

 

Testen von Änderungen

Die Tests von Änderungen werden immer zunächst lokal durch den Administrator durchgeführt. Für weitergehende Tests kann auch ein lokaler Puppetmaster aufgesetzt werden. Hierfür kann die offizielle Learning VM verwendet werden.

Sind die durchgeführten Änderungen funktionsfähig, können wir diese Committen. Dabei sollte immer eine sinnvolle Notiz hinzugefügt werden.

Bei Syntaxfehlern würde an dieser Stelle bereits einer unserer Git Hooks greifen und bei Fehlern den Commit verweigern.

 

Übermittlung an das Repository

Nachdem die Änderungen lokal committet wurden, können diese an das zentrale Repository übermittelt werden.

 

Change Management / Review

Vor der Produktivsetzung eines neues Changes sollte mindestens ein zweiter Administrator die durchgeführten Änderungen prüfen. Hierzu holt dieser sich die neuen Daten vom Repository.

Sind alle Änderungen in Ordnung, werden die Änderungen zunächst lokal mit unserem Produktivzweig zusammengeführt. Dazu wechseln wir zunächst in den production Branch.

und führen die Änderungen zusammen

Abschließend werden die Änderungen wieder committet.

 

Produktivsetzung

Nachdem die Änderungen per merge zusammengeführt wurden, erfolgt die Übermittlung an das Repository. An dieser Stelle springt der von uns erstellte post-receive Hook ein und überspielt die Änderungen in das Produktivsystem.

 

Historie

Um die Git Historie anzuzeigen wird die Option log verwendet.

Hier werden auch die eindeutigen IDs der Commits in Form eines SHA Hashes angezeigt.

 

Rollback

Funktioniert die neue Konfiguration nicht wie gewünscht, lassen sich die Änderungen zurückrollen. Hierzu aktualisieren wir wieder unsere lokale Working Copy und wechseln in den production Branch.

Im Anschluss machen wir den letzten Commit rückgängig und übermitteln die Änderungen an den Server.

Um zu einem bestimmten Stand zu springen (siehe Historie), verwenden wir den SHA Hash.