Kontinuierliche Integration mit kontinuierlicher Lieferung verbinden

Bei XebiaLabs erhalten wir viele Fragen zu unserer Automatisierungslösung für die Unternehmensbereitstellung , Deployit, von Benutzern, die eine automatisierte Bereitstellung als Voraussetzung für Continuous Delivery wünschen. Oft ist dies das Ergebnis von Initiativen zur Erweiterung bestehender Continuous Integration-Tools, um Anwendungsbereitstellungen zu unterstützen. Die Erhöhung der Häufigkeit von Anwendungstests, die Verkürzung der Zeit bis zur Produktivsetzung und die schnellere und regelmäßigere Bereitstellung eines größeren Geschäftswerts sind Ziele, die wir definitiv teilen, und in diesem Beitrag möchten wir einige wichtige Erfahrungen und Lektionen aus der Zusammenarbeit mit unseren Anwendern weitergeben, um ihnen bei der Realisierung von Continuous Delivery zu helfen.

Erweiterung der fortlaufenden Integration

Für viele Unternehmen sind Tools für die kontinuierliche Integration (Continuous Integration, CI) die offensichtliche "Basisplattform", auf der sie ihre Automatisierungssuite für Continuous Delivery (CD) aufbauen. Oft ist CI bereits etabliert und in Betrieb, z.B. als Teil der Einführung agiler Entwicklungsmethoden.Selbst wenn Sie sich erst jetzt mit CI beschäftigen, ist es ein guter Ausgangspunkt für CD-Bemühungen: eine Lieferpipeline beginnt in der Regel mit dem Code, und genau hier setzt Continuous Integration an. Praktischerweise ist sie auch die etablierteste Komponente einer "Continuous Delivery-Toolsuite", für die eine Vielzahl von in Unternehmen bewährten, funktionsreichen Produkten zur Verfügung steht.

Von der kontinuierlichen Integration zur kontinuierlichen Bereitstellung

Der erste wichtige Punkt bei der Einführung von CD ist, dass es mehr ist als "nur ein Tool". Wie bei Agile oder Devops handelt es sich bei Continuous Delivery um eine Reihe von Grundsätzen und Prozessen und, was noch grundlegender ist, um eine Denkweise, deren Umsetzung Anstrengung, Veränderung und Akzeptanz erfordert.

Für den langweiligen "technischen" Teil von CD ist jedoch ein gewisses Tooling erforderlich: kontinuierliche Integration, Automatisierung der Bereitstellung, automatisierte Tests. Da immer mehr Unternehmen ihre privaten oder hybriden Clouds einführen wollen, werden auch Tools für die automatisierte Bereitstellung und das Konfigurationsmanagement immer wichtiger.Aufgrund der relativ großen Anzahl von Plugins für etablierte Testtools ist es relativ einfach, automatisierte Funktions-, UI- oder Leistungstests mit Ihren Continuous Integration Builds zu verknüpfen - die Herausforderung besteht eher darin, die Tests zu schreiben und sicherzustellen, dass Ihre Anwendung auf automatisierte Weise getestet werden kann.Für die Bereitstellungsautomatisierung gibt es jedoch nur wenig, was den Anforderungen einer Unternehmensumgebung entspricht. Dies ist der Grund für die häufigen Kundenanfragen und wir hoffen, dass unsere Zusammenarbeit mit den führenden Anbietern von KI - CloudBees, dem Unternehmen hinter Jenkins Enterprise, Atlassian und ThoughtWorks - dazu beitragen kann, diese Situation zu verbessern.Eine Ausweichmöglichkeit war schon immer der "Alleingang", das Schreiben eigener Deployment-Skripte und das Einbinden dieser Skripte in Ihre KI-Tools. Wenn es bereits eine Vielzahl von Skripten gibt, die nur geringfügige Änderungen erfordern, kann dies ein nützlicher erster "Quick Win" sein. Aus strategischer Sicht lohnen sich jedoch die laufenden Kosten, die mit der Pflege benutzerdefinierter Skripte und deren Erweiterung zur Unterstützung neuer Technologien und Umgebungen wie der Cloud verbunden sind, so dass es sich lohnt, dedizierte Lösungen zu evaluieren.

Vorbereitungen für Continuous Delivery

Ausgehend von unserer Erfahrung bei der Unterstützung von Unternehmen bei der Ausweitung von Continuous Integration auf Continuous Delivery, stellen wir Ihnen hier vier der häufigsten Punkte vor, die Sie beachten sollten: 1. Was gehört zu unseren Bereitstellungspaketen?

