5 häufige Fallstricke von CI / CD - und wie man sie vermeidet

Devops mögen einer der dunstigsten Begriffe in der Softwareentwicklung sein, aber die meisten von uns sind sich einig, dass fünf Aktivitäten Devops zu dem machen, was sie sind: kontinuierliche Integration, kontinuierliche Bereitstellung, Cloud-Infrastruktur, Testautomatisierung und Konfigurationsmanagement. Wenn Sie diese fünf Dinge tun, machen Sie Devops. Natürlich sind alle fünf wichtig, um richtig zu liegen, aber allzu leicht, um falsch zu liegen. Insbesondere die kontinuierliche Integration und die kontinuierliche Bereitstellung (CI / CD) sind möglicherweise die am schwierigsten zu meisternden Schritte.

Continuous Integration (CI) ist ein Prozess, bei dem Entwickler und Tester gemeinsam neuen Code validieren. Traditionell haben Entwickler Code geschrieben und ihn einmal im Monat zum Testen integriert. Das war ineffizient - ein Fehler im Code von vor vier Wochen könnte die Entwickler dazu zwingen, den vor einer Woche geschriebenen Code zu überarbeiten. Um dieses Problem zu lösen, ist CI auf die Automatisierung angewiesen, um Code kontinuierlich zu integrieren und zu testen. Scrum-Teams verwenden mindestens täglich CI-Commit-Code, während die meisten von ihnen Code für jede eingeführte Änderung festschreiben.

Continuous Delivery (CD) ist der Prozess der kontinuierlichen Erstellung freisetzbarer Artefakte. Einige Unternehmen geben sie einmal oder sogar mehrmals täglich an Benutzer weiter, während andere die Software aus Marktgründen langsamer veröffentlichen. In jedem Fall wird die Freisetzungsfähigkeit kontinuierlich getestet. Dank Cloud-Umgebungen ist eine kontinuierliche Bereitstellung möglich. Server sind so eingerichtet, dass Sie sie für die Produktion bereitstellen können, ohne die Server herunterfahren und manuell aktualisieren zu müssen.

Somit ist CI / CD ein Prozess zur kontinuierlichen Entwicklung, zum Testen und zur Bereitstellung von neuem Code. Einige Unternehmen wie Facebook und Netflix verwenden CI / CD, um 10 oder mehr Veröffentlichungen pro Woche abzuschließen. Andere Unternehmen haben Schwierigkeiten, dieses Tempo zu erreichen, weil sie einer oder mehreren der fünf Fallstricke erliegen, die ich als nächstes erörtern werde.

CI / CD-Fallstrick Nr. 1: Automatisieren Sie zuerst die falschen Prozesse

Diese Falle trifft tendenziell Organisationen, die den Übergang von der Wasserfallentwicklung zu Entwicklern vollziehen. Neue Organisationen haben den Vorteil, CI / CD von Grund auf neu zu implementieren. Bestehende Unternehmen müssen schrittweise von der manuellen zur hochautomatisierten Entwicklung übergehen. Der vollständige Übergang kann mehrere Monate dauern, was bedeutet, dass Sie bei der Einführung von CI / CD iterativ vorgehen müssen.

Wenn Sie fragen: "Muss dies jetzt automatisiert werden?" Führen Sie die folgende Checkliste durch:

  1. Wie oft wird der Prozess oder das Szenario wiederholt?
  2. Wie lange dauert der Prozess?
  3. Welche Personen- und Ressourcenabhängigkeiten sind in den Prozess involviert? Verursachen sie Verzögerungen bei CI / CD?
  4. Ist der Prozess fehleranfällig, wenn er nicht automatisiert ist?
  5. Was ist die Dringlichkeit, um den Prozess zu automatisieren?

Mit dieser Checkliste können Sie die Schritte in einer CI / CD-Implementierung priorisieren. Automatisieren Sie in erster Linie den Prozess zum Kompilieren von Code. Im Idealfall integrieren Sie Code mehrmals pro Tag (1). Manuell dauert der Vorgang einige Minuten bis einige Stunden (2). Dadurch wird die Ausgabe blockiert, bis der Compiler die Aufgabe beendet hat (3). Es ist auch anfällig für menschliches Versagen (4), und da CI / CD ein Wunschtraum ohne automatisierte Integration ist, ist dies dringend erforderlich (5).

