CI / CD-Muster und Anti-Muster. Teil 1

Hallo allerseits! Freunde, am letzten Wintertag werden wir einen neuen Stream zum Kurs "DevOps-Praktiken und -Tools" starten. Im Vorgriff auf den Beginn des Kurses teilen wir Ihnen den ersten Teil des Artikels mit: „CI / CD-Muster und Anti-Muster“.



Die Bereitstellungspipeline-Aufgabe besteht aus drei Teilen:

• Sichtbarkeit: Alle Aspekte der Lieferkette - Erstellung, Bereitstellung, Test und Freigabe - sind für Teammitglieder sichtbar und erleichtern die Zusammenarbeit.
• Feedback: Teammitglieder informieren sich so schnell wie möglich über Probleme, damit sie so schnell wie möglich behoben werden können.
• Kontinuierliche Bereitstellung: Mithilfe eines vollautomatisierten Prozesses können Sie jede Softwareversion in jeder Umgebung bereitstellen und freigeben.

Im obigen Diagramm der Bereitstellungspipeline haben alle Muster einen Kontext. Einige Muster decken mehrere Phasen dieser Pipeline ab, daher habe ich die Phase ausgewählt, in der sie am häufigsten verwendet werden.

1.1 Konfigurationsmanagement - Muster und Anti-Muster

1.1.1 Benutzerdefinierte Software von Drittanbietern

• Muster: Evaluieren und verwenden Sie Software von Drittanbietern, die einfach konfiguriert, bereitgestellt und automatisiert werden kann.
• Anti-Pattern: Software, die nicht extern konfiguriert werden kann. Software ohne API oder Befehlszeilenschnittstelle, für die ein Befehl zur Verwendung einer GUI erforderlich ist.

1.1.2 Konfigurationsverzeichnis

• Muster: Unterstützung für einen Katalog aller Parameter jeder Anwendung, Möglichkeiten zum Ändern dieser Parameter und des Speicherorts jeder Anwendung. Automatische Katalogerstellung als Teil des Erstellungsprozesses.
• Anti-Patterns: Konfigurationsparameter sind nicht dokumentiert. Der Katalog aller Anwendungen und anderer Assets ist eine lokale, unbeschreibliche „Folklore“.

1.1.3 Hauptleitung

• Muster: Minimierung von Fusionen, Kontrolle der Anzahl der aktiven Codelines durch Arbeiten in der Mainline.
• Anti-Patterns: Mehrere Zweige pro Projekt.

1.1.4 Tägliche Zusammenführungen

• Muster: Änderungen, die in der Hauptzeile vorgenommen wurden, werden mindestens täglich auf alle Zweige angewendet.
• Anti-Patterns: Führen Sie alle Iterationen einmal pro Woche oder weniger als einmal pro Tag zusammen.

1.1.5 Sichere Konfiguration

• Muster: Speicherung von Konfigurationsinformationen an einem sicheren, remote zugänglichen Ort, z. B. in einer Datenbank, einem Verzeichnis oder einer Registrierung.
• Anti-Patterns: Öffnen Sie Textkennwörter und / oder einen Computer oder eine gemeinsam genutzte Ressource.

1.1.6 Repository

• Muster: Alle Quelldateien - ausführbarer Code, Konfiguration, Hostumgebung, Daten - werden mit Versionskontrolle in das Repository hochgeladen.
• Anti-Pattern: Einige Dateien werden komprimiert, andere, z. B. Umgebungskonfigurationen oder Datenänderungen, nicht. Binärdateien, die während des Erstellungs- oder Bereitstellungsprozesses neu erstellt werden können, werden eingecheckt.

1.1.7 Kurzlebige Zweige

• Muster: Zweige sollten kurzlebig sein, idealerweise mehrere Tage und nicht mehr als eine Iteration.
• Anti-Muster: Zweige, die länger leben als die Iteration. Zweige für die Funktionalität des Produkts, die nach der Veröffentlichung leben.

1.1.8 Teamumgebung

