Variable Toolchain für Entwicklungsteams
In der Softwareentwicklung dominieren Tools den Alltag, die kaum miteinander integriert sind. Das führt insbesondere in großen Entwicklungsabteilungen zu hohen Administrationskosten, erschwert automatisierte Prozesse und schränkt die Agilität der Teams ein. Die Alternative zu den üblichen Toolboxes sind zentral bereitgestellte, hoch integrierte Entwicklungsplattformen. Diese ermöglichen Automatisierung, schnelle Bereitstellung der benötigten Tools und Skalierung. Sie erlauben also die Entwicklung von Software nach modernen Maßstäben.
Automatisierung, ein hoher Standardisierungsgrad und Arbeitsteilung sind die Grundsätze, die sich in der industriellen Fertigung seit vielen Jahrzehnten bewährt haben. In der Softwareentwicklung werden diese erprobten und über die Zeit verfeinerten Elemente nach und nach im Rahmen der digitalen Transformation aufgenommen und in agile Ansätze integriert. Vordenker wie Martin Fowler fordern nicht umsonst ein hohes Maß an Automatisierung, etwa durch Continuous Integration/Continuous Deployment (CI/CD). Das Ziel dabei ist nicht zuletzt, die Qualität der Software zu verbessern und gleichzeitig die Time to Market zu verkürzen. Das Agile Manifest dreht sich letztlich um diese beiden Aspekte und fordert, funktionierende Software in möglichst kurzer Zeit auszuliefern – und dabei den Nutzen für die Anwender im Fokus zu haben. Auf Prozess- und Organisationsseite haben sich Scrum und DevOps etabliert, diese Ziele zu erreichen. Die Marktforscher von IDC konstatieren zum Beispiel, dass 67 Prozent der Unternehmen weltweit DevOps-Praktiken in der einen oder anderen Form implementiert haben [1].
DevOps ist, wie auch viele agile Methodiken, sehr vielschichtig. Wie die Herangehensweise konkret auf Entwicklungsprojekte angewandt wird, ist nicht festgelegt. So geben DevOps und agile Methoden Empfehlungen zu Prozessen, wobei es keinerlei Vorgaben zu deren Umsetzung mit Hilfe von Tools gibt. Über die letzten Jahre haben sich zwei unterschiedliche Ansätze bei Unternehmen herauskristallisiert. Auf der einen Seite finden sich mehr oder weniger lose Tool-Sammlungen, meist auf der Basis von Open-Source-Angeboten. Auf der anderen Seite stehen properitäre, integrierte Entwicklungsumgebungen aus einer Hand. Der Ansatz, eine Open-Source-Sammlung zusammenzustellen, hat sicher Vorteile. Die Toolbox ist flexibel, für jede Komponente der Toolchain gibt es am Markt Alternativen. Dem gegenüber steht der sehr große administrative Aufwand, die Insellösungen zu einer Gesamtplattform zu integrieren, wie es für automatisierbare Entwicklungsprozesse wichtig ist. Kommerzielle Komplettsysteme wiederum sind oft nicht flexibel, einzelne Komponenten lassen sich nicht bei Bedarf austauschen und sie sind mit nicht unerheblichen Lizenzkosten verbunden. Die Unternehmen machen sich zudem von einem Anbieter abhängig – es droht der bekannte Vendor-Lock-In.
Die Integration der verschiedenen Tools zu einer einheitlichen Entwicklungsinfrastruktur ist nicht trivial.
Flexible Plattform
Diese Situation ist nicht befriedigend, da man nur die Wahl zwischen zwei nicht optimalen Szenarien hat. Das Ziel sollte sein, eine Lösung zu finden, die auf der einen Seite integriert und einfach zu administrieren ist. Auf der anderen Seite sollte die Toolchain so flexibel sein, dass alle Bestandteile bei Bedarf ausgetauscht werden können. Idealerweise das Ganze auch noch mit möglichst geringen Lizenzkosten, etwa durch die Kombination freier und kommerzieller Tools. Im Eigenbau ist das allerdings nur mit erheblichem Aufwand zu leisten: Die Integration der verschiedenen Tools zu einer einheitlichen Entwicklungsinfrastruktur ist nicht trivial. Unterschiedliche Schnittstellen, Konfigurationsmöglichkeiten und Benutzerverwaltungen sorgen hier für erhebliche Aufwände. Auch übergreifende Backup- und Restore-Lösungen sind nicht ohne erhebliches Engagement der Administratoren realisierbar. Nicht zu vergessen die zum Teil deutlich voneinander abweichenden Update-Verfahren und -Zyklen der Tools. Alleine der beliebte Build-Server Jenkins erhält alle zwölf Wochen eine neue LTS-Version – in den ersten neun Wochen des vergangenen Jahres kam Jenkins auf elf Releases, die getestet und integriert werden mussten. Durch die Vielzahl der verwendeten Tools ist alleine für die Aktualisierungen aller Komponenten ein erheblicher Aufwand nötig, wenn man auf dem aktuellen Stand bleiben möchte.
Moderne Entwicklungsansätze erfordern, dass die von den jeweiligen Projekten und Teams benötigten Funktionalitäten und Tools möglichst rasch zur Verfügung stehen. Daher sollten Tools auf schnelle, unkomplizierte Weise bereitgestellt werden können, ohne dass daraus ein klassisches IT-Projekt mit langer Laufzeit wird. Denn das läuft dem Agilitätsgedanken zuwider. Erreicht werden kann das durch die Kombination der beiden Ansätze – selbstgebaut oder proprietär – in Form einer Shared Self-Service-Plattform. Dahinter verbirgt sich eine dem Bedarf anpassbare Toolchain, die von den Entwicklungsteams im Self-Service-Verfahren projektindividuell zusammengestellt werden kann – es ist also eine DevOps-Plattform, die Tools und Prozesse integriert und mit wenig Administrationsaufwand bereitstellt.
Eine solche Plattform muss natürlich deutlich umfangreicheren Ansprüchen genügen, als das bei einer einfachen Toolbox für Entwicklungsteams der Fall ist. Ganz oben auf der Liste der Anforderungen steht bei einer Infrastruktur die schon erwähnte einfache Administrierbarkeit. Diese muss mit möglichst geringem Aufwand, bei einem hohen Automatisierungsgrad und in gleichbleibender Qualität betrieben werden können. Ferner muss eine Infrastruktur zeitnah skalierbar sein, um den schnell wechselnden Anforderungen von Unternehmen gerecht zu werden. Sicherheit und Zuverlässigkeit sind ebenfalls zentrale Forderungen. Neben dem Schutz der Daten und Systeme betrifft das auch Backup und Restore, je nach Unternehmen sind auch Desaster Recovery und Business Continuity wichtige Aspekte. Zuletzt muss die Infrastruktur zukunftssicher sein, sie muss sich also mit vertretbarem Aufwand um künftige Technologien, Methoden und Tools erweitern lassen. Pointiert gesagt: Eine DevOps-Plattform sollte die im positiven Wortsinn industrielle Softwareentwicklung ermöglichen, die effizient, zuverlässig und mit geringen Varianzen beim Ergebnis abläuft. Nur so kann sie dem Bedarf digitaler Geschäftsprozesse im Rahmen von Industrie 4.0 und digitaler Transformation gerecht werden: Schnelle Adaption neuer Technologien bei gleichzeitig hoher Zuverlässigkeit im Einsatz.
Tool-agnostische Plattform
Eine Infrastruktur, die diese Anforderung erfüllen kann, kann sich zum Beispiel an der bewährten Aufteilung in zwei Schichten (2-Tier) orientieren: Ein zentrales Backend stellt ein Repository bereit, über das die Administratoren die benötigten Tools für die Instanzen der Entwickler und für die Verwaltung des Systems zusammenstellen. Grundsätzlich ist es dabei sinnvoll, die Architektur nicht nach bestimmten, aktuell benötigten Tools auszurichten, sondern diese möglichst generisch zu halten. Denn je nach Projekt müssen neue Tools in die Toolchain aufgenommen werden können, da bestehende Tools ihre Bedeutung verlieren oder durch neue, leistungsfähigere Alternativen ersetzt werden. Ein weiterer Aspekt, der bei der Infrastruktur berücksichtigt werden sollte, ist der Schutz der Daten. Wobei es hier weniger um Daten im Sinne des Datenschutzgesetzes geht, sondern mehr um das geistige Eigentum des Unternehmens. Viele Entwicklungsprojekte arbeiten mittlerweile cloud-basierend – ein sinnvoller Ansatz, da alle Daten und Code-Teile allen Entwicklern, Testern und Managern jederzeit zur Verfügung stehen. Viele Unternehmen bringen jedoch der Cloud grundsätzliche Bedenken entgegen, gerade was die Sicherheit der darin gespeicherten Daten betrifft. Die Sorgen sind nicht unberechtigt. Denn die in der Entwicklung erzeugten Daten sind für die meisten Unternehmen wertvolle Assets, die entsprechend geschützt werden müssen. Eine Plattform, die die Entwicklungsprojekte im eigenen Rechenzentrum belässt, bietet hier signifikant mehr Kontrolle über die erforderlichen Schutzmaßnahmen.
Konkret umgesetzt wurde dieser Ansatz zum Beispiel vom Braunschweiger Software-Unternehmen Cloudogu. Dessen Lösung Cloudogu EcoSystem (CES) basiert auf mit Docker containerisierten Tools, die durch eine automatische Provisionierung zu einer integrierten Gesamtlösung zusammengeführt werden. So umfasst die Plattform zum Beispiel eine einheitliche Single-Sign-On-Lösung, die bei allen Containern übergreifend zum Einsatz kommt. Das lästige Problem einer selbst zusammengestellten Toolbox mit unterschiedlichen Benutzerauthentifizierungen wird so gelöst. Darüber hinaus sind die Container bei Updates so harmonisiert, dass die eigene IT-Abteilung hier wenig Arbeit hat: Updates werden zentral durch Cloudogu als getestete Container für die DevOps-Plattform bereitgestellt und von den Anwendern eingespielt. Als Repository dient dabei ein cloud-basierendes Backend, an dem sich die on-premises installierten Instanzen der Plattform bedienen können. Hier stehen bereits zahlreiche Lösungen wie Jenkins, Nexus Repository, SonarQube oder Smeagol bereit.
Automatische Konfiguration
Die vor Ort betriebenen Instanzen sind standardisierte virtuelle Maschinen, die aus drei Schichten bestehen: Die Basis bildet ein beliebiger Hypervisor. Jede virtuelle Maschine verfügt über Linux als Betriebssystem, auf dem die Docker-Engine sowie Nginx als Web-Server und Reverse-Proxy läuft. Welche Tools konkret installiert werden sollen, kann vom Administrator während des Setups festgelegt werden. Dabei werden alle angeforderten Container automatisch heruntergeladen, konfiguriert und installiert. Darüber hinaus stehen in der Enterprise-Version wichtige Funktionen wie Backup und Restore bereit. Durch die konsequente Virtualisierung können beliebig viele Instanzen betrieben werden, die vollständig voneinander getrennt sind. Eine Instanz kann in der Regel in einer halben Stunde betriebsbereit aufgesetzt werden. Das Hinzufügen weiterer Tools oder auch das Entfernen nicht mehr benötigter Komponenten ist jederzeit möglich.
Wirtschaftlichkeit, Automatisierung und agile Ansätze erfordern eine entsprechende Infrastruktur.
Der Einsatz der Self-Service-Plattform bringt einige Vorteile mit sich. So sind Konfiguration und Betrieb der Infrastruktur mit signifikant geringerem Aufwand möglich als bei herkömmlich zusammengestellten Toolchains. Zudem sorgt der durchgängige Einsatz von Single-Sign-On für einen reibungslosen Ablauf der Entwicklungsarbeit. Neue Tools lassen sich sehr einfach in die Toolchain integrieren, weitere Instanzen für Projekte mit anderem Tool-Bedarf oder zur strikten Projekttrennung können schnell aufgesetzt werden. Besonders in Unternehmen mit hohem Entwicklungsanteil können hier zentral sichere, individuelle Plattformen für die internen Kunden oder auch für externe Partner realisiert werden, ohne dass es zu einem Wildwuchs kommt. Zudem besteht durch die einfache und flexible Möglichkeit, Tools individuell zusammenzustellen, keine Gefahr eines Vendor-Lock-Ins.
Fazit
Die aktuellen Entwicklungen zeigen, dass die Industrialisierung auch in der Softwareentwicklung angekommen ist. Wirtschaftlichkeit, Automatisierung und agile Ansätze erfordern eine entsprechende Infrastruktur. Ein hoher Standardisierungsgrad erlaubt den ressourcenschonenden Betrieb, sowohl hinsichtlich des Budgets als auch des Personaleinsatzes. Gleichzeitig ist ein umfassender Individualisierungsgrad erforderlich, um den unterschiedlichen Entwicklungsprojekten Rechnung zu tragen. Der Aufbau einer virtualisierten und containerisierten Infrastruktur, wie es mit dem Cloudogu EcoSystem möglich ist, ist vor allem für Unternehmen mit vielen Entwicklungsprojekten und verteilten Teams hilfreich. Industrie 4.0 und digitale Transformation der Geschäftsprozesse und -modelle erfordern Entwicklungsprozesse, die schnell, zuverlässig und kostengünstig ablaufen. Nicht nach dem Vorbild der Manufaktur, sondern an den Methoden der industriellen Fertigung ausgerichtet. Eine integrierte Self-Service-Plattform übernimmt hierbei die Rolle der optimierten Produktionsstraße, wo alle Prozesse ineinandergreifen. Nur so ist es möglich, in der Softwareentwicklung mit dynamischen Märkten, Prozessen und nicht zuletzt Unternehmen Schritt zu halten. Oder sogar der vielfältigen Dynamik immer einen Schritt voraus zu sein.