Wir können die gleiche Checkliste beim Testen ausführen. Beim Übergang zu CI / CD fragen Sie sich möglicherweise: Sollten wir zuerst Funktionstests oder UI-Tests automatisieren? Beide werden mindestens einmal pro Tag wiederholt (1). Beides kann für eine mittelgroße Anwendung zwei bis drei Stunden dauern (2). Sie beinhalten jedoch mehrere Abhängigkeiten (3). Wenn Sie Funktionstests automatisieren, müssen Sie das Automatisierungsskript möglicherweise nicht so häufig aktualisieren. Die Benutzeroberfläche hingegen ändert sich häufig und erfordert daher häufige Skriptänderungen. Obwohl beide fehleranfällig sind (4), sollten Sie Funktionstests vor dem Testen der Benutzeroberfläche priorisieren, um Ihre Ressourcen optimal zu nutzen (5).

Lassen Sie uns dies noch einmal mit dem Prozess des Einrichtens von Umgebungen tun. Dieses Szenario wird nur häufig wiederholt, wenn Sie sich auf einer Einstellungsreise befinden oder unter starker Abwanderung leiden (1). Es ist ein ziemlich zeitaufwändiger Prozess, der mehrere Stunden, wenn nicht Tage dauern kann (2). Neue Teammitglieder können ohne Umgebungen nichts Nützliches tun, daher besteht eindeutig eine Abhängigkeit und Verzögerung (3). Ich würde nicht sagen, dass der Prozess fehleranfällig ist (4), ist er also immer noch dringend (5)? Ich neige zu Ja, aber ich würde immer noch zuerst Integration und Funktionstests priorisieren.

Überautomatisierung gibt es nicht. Wenn Sie unbegrenzte Ressourcen hätten, würden Sie alles Mögliche automatisieren. Sie können jedoch keine vollständige Testautomatisierung erreichen. Manchmal können Sie Aufgaben in kleinere Segmente aufteilen und in Patches automatisieren. Manchmal sollten Sie den Prozess einfach detailliert dokumentieren und manuell ausführen.

CI / CD-Fallstrick Nr. 2: Verwirrende kontinuierliche Bereitstellung für kontinuierliche Bereitstellung

Kontinuierliche Bereitstellung ist das Konzept, dass jede in der Codebasis vorgenommene Änderung fast sofort in der Produktion bereitgestellt wird, wenn die Ergebnisse der Pipeline erfolgreich sind. Dies ist für die meisten Unternehmen erschreckend, da schnelle Produktänderungen Benutzer abschrecken können.

Unternehmen glauben, dass sie keine CD machen, wenn sie keine kontinuierliche Bereitstellung praktizieren. Sie unterscheiden nicht zwischen kontinuierlicher Bereitstellung und kontinuierlicher Bereitstellung.

Kontinuierliche Bereitstellung ist das Konzept, dass jede Änderung an der Codebasis die Pipeline bis zur Bereitstellung in Umgebungen ohne Produktion durchläuft. Das Team findet und behebt Probleme sofort und nicht später, wenn es plant, die Codebasis freizugeben.

Die Codebasis befindet sich immer auf einem Qualitätsniveau, das für die Freigabe sicher ist. Wann die Codebasis für die Produktion freigegeben werden soll, ist eine Geschäftsentscheidung.

Während die kontinuierliche Bereitstellung die meisten Unternehmen verunsichert, ist die kontinuierliche Bereitstellung bei ihnen sehr beliebt. Durch die kontinuierliche Lieferung haben sie die Kontrolle über Produkteinführung, Funktionalität und Risikofaktoren. Es ist Zeit für Alpha-Tests, für Beta-Kunden, für Early Adopters und so weiter.

CI / CD-Fallstrick Nr. 3: Mangel an aussagekräftigen Dashboards und Metriken