• Eine Anwendung besteht aus mehr als nur kompiliertem Code oder Binärdateien! Denken Sie an Konfigurationsdateien, Datenbankänderungen und Konfigurationseinstellungen oder Ressourcen, die in der Ziel-Middleware-Umgebung erstellt werden müssen.
• Kann ich alle Komponenten zum Zeitpunkt der Integration sammeln, um mein Bereitstellungspaket automatisch vorzubereiten? Kann ich Datenbankskripte oder Konfigurationsspezifikationen aus einem Repository abrufen?
• Eine nützliche Testfrage: Wenn ich mein Bereitstellungspaket auf einer frischen "Vanilla-Middleware-Installation des Unternehmens" einsetze, habe ich dann alle Komponenten und Einstellungen, die ich brauche?

2. Wie werden wir mit umgebungsspezifischen Konfigurations- und Bereitstellungsaktionen umgehen?

• Die Cloud macht es möglich, mehrere identische ^1-Umgebungen parallel laufen zu lassen, aber im Moment erfordern die meisten Unternehmensimplementierungen umgebungsspezifische Einstellungen und Implementierungen: unterschiedliche Datenbankbenutzernamen und Passwörter oder die Implementierung aller Komponenten in einem einzigen Cluster in Dev im Gegensatz zu Sets von Komponenten in verschiedenen Clustern für Q&A oder Production.
• Separate CI-Aufgaben für jede Umgebung, um diese Unterschiede zu behandeln, führen zu übermäßiger Duplizierung und Verwaltungsaufwand. Außerdem können dadurch sensible Informationen, die vor den Entwicklern und anderen Personen mit Zugriff auf den Build verborgen bleiben sollten, in den CI-Prozess gelangen.
• Streben Sie ein einziges CI-Build an, das Ihr "Goldstandard"-Einsatzpaket liefert, das zum Zeitpunkt des Einsatzes an die Zielumgebung angepasst werden kann (z. B. mithilfe von Konfigurationsdateien mit Platzhaltern). Umgebungsspezifische Bereitstellungsaktionen (z.B. für unterschiedliche Größenordnungen von Umgebungen) sollten von der Automatisierungskomponente für die Bereitstellung übernommen werden.

3. Wie ordnen wir die Phasen in unserer Pipeline den CI-Aufgaben/Jobs zu?

• Die meisten CI-Tools ermöglichen Ihnen sowohl das Hinzufügen zusätzlicher Aktionen zu einer Aufgabe/einem Job als auch die Definition einer "Aufgaben-/Job-Kaskade", bei der jede Aufgabe durch den Abschluss der vorhergehenden ausgelöst wird. Sie können also im Extremfall eine Aufgabe mit vielen Aktionen haben, die die gesamte Pipeline repräsentiert, oder eine Kaskade von vielen sehr kurzen Aufgaben.
• Wenn Sie die Pipeline in eine Kaskade aufteilen, bleibt die Konfiguration der einzelnen Aufgaben kleiner und fokussierter. Außerdem ist es so einfacher, nur diesen Teil der Pipeline auszuführen, was insbesondere für Tests und Verfeinerungen nützlich ist.
• Die Definition von fokussierteren Aufgaben führt jedoch zu viel mehr Aufgaben in Ihrer CI-Installation, so dass Sie Sortier-, Filter- oder andere Funktionen zur Verwaltung von Unternehmensdaten in Ihrem CI-Tool benötigen.
• Nützliche "Brocken", die Sie berücksichtigen ^sollten2:
  • erstellen, testen und verpacken
  • einsetzen und überprüfen
  • Integrations-/Leistungs-/Funktionstests
  • Abriss/Aufräumarbeiten

4. Wie integrieren wir das Release Management?

• Je länger die Pipeline wird, d.h. je weiter sie sich in Richtung Q&A und Produktion bewegt, desto wahrscheinlicher werden Sie an Punkte gelangen, an denen eine Genehmigung des Release Management (RM) erforderlich ist, um fortzufahren.
• Die Interaktion zwischen Release Management und Continuous Delivery geht mindestens in beide Richtungen: RM-Aktionen können Pipeline-Stufen auslösen, während CD-Aktionen RM-Verifizierungen auslösen können.
• Wenn Sie zum Beispiel eine Änderungsanforderung auf Genehmigt setzen, kann dies automatisch einen Bereitstellungs- und Testzyklus auslösen. Ebenso kann eine durch erfolgreiche Funktionstests ausgelöste Bereitstellung in der Q&A-Umgebung automatisch überprüfen, ob die RM-Genehmigung erteilt wurde, indem eine Änderungsanforderung validiert wird.