Ehe ein Software-Unternehmen nicht eine stabile, verlässliche Continuous-Integration-Umgebung hat und es keine Kultur gibt, diese effektiv zu nutzen, kann der Schritt hin zu Continuous Delivery eine schmerzhafte Verschwendung von Zeit und Ressourcen sein. Um die Voraussetzungen für eine erfolgreiche CD-Adaption zu schaffen, ist die Implementierung eines stabilen und zuverlässigen CI-Prozesses nötig.

Continuous Delivery erfordert, dass die Software-Release-Infrastruktur – wie der Name schon sagt – kontinuierlich genutzt wird. Wenn die CI-Infrastruktur, auf die die CD-Prozesse aufgebaut werden, eilig zusammengeworfen wurde, geht die Organisation das Risiko ein, dass Teile davon versagen. Und anders als bei traditionellen Release-Modellen, wird hier das Unternehmen in all seinen Teilen beeinträchtigt, wenn die Infrastruktur streikt.

In einem eher Wasserfall-artigen Release-Modell ist genug Zeit und Luft, um einen gecrashten CI-Server neu zu starten, um Artefakte hin und her zu bewegen, weil der Dateiserver wieder gefüllt ist, oder um sich als Release-Manager in jeden einzelnen Slave einzuloggen und jenes Package zu installieren, das ein Entwickler während einer Debugging-Session nur auf einem der Slaves installiert hat. Wenn dagegen das CD-Modell zur Anwendung kommt, sprengen solche Probleme die Pipeline für alle – von den Entwicklern, die committen, bis zu den Kunden, die die neuen Programmpakete nicht erhalten. Über das gesamte Unternehmen hinweg werden die Auswirkungen unangenehm spürbar.

Master und Slaves

Wenn wir die Verlässlichkeit der CI-Infrastruktur sicherstellen wollen, besteht der erste Schritt darin, uns ihre konstituierenden Bestandteile anzuschauen: den Master-CI-Server und die Slaves, die die Arbeit tun. Vorausgesetzt, wir bauen unsere CD-Pipelines intern auf, wird uns die Beantwortung der folgenden Fragen Einsichten im Hinblick auf den derzeitigen Status unserer CI-Infrastruktur bieten.

Für den Master:

• Unterliegt die Maschinenkonfiguration einem automatisierten Konfigurationsmanagement (CFEngine, Chef, Puppet etc.), sodass sie auf eine komplett automatisierte Weise von Grund auf wiederaufgebaut werden kann? Kann dieser Prozess selbständig ablaufen oder erfordert er Downloads (Plugins usw.) von externen Websites? Wie lange würde ein Wiederaufbau dauern?
• Sind die Daten, die im CI-Master enthalten sind, anderswo verfügbar? Gibt es Objekte wie Build-Logs (speziell für ausgelieferte Builds), Artefakte, Testergebnisse und andere wiederherstellbare Build-Metadaten oder wären so wichtige Daten wie Build-Nummern verloren, wenn der Master weg ist?
• Gibt es eine Zugangskontrolle für die Systemkonfiguration des Master-Servers oder kann sich jeder einloggen und alles ändern? Wie ist das bei den individuellen Job-Konfigurationen? Wenn etwas geändert wird, gibt dann einen Audit-Trail? Werden Stakeholder informiert?
• Werden die Job-Konfigurationen im CI-Tool selbst versionskontrolliert oder spezifiziert? Werden Job-Konfigurationsänderungen irgendwo dokumentiert?

Für die Slaves:

• Unterliegen die Slaves einem automatisierten Konfigurationsmanagement, sodass sie auf automatisierte Weise wiederhergestellt werden können – und zwar für alle unterstützten Plattformen?
• Wer kann sich in die Slaves einloggen? Sehen Slaves nach dem Login "schmutzig" aus, und wenn ja, was passiert dann mit ihnen?

Diese Fragen mögen sich trivial anhören, aber es ist nach wie vor häufig zu beobachten, dass Jobs auf bestimmten Slaves nicht funktionieren, auf anderen dagegen schon. Oder Entwickler fordern Login-Zugriff an und nehmen Konfigurationsänderungen vor, die dann nicht in den Build-Umgebungsprozess für die Build-/Release-Teams oder nicht mal auf der lokalen Maschine des Entwicklers integriert werden.

Eine weitere wichtige Frage, die sowohl für den Master als auch für die Slaves gilt, lautet: Wer ist verantwortlich für die Wartung der Maschinen, die die CI-Infrastruktur bilden, und wer nimmt Backups kritischer Daten vor? Oftmals fällt dies einem separaten IT-Team zu. Hier ist Vorsicht vor gegensätzlichen Anforderungen geboten. Wer auch immer die Funktion ausfüllt: Er muss unbedingt Teil der Kommunikationsschleife mit den CI-Tool-Administratoren und den Usern sein.

Zu einer recht guten Einschätzung des Zustands der CI-Infrastruktur gelangen wir, wenn wir diese Fragen durchdenken: "Angenommen, wir haben uns entschieden, die CI-Tools zu wechseln. Wie lange würde es dauern, die gesamte Konfiguration umzuziehen? Und könnten wir all die Metadaten, Logs, Artefakte und anderen Informationen über frühere Builds, die uns interessieren, wiederherstellen?" Wenn die Antworten "lange" und "nein" lauten, besteht Handlungsbedarf. Und in der Praxis dürfte das angesichts ständig wechselnder Teammitglieder (und Meinungen) sowie neuer Tools oft der Fall sein.

Organisationen, die Cloud-basierte CI-Dienste nutzen, könnten meinen, dass diese Fragen und Probleme sie nicht zu interessieren brauchen. Aber es ist nicht ungewöhnlich, dass Unternehmen, die wachsen oder sich auf sonstige Weise verändern, ihre CI-Funktionalitäten in andere Cloud-Infrastrukturen verlagern – beispielsweise um von Großkunden-Tarifen zu profitieren oder eine Private Cloud aufzubauen. Manchmal führt der Bedarf an schnelleren Builds dazu, dass die CI-Infrastruktur doch wieder intern oder direkt auf der Hardware implementiert werden muss. Das ist definitiv ein Wechsel der CI-Tools, und diese Unternehmen müssen sich mit den Überlegungen oben auseinandersetzen. Es zahlt sich aus zu wissen, wie die Cloud-basierten CI-Agents konfiguriert sind.

Im zweiten Teil des Artikels geht es darum, was andere beteiligte Teams (z.B. Release-Management und QS) tun können, um den CI-Prozess optimal aufzusetzen. 

Kennen Sie Codeyard?

Das ist unsere neue Atlassian-basierte Tool-Suite für Software-Entwicklungsteams, eine professionelle Lösung für das schnelle Aufsetzen einer passgenauen Infrastruktur als Grundlage für einen effektiven und effizienten Software-Entwicklungsprozesses – von der Idee bis zum auslieferbaren Produkt. Hier gibt es weitere Infos zu Codeyard.

Weiterführende Infos

Warum Git so gut für den CD-Prozess ist
Continuous Delivery in der Praxis: Deployment auf Knopfdruck und Release-Verwaltung mit Bamboo
Individuelle Software-Entwicklung: Workflows, Branching-Modelle und Continuous Delivery
Der Continuous-Delivery-Workflow für SaaS- und für installierte Software-Produkte
Der Continuous-Delivery-Workflow für Gitflow-Projekte