In CI / CD-Implementierungen kann das Scrum-Team ein Dashboard erstellen, bevor die Mitglieder wissen, was sie verfolgen müssen. Infolgedessen fällt das Team einem logischen Irrtum zum Opfer: „Dies sind die Metriken, die wir haben, also müssen sie wichtig sein.“ Führen Sie stattdessen eine progressive Bewertung durch, bevor Sie ein Dashboard entwerfen.

Verschiedene Mitglieder einer IT-Organisation und sogar verschiedene Mitglieder eines Scrum-Teams haben unterschiedliche Prioritäten. Zum Beispiel lieben die Leute in einem Network Operation Center (NOC) rote, gelbe und grüne Indikatoren. Mit solchen Ampel-Dashboards können NOC-Mitarbeiter Probleme unterscheiden, ohne dichten Text zu lesen oder ihre analytischen Fähigkeiten zu belasten. Ampeln helfen dabei, Hunderte von Servern verwaltbar zu machen.

Sie könnten versucht sein, ein Ampel-Dashboard auch für CI / CD zu verwenden. Grün, wir sind auf dem richtigen Weg. Gelb, wir sind nicht auf dem richtigen Weg, aber wir haben einen Plan, um das anzugehen. Rot, wir sind aus der Bahn geraten und müssen wahrscheinlich unsere Ziele ändern.

Dieses Dashboard ist wahrscheinlich für einen Scrum Master nützlich, aber was ist mit dem VP of Development oder dem CTO? Wenn ein Scrum-Team 350 Stunden Arbeit für einen zweiwöchigen Sprint vor sich hat und seine 10 Mitglieder jeweils 35 Stunden verantwortlich sind, erhalten sie eine entsprechende Anzahl von Story-Punkten. Das obere Management ist möglicherweise weniger am Status der Story Points interessiert und eher neugierig auf die Burndown-Rate: die Geschwindigkeit der Aufgabenerfüllung. Tragen Teammitglieder ihre Lasten? Wie schnell? Verbessern sie sich im Laufe der Zeit?

Leider können Burndown-Raten irreführend sein, wenn die verschiedenen Stakeholder die vereinbarten Gewohnheiten des Scrum-Teams nicht verstehen. Einige Teams verbrennen Punkte frühzeitig. Andere warten bis gegen Ende des Sprints, um offene Punkte niederzubrennen. Das Dashboard sollte dies berücksichtigen.      

Wenn Sie beurteilen können, welche Daten jeder möchte, und eine Standarderzählung für die Bedeutung dieser Daten erstellen können, können Sie ein nützliches Dashboard entwerfen. Aber sei nicht besessen von Substanz auf Kosten des Aussehens. Fragen Sie, wie die Stakeholder aussehen sollen. Wären Grafiken, Text oder Zahlen am besten?

Dies sind die Überlegungen, die in einer progressiven Bewertung untersucht werden müssen. Sie zeigen, wie schwierig es ist, ein nützliches CI / CD-Dashboard zu erstellen - und alle glücklich zu machen. Zu oft entführt das lautstärkste Teammitglied den Prozess, und andere sind frustriert, dass das Dashboard nur den Vorlieben einer Person entspricht. Hören Sie allen zu.  

CI / CD-Falle Nr. 4: Mangelnde Koordination zwischen kontinuierlicher Integration und kontinuierlicher Bereitstellung

Diese Falle führt uns zurück zu unserer Konsensdefinition von Devops, die besagt, dass kontinuierliche Integration und kontinuierliche Bereitstellung zwei verschiedene Punkte sind. CI füttert CD. Die Implementierung einer anständigen Pipeline für die kontinuierliche Integration und eines vollständigen Systems für die kontinuierliche Bereitstellung dauert Monate und erfordert die Zusammenarbeit. Qualitätssicherung, das Entwicklerteam, Ops-Ingenieure, Scrum-Master - alle müssen dazu beitragen. Der vielleicht schwierigste Aspekt von CI / CD ist dieser menschliche Faktor und nicht irgendeine technische Herausforderung, die wir besprochen haben. So wie Sie keine gesunde Beziehung zwischen zwei Personen programmieren können, können Sie die Zusammenarbeit und Kommunikation nicht automatisieren.

