DevOps-Praxis

Wie die Pipelines clean bleiben

Continuous Integration (CI) und Continuous Deployment (CD) sorgen für regelmässige, automatisierte Prozesse in der agilen Softwareentwicklung, um die Qualität und die Auslieferung der Software zu optimieren. Clean Pipelines sind dafür eine wichtige Voraussetzung. bbv-Experte Joachim Jabs erläutert die Dos and Don‘ts bei CI/CD-Pipelines.

01.07.2020Text: bbv0 Kommentare

Continuous Integration (CI) und Continuous Deployment (CD) sorgen für regelmässige, automatisierte Prozesse in der agilen Softwareentwicklung, um die Qualität und die Auslieferung der Software zu optimieren. Clean Pipelines sind dafür eine wichtige Voraussetzung. bbv-Experte Joachim Jabs erläutert die Dos and Don‘ts bei CI/CD-Pipelines.

Statt während Tagen, Wochen oder gar Monaten den entwickelten Code am Schluss des Projekts in den Quellcode einzufügen und diesen zu testen, wird bei CI der neu geschriebene Code kontinuierlich – also täglich oder häufiger – implementiert. Mit der regelmässigen Integration der Teilbereiche kennen alle Beteiligten jederzeit den Zustand der aktuellen Software. So können Fehler sofort erkannt und Tests regelmässig durchgeführt werden.

Die aktuelle Software-Version wird also in kleinen Schritten entwickelt, sodass die Teams auch auf kurzfristige Änderungen besser reagieren können. Dasselbe gilt für CD, also für Continuous Delivery beziehungsweise für Continuous Deployment. Doch weil viele Beteiligte am gemeinsamen Repository arbeiten, muss die Kommunikation und die Zusammenarbeit ebenso Hand in Hand gehen. Gerade bei automatisierten Prozessen in Entwicklungs- und Test-Phasen wird diese Arbeit durch eine agile Zusammenarbeit von DevOps-Teams unterstützt. Dies gilt für sämtliche Phasen von der Integration und im Testing bis zur Bereitstellung und Implementierung.

Clean Code für Pipelines

Mittlerweile bietet fast jeder Cloud-Dienstleister wie AWS, Google Cloud oder Microsoft Azure die Möglichkeit, Deployment Pipelines zu erstellen. Aber auch mit Online-Repositories beziehungsweise Managed Repository Plattforms wie Github, Bitbucket oder Gitlab lässt es sich so zusammenarbeiten, dass eine kontinuierlichen Integration beziehungsweise eine kontinuierliche Auslieferung möglich ist. Auf diese Weise können Entwickler auf den mittlerweile als «klassisch» bezeichneten Ansatz mit CI-Tools wie Jenkins oder Travis verzichten.

Die Erstellung einer Code-Pipeline beinhaltet das Kompilieren und Testen des Projekts sowie die Installation auf dem Zielserver. Sauber geschriebene Pipelines erleichtern die Vorgänge auf allen Ebenen. Das Kredo von Joachim Jabs, Senior Technical Consultant bei bbv Deutschland, lautet deshalb: «Schreibe Pipelines stets so, als würdest du ‹normalen› Code schreiben.»

Die CI/CD-Pipeline vereinfacht zwar die Implementierung einer Software, doch müssen die entsprechenden Codes für alle entsprechenden Phasen sorgfältig geschrieben werden. Joachim Jabs hält die wichtigsten Ratschläge folgendermassen fest:

  • Benutze deskriptive Namen für Variablen, Jobs, usw.
  • Folge dem DRY-Prinzip (Don’t repeat yourself). Verwende dazu YAML Anchors und/oder Features der jeweiligen Pipeline, um zu vermeiden, dass einzelne, sich wiederholende Bereiche per Copy-and-Paste manuell dupliziert werden müssen. Dies vermindert die Fehleranfälligkeit und erhöht die Lesbarkeit.
  • Convention over Configuration: Beschreibe Namen, Funktionen, Templates usw. einheitlich. Damit kann man eine Vielzahl von Re-Deklarationen vermeiden und stattdessen Substitutionen verwenden. So kann die Komplexität gering gehalten werden.
  • Achte auf Sichtbarkeit von Variablen! Stelle sicher, dass Credentials innerhalb der Pipeline niemals sichtbar sind. In den meisten Tools gibt es die Möglichkeit, Variablen zu schützen (Vaults oder Protected Variables). Damit verhindert man, dass unberechtigte Personen Zugriff darauf erhalten. Man stelle sich zum Beispiel vor, man mache bei einer Pipeline zur Datenbankmigration die Zugangsdaten über die Variable sichtbar. Jeder, der Zugriff auf die Logs hat, könnte in die Ausgabe der Pipeline schauen und den Benutzernamen wie auch das Passwort kopieren. Auch Unbefugte erhielten so leicht Zugriff auf die Datenbank.
  • Halte die Abhängigkeiten so flach wie nur möglich und arbeite mit dem, was du hast. Jedes zusätzlich installierte Programmpaket kostet Zeit und kann unter Umständen das Risiko für Fehler und Sicherheitsprobleme erhöhen.
  • Teste deine Pipelines wenn möglich immer zuerst lokal. Achte darauf, dass du die gleiche Umgebung nutzt wie das CI/CD Tool.
  • Vermeide «unbestimmte» Zustände innerhalb der Pipeline. Stelle sicher, dass die einzelnen Schritte trotz Fehler, die nicht als solche erkannt werden, nicht durchlaufen.
  • Arbeite mit sinnvollen Standartwerten und Verhalten für alles, was konfiguriert werden kann oder voneinander abhängig ist.
  • Wenn zusätzliche Skripte benötigt werden, verwende keine positionellen Parameter, sondern immer benannte.
  • Räume hinter dir auf. Lösche nicht mehr benötigte Artefakte und Caches.

CI und CD helfen, die Softwarequalität zu verbessern. Voraussetzung dafür ist, dass sämtliche Entwickler dasselbe Repository verwenden, um ihre neuen Komponenten kontinuierlich zusammenzufügen. Auch Tester, Qualitätsmanager oder Business-Verantwortliche sollten Zugang zu dieser Quelle haben, um ausführbare Anwendungen zu prüfen oder sie demonstrieren zu können. Wichtig ist, dass die letzten Änderungen stets nachvollziehbar und aktuell sind.

Tipps vom Profi

Um die Pipelines möglichst nutzbringend zu erstellen, gibt Joachim Jabs weitere Ratschläge an Entwickler:

  • Erstelle zuerst ein Gerüst bzw. ein Mock, um die Logik abzubilden, bevor die tatsächlichen Befehle ausgeführt werden. Das geht relativ einfach, indem man mit echo, print oder anderen Ausgabeanweisungen die Pipeline modelliert (Dry runs).
  • Mit dem Befehl «envsubst» kann man Templates unter Shell machen – dies findet sich üblicherweise im «gettext»-Paket von fast jeder Distribution.
  • Mit YAML Anchors kann man sich das Schreiben von Skripten zum Behandeln von wiederholenden Aufgaben sparen. Variablen innerhalb dieser werden in der Regel erst zur Ausführungszeit interpretiert.
  • YAML kann Multiline. Nutze dies, um die Arbeitsschritte lesbarer zu gestalten. Wenn die Pipeline nicht in YAML ist, kann es auch sinnvoll sein, einen langen parametrisierten Befehl in einer Variablen zu speichern, um Zeilenumbrüche zu vermeiden.
  • CI/CD-Pipelines und ihre Laufzeitumgebungen haben meist ein sehr seltsames Verhalten, welches die Interpretation von Sonderzeichen und Sequenzen betrifft. Wenn mit regulären Ausdrücken oder anderen Formen von String-Manipulationen gearbeitet wird, stelle sicher, dass diese auch in der Pipeline funktionieren (Lokale Laufzeitumgebung).
  • Nutze Artefakte anstatt Caches, um innerhalb der CI/CD-Pipeline Daten auszutauschen, wenn die Pipeline keine Unterstützung zum Datenaustausch oder zur Variablenübergabe zwischen den Schritten erlaubt. Caches sind nicht verlässlich.
  • Vermeide XOR-Entscheidungen in Pipelines. Dies wird von den meisten Pipelines nicht sauber unterstützt. Wenn eine konditionelle Logik beim Deployment benötigt wird, überdenke den Workflow und vermeide Divergenz.

Der Experte

Joachim Jabs

Joachim Jabs ist Senior Technical Consultant in den Bereichen DevOps und Operations bei bbv Software Services in München. Seine Empfehlung: «Schreibt Pipelines so, als würdet ihr normalen Code verwenden.»

6 Tipps, wie Sie Ihr Team effizienter machen

Müde Augen ade: So helfen kurze Codezeilen

Agile
Effizienter dank Data Driven HR

HR-Digitalisierung auf den Menschen ausgerichtet

Agile Software Development
Standard- und Individualsoftware

Von Mythen umwoben

Agile Software Development

Artikel kommentieren

Attention!

Sorry, so far we got only content in English for this section.

Achtung!

Entschuldigung, bisher haben wir für diesen Abschnitt nur deutschsprachige Inhalte.

Attention!

Sorry, so far we got only content in English for this section.

Achtung!

Entschuldigung, bisher haben wir für diesen Abschnitt nur deutschsprachige Inhalte.