• Muster: Überprüfen Sie das Projekt-Repository mit Versionskontrolle und führen Sie einen einzelnen Befehl aus, um die Anwendung in einer verfügbaren Umgebung, einschließlich der lokalen Entwicklung, zu erstellen und bereitzustellen.
• Anti-Pattern: Der Entwickler muss Umgebungsvariablen definieren und konfigurieren. Erzwingen, dass der Entwickler viele Build- / Bereitstellungstools installiert.

1.1.9 Einweg zur Bedienung

• Muster: Verwalten der Konfiguration des gesamten Systems - Quellen, Konfiguration, Umgebung, Daten. Alle Änderungen können an einer bestimmten Revision im Versionskontrollsystem nachverfolgt werden.
• Anti-Patterns: Teile des Systems haben keine Version. Ein Rollback auf die vorherige System-Software-Einstellung ist nicht möglich.

1.2 CI Continuous Integration - Muster und Anti-Muster

1.2.1 Schwellenwert erstellen

• Muster: Die Assembly stürzt ab, wenn die Projektregeln verletzt werden. Zum Beispiel Architekturverletzungen, langsame Tests, Verstöße gegen Code-Schreibstandards.
• Anti-Patterns: Manuelle Codeüberprüfung. Erkennen von Problemen mit der Codequalität in späteren Phasen des Entwicklungszyklus.

1.2.2 Häufige Commits

• Muster: Jedes Teammitglied wird regelmäßig eingecheckt - mindestens einmal am Tag, idealerweise jedoch nach jeder Aufgabe, um das CI-System zu aktivieren.
• Anti-Patterns: Quelldateien werden aufgrund der Anzahl der vom Entwickler vorgenommenen Änderungen seltener als einmal am Tag festgeschrieben.

1.2.3 Kontinuierliches Feedback

• Muster: Automatisches Feedback vom CI-System an alle Mitglieder des funktionsübergreifenden Teams senden.
• Anti-Patterns: Benachrichtigungen werden nicht gesendet. Benachrichtigungen werden ignoriert; Das CI-System sendet Informationen an alle, die nicht verwendet werden können.

1.2.4 Kontinuierliche Integration

• Muster: Das Zusammenstellen und Testen der Software erfolgt nach dem Festschreiben von Änderungen am Projekt-Repository mit Versionskontrolle.
• Anti-Patterns: Geplante Baugruppen, nächtliche Baugruppen, regelmäßige Baugruppen, Baugruppen ausschließlich auf dem Computer des Entwicklers, völliger Mangel an Baugruppen.

1.2.5 Das Prinzip der „Stop Line“

• Muster: Reparieren Sie alle Fehler bei der Softwarebereitstellung, sobald sie auftreten. "Stoppen Sie die Leitung". Niemand checkt eine defekte Baugruppe ein, da deren Behebung die höchste Priorität hat.
• Anti-Pattern: Assemblys bleiben lange Zeit defekt, wodurch Entwickler daran gehindert werden, Arbeitscode zu überprüfen.

1.2.6 Unabhängige Versammlung

• Muster: Build-Skripte werden geschrieben, die von der IDE getrennt sind. Diese Skripte werden vom CI-System ausgeführt, sodass die Assembly bei jeder Änderung ausgeführt wird.
• Anti-Patterns: Auto-Builds hängen von der IDE-Konfiguration ab. Die Montage kann nicht über die Befehlszeile gestartet werden.

1.2.7 Sichtbare Dashboards

• Muster: Es ist möglich, alle Informationen zu Ihrem Liefersystem anzuzeigen. Bereitstellung eines qualitativ hochwertigen funktionsübergreifenden Team-Feedbacks in Echtzeit.
• Anti-Patterns: Benachrichtigungen werden nur per E-Mail gesendet. Feedback wird nicht für das gesamte Team veröffentlicht.

Das Ende des ersten Teils.

Hier ist so ein Material. Sie können die Fortsetzung der Übersetzung hier lesen. Jetzt warten wir auf Ihre Kommentare und laden Sie zu einem offenen Webinar ein , das heute Abend stattfinden wird.