Um dieses Maß an Koordination zu messen, vergleichen Sie Ihren CI / CD-Prozess mit den besten in der Branche. Unternehmen wie Netflix können die Integration, das Testen und die Bereitstellung in zwei bis drei Stunden abschließen. Sie etablierten ein System, das Code ohne Unentschlossenheit und Diskussion von Hand zu Hand weitergibt. Nein, es ist nicht zu 100 Prozent automatisiert, da dies mit der aktuellen Technologie nicht möglich ist.

CI / CD-Fallstrick Nr. 5: Abwägen der Häufigkeit der Ausführung kontinuierlicher Integrationsjobs und der Ressourcennutzung

Kontinuierliche Integrationsjobs sollen für jede Änderung ausgelöst werden, die in den Code eingeführt wird. Erfolgreiche Jobs ermöglichen das Durchlaufen der Änderungen, während Fehler die Änderungen ablehnen. Dies ermutigt Entwickler, kleinere Codestücke einzuchecken, wodurch an einem Tag mehr Builds ausgelöst werden. Unnötige Jobs für die kontinuierliche Integration verbrauchen jedoch Ressourcen, was Zeit und Geld verschwendet.

Da dieser Prozess eine hohe Ressourcenauslastung (CPU, Leistung, Zeit) erfordert, sollte die Software in kleinere Komponenten unterteilt werden, um schneller laufende Pipelines zu erstellen. Oder die Jobs für die kontinuierliche Integration sollten für Batch-Check-Ins ausgelegt sein, die zuerst lokal getestet werden. Ziel ist es, ein Gleichgewicht zwischen der Häufigkeit der Ausführung kontinuierlicher Integrationsjobs und der Ressourcennutzung zu finden.

Behalten Sie das Ziel im Blick

Wenn wir uns mit den Fallstricken von CI / CD befassen - mit all seiner esoterischen Terminologie -, kann man leicht aus den Augen verlieren, warum dies wichtig ist. Letztendlich ist CI / CD wichtig, weil es die Geschäftsziele erfüllt.

Technologiemanager wissen, dass kontinuierliche Weiterentwicklung, schnelle Lösungen und Qualitätsergebnisse Kunden schaffen und binden. Sie wissen, dass eine fehlgeschlagene Version einen Knüppel zu App Store-Bewertungen einlädt, und es ist schwieriger, hohe Bewertungen wiederzugewinnen, als sie zu behalten. Devops schaffen möglicherweise eine bessere Arbeitserfahrung für Ihr Team, aber das ist nicht der Grund, warum Unternehmen Devops implementieren.

Einfach ausgedrückt, die Fallstricke von CI / CD sind eine Überprüfung wert, da Milliarden von Dollar auf dem Spiel stehen. Ich schlage zwar nicht vor, dass Sie Ihrem CI / CD-Dashboard einen Börsenticker oder einen App Store-Überprüfungs-Tracker hinzufügen, ich fordere Sie jedoch dringend auf, sich dessen bewusst zu bleiben. Viel hängt von den Minutien von CI / CD ab.

Zubin Irani ist Mitbegründer und CEO von cPrime, einem Full-Service-Beratungsunternehmen, das agile Transformationen implementiert und agile Lösungen für mehr als 50 Fortune 100-Unternehmen und viele der größten Arbeitgeber im Silicon Valley liefert.

Das New Tech Forum bietet einen Ort, an dem Sie neue Unternehmenstechnologien in beispielloser Tiefe und Breite erkunden und diskutieren können. Die Auswahl ist subjektiv, basierend auf unserer Auswahl der Technologien, die wir für wichtig und für die Leser von größtem Interesse halten. akzeptiert keine Marketingmaterialien zur Veröffentlichung und behält sich das Recht vor, alle eingebrachten Inhalte zu bearbeiten. Senden Sie alle Anfragen an [email protected]