Gehen Sie, bevor Sie laufen: CI in CD verstehen

Mit dem Trubel herum Kontinuierliche Lieferung (CD) Heutzutage mag es wie eine antiquierte Vorstellung erscheinen, überhaupt darüber zu sprechen, geschweige denn darüber zu schreiben Kontinuierliche Integration (CI). In den vielen Gesprächen, die wir mit Organisationen geführt haben, die CD implementieren möchten oder sich mitten in der Umsetzung befinden (und dabei stolpern), ist uns jedoch klar geworden, dass es eine große Kluft gibt, die in den grundlegenden Aspekten überbrückt werden muss die den Wunsch einer Organisation unterstützen, CD einzuführen. CI ist ein wichtiges unterstützendes Konstrukt, dessen Prinzipien immer noch nicht hinreichend klar verstanden/umgesetzt werden und daher einen erneuten Blick wert sind.

Kontinuierlich…

Integration ist der Prozess, schnelles, automatisiertes Feedback zu erhalten Richtigkeit Ihrer Anwendung jedes Mal, wenn sich der Code ändert.

Lieferung baut auf dem früheren Konzept auf, indem es schnelles, automatisiertes Feedback dazu liefert Richtigkeit und Produktionsbereitschaft Ihrer Bewerbung jedes Mal, wenn sich etwas ändert Code, Infrastruktur oder Konfiguration.

Die Prämisse hinter CD ist, dass Software immer einsetzbar ist. Hmm. Klingt bekannt. Hat jemand in letzter Zeit einen Blick auf die Prinzipien hinter dem Agilen Manifest geworfen? Das allererste Prinzip lautet:

„Unsere höchste Priorität ist es, den Kunden zufrieden zu stellen – durch frühzeitige und kontinuierliche lieferung – von wertvoller Software.“

Es scheint, dass es sich bei der CD weniger um eine neumodische Idee handelt, sondern vielmehr um die Verwirklichung eines seit langem bestehenden Versprechens. Und die wichtigsten Voraussetzungen zur Verwirklichung dieses Ideals sind:

• Kontinuierliche Integration
• Umfassendes Konfigurationsmanagement
• Mehrstufige automatisierte Tests

Der Rest des Beitrags geht etwas tiefer auf den CI-Aspekt von CD ein.

Kontinuierliche Integration

CI ist der Prozess der Ausführung des Software-Builds.Deploy-Testzyklus (BDT) häufig mit minimalem manuellen Eingriff, wobei das Grundprinzip der ständigen Kommunikation und des Feedbacks zwischen den Teammitgliedern zugrunde liegt. Martin Fowler, ein bekannter Autor und Redner zu Softwareentwicklungsthemen, beschreibt es als:

„…eine Softwareentwicklungspraxis, bei der Mitglieder eines Teams ihre Arbeit häufig integrieren, normalerweise integriert jede Person mindestens täglich – was zu mehreren Integrationen pro Tag führt.“ Jede Integration wird durch einen automatisierten Build (inkl. Test) verifiziert, um Integrationsfehler schnellstmöglich zu erkennen. Viele Teams stellen fest, dass dieser Ansatz zu deutlich geringeren Integrationsproblemen führt und es einem Team ermöglicht, zusammenhängende Software schneller zu entwickeln.“

Wenn es wehtut, bringen Sie den Schmerz nach vorne

CI bietet einen Rahmen für die schnelle Erkennung von Software-Integrationsfehlern und ermöglicht es Teams, einheitliche Software schneller zu entwickeln und gleichzeitig die gefürchteten „Big Bang“-Integrationen und die damit verbundene Code-Merge-Misere zu lindern, unter der viele Software-Teams leiden. CI zielt darauf ab, Integrationsunsicherheiten zu beseitigen, indem es Entwickler dazu ermutigt, die häufige Integration ihrer Arbeit in die tägliche Entwicklungsaktivität zu integrieren. Dadurch entfällt nicht die herausfordernde Aktivität der Codezusammenführung und Konfliktlösung – es reduziert den mit seltenen Zusammenführungen verbundenen Aufwand erheblich, indem täglich kleine, inkrementelle Zusammenführungen gefordert werden. Es tauscht schwächenden Schmerz später gegen etwas Schmerz heute ein.

Wie verändert es, was der Entwickler täglich tut?

CI ist eine Denkweise, und obwohl der Prozess manuell ausgeführt werden kann, verwenden die meisten Teams ein Tool, um die Disziplin durchzusetzen. Die folgende Abbildung zeigt den typischen Integrationszyklus im Zusammenhang mit der Verwendung eines solchen Tools – eines CI-Servers – zur Unterstützung der Implementierung der Praxis.

• Der Tag beginnt damit, dass der Entwickler die neueste Codebasis aus dem Quellcodeverwaltungs-Repository abruft
• Dann gibt es noch die typische Entwicklungsaktivität (vorzugsweise geleitet durch automatisierte Unit-Tests).
• Der Entwickler ist bereit, Code in das Repository zu übertragen, und muss möglicherweise die Absicht dem Team mitteilen
• Aktualisiert die lokale Arbeitskopie mit Code aus dem Repository (da andere möglicherweise den Codestream aktualisiert haben)
• Führt Code zusammen und löst alle Konflikte lokal
• Erstellt und stellt sicher, dass Tests lokal bestanden werden
• Überträgt Code in das Repository
• Der CI-Server „horcht“ auf Änderungen im Code-Repository. Jede Änderung löst automatisch den Build- und Testzyklus aus und die Ergebnisse werden den Teammitgliedern automatisch mitgeteilt. Ein fehlerhafter oder „roter“ Build (entweder aufgrund von Kompilierungs- oder Testfehlern) weist auf einen Integrationsfehler hin und sollte sofort behoben werden. Die CI-Umgebung auf „grün“ zu bringen, sollte die oberste Priorität des Entwicklers/Teams sein.

Wo fangen wir da an?

Wie aus der Beschreibung des Produkts des Integrationszyklus hervorgeht, erfordert die Einführung von CI bestimmte Praktiken, die notwendig sind, um CI möglich und wirksam zu machen.

Single-Source-Repository

Alle Quellcodedateien, Datenbankskripte, abhängigen Bibliotheken und Eigenschaftsdateien, die zum Erstellen der bereitstellbaren Softwareartefakte erforderlich sind, müssen in einer Art Quellcodeverwaltungssystem versioniert werden, da der CI-Server Änderungen am Code-Repository überwacht, um den BDT-Zyklus auszulösen. So rudimentär diese Einschränkung auch erscheinen mag, es gibt immer noch einige Organisationen, die noch nicht den Reifegrad erreicht haben, bei dem eine zentrale Quellcodeverwaltung und Versionsverwaltung eine Selbstverständlichkeit ist.

Build-Automatisierung

Selbst wenn eine zentrale Quellcodeverwaltung vorhanden ist, verlassen sich viele Organisationen noch immer auf manuelle Prozesse, um bereitstellbare Softwareartefakte zu erstellen, die eine Koordination zwischen organisatorischen Silos und Teammitgliedern erfordern. Da die Prämisse von CI darin besteht, einen Build ohne menschliches Eingreifen zu starten, ist die Erstellung einer Build-Funktion mit nur einem Klick erforderlich, um den BDT-Zyklus zu automatisieren. Die Faustregel für die Build-Automatisierung besteht darin, ein lauffähiges System von Grund auf aufsetzen zu können.

Testautomatisierung

Obwohl dies keine Voraussetzung ist, Testautomatisierung spielt eine Schlüsselrolle dabei, dem Team verlässliches Feedback zu geben, dass die Softwarekomponenten nicht nur integriert sind, sondern auch ordnungsgemäß funktionieren. Lassen Sie nicht zu, dass die Testautomatisierung den Übergang zu CI behindert, aber es ist am besten, nicht zu lange mit der Einführung automatisierter Tests in den Mix zu warten, um die Vorteile der Praxis wirklich zu nutzen.

Was sind einige der „Best Practices“?

•  Häufige Commits an einen gemeinsamen Code-Stream
• Commits in einen „kaputten“ Build nicht zulassen
• Ein „kaputter“ CI-Build sollte sofort behoben werden und seine Behebung sollte höchste Priorität haben
• Beheben Sie lang laufende Builds. 10-15 Minuten sind ideal; Mehr als 20–30 Minuten sind die äußere Grenze für eine sinnvolle häufige Integration. Je kürzer der Zyklus, desto besser. Der wahrscheinlichste Schuldige könnten Integrationstests sein, die sich als Unit-Tests ausgeben. Stellen Sie die Builds bei Bedarf bereit.
• Erstellen Sie die Datenbank neu (Build from Zero)
• Erstellen/Bereitstellen/Testen auf einer produktionsähnlichen Plattform
• Bieten Sie der Qualitätssicherung die Möglichkeit, gezielte Builds in Umgebungen auf höherer Ebene bereitzustellen.

Was sind einige der Missverständnisse?

CI ist das Gleiche wie der Nightly Build

Nicht wahr. Ein nächtlicher Build erzeugt Software-Artefakte für den externen Gebrauch, z. B. für QS-Funktionstests, Produktüberprüfungen usw. XP hat das Konzept eines nächtlichen Builds auf die Spitze getrieben, indem es häufige Kontrollpunkte für die Codesynchronisierung innerhalb eines Tages als Mittel für einen Entwickler vorschlägt mit dem System zu kommunizieren, um sicherzustellen, dass er/sie zumindest vorerst seinen/ihren Beitrag geleistet hat. Das heißt nicht, dass der nächtliche Build keinen Wert hat, und tatsächlich könnte CI verwendet werden, um ihn stufenweise zu generieren.

Wir sind nicht agil, also machen wir kein CI

Während der Begriff „kontinuierliche Integration“ von Extreme Programming (XP) eingeführt wurde, stammt das zugrunde liegende Konzept einer häufigeren Integration aus der Zeit vor XP. Tatsächlich ist CI eine der am wenigsten umstrittenen Praktiken von XP, und ihre Leitprinzipien sind relevant, unabhängig davon, ob eine Organisation Agilität eingeführt hat oder nicht.

Häufig Deployment Disruptiv

Die Einführung von CI bedeutet nicht zwangsläufig eine automatische Bereitstellung jedes „grünen“ Builds in Umgebungen höherer Ebene, ob angefordert oder nicht. Eine gute CI-Implementierung sollte die Möglichkeit bieten, dass QA oder andere Teammitglieder gezielte Builds auf dem CI-Server nach Bedarf in anderen Umgebungen bereitstellen können.

Im Automatisierung für die Menschen In der Serie listet Paul Duvall einige gängige CI-Antimuster und Missverständnisse auf und wie man sie vermeidet.

Fazit

Der größte Vorteil von CI ist das geringere Risiko. Zu oft treten die Probleme mit verzögerter und seltener Integration im späteren Teil des Projekts auf, wenn viel auf dem Spiel steht und der Druck zur Lieferung am größten ist. Darüber hinaus ebnet es den Weg für die Automatisierung auf vielen Ebenen, angefangen bei der Build-Automatisierung, der Testautomatisierung und in jüngster Zeit auch bei Continuous Delivery/Continuous Deployment, die alle darauf abzielen, die Schaffung von höherwertige Software, Schneller.

Referenzen

• http://martinfowler.com/articles/continuousIntegration.html
• http://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html
• Kontinuierliche Integration: Verbesserung der Softwarequalität und Reduzierung des Risikos – Duvall, P & Matyas, S & Glover, A
• Continuous Delivery: Zuverlässige Software Releases durch Build, Test und Deployment-Automatisierung – Humble, J & Farlay, D