Kurze Iterationszyklen, regelmäßige Tests und Continuous Integration: Agile Ansätze geben in der Softwareentwicklung ein neues Tempo vor, versprechen dadurch höhere Flexibilität und Qualität. Spätestens jedoch in der Systemintegration stellt agiles Vorgehen viele Unternehmen vor Herausforderungen bezüglich der Geschwindigkeit und Qualität. So ist es beispielsweise für die Integration unbedingt notwendig, die Software an die verschiedenen Integrationsumgebungen anzupassen. In einer heterogenen IT-Infrastruktur kann dies allerdings bis zu zwei Wochen dauern - viel zu lang für die kurzen Iterationen der agilen Verfahren. Außerdem ist die manuelle Integration höchst fehleranfällig.

Automatisierter Build

Eine Lösung für beide Probleme bieten automatisierte Prozesse: Für die Build-Phase etwa zeigt die Praxis, dass sich der Aufwand durch geschickte Standardisierung und Automatisierung auf ungefähr ein Drittel der ursprünglichen Zeit reduzieren und dadurch an Geschwindigkeit und Effizienz der agilen Entwicklung angleichen lässt. Auch die Qualität der Software steigt beträchtlich. Unbedingte Voraussetzung für diese Optimierungen ist allerdings, dass die nötigen Standards vorhanden sind - und die müssen meist erst noch geschaffen werden.

Derart weitreichende Neuerungen umzusetzen ist keine kleine Aufgabe; doch wer Abläufe und Systeme behutsam anpasst, erreicht sein Ziel in überschaubarer Zeit und bleibt zugleich voll handlungsfähig. Das Build und Deployment ist als zentraler Prozess mit allen anderen Vorgängen der Softwareentwicklung verknüpft und eignet sich daher besonders gut als Ausgangspunkt, um mit Augenmaß Standards einzuführen und sinnvolle Workflows zu definieren. Optimiert wird mit jedem neuen Software-Release, so dass der Anteil an standardisierten Bereichen schrittweise wächst. Letztlich bilden diese Standards die Grundlage für die weitere Automatisierung, durch die die Softwareentwicklung erst tatsächlich komplett agil wird.

Check-in? Spätestens abends

Ein automatisiertes Feature, das vor allem die Software- und Integrationsqualität steigert, ist beispielsweise Continuous Integration: Alle Entwickler checken ihre lauffähigen Sourcen regelmäßig in die Versionsverwaltung ein, um nicht nur die Funktion einer Software, sondern auch ihre Bau- und Verteilbarkeit kontinuierlich zu prüfen. Nach jeder Änderung oder auch einmal jede Nacht startet dann die automatisierte Erzeugung der neuen Software-Builds, die anschließend, ebenfalls automatisch, nach einem vorgegebenen Schema versioniert und im Software-Repository abgelegt werden. Das Deployment auf die vordefinierten Umgebungen kann dann manuell, automatisch oder zeitgesteuert erfolgen - für ein unterbrechungsfreies Testen in der Regel über Nacht. Morgens erhält jeder Entwickler in detaillierten Reports Aufschluss über den Status seiner Arbeit. Integraler Bestandteil ist Continuous Integration unter anderem beim so genannten Extreme Programming (XP).

Lieferung nach Standard

Lässt ein Unternehmen seine Software von einem agil ausgerichteten Dienstleister entwickeln, sollte es zumindest die Softwareannahme so weit wie möglich automatisieren: Der Lieferant legt seine Artefakte in einem definierten Zustand am vorgesehenen Ort bei seinem Kunden ab, entweder als Sourcen in der Versionsverwaltung oder in Form von Installationspaketen im Binary-Format. Ebenfalls in standardisierter Form übergibt er die Konfigurationen für Applikationen sowie die Basistechniken. Nach der Ablage stößt der interne Release-Manager den Annahmeprozess an, Software- und Installationsartefakte werden automatisiert zu einem installierbaren Paket zusammengebaut. Danach erfolgt das Test-Deployment auf eine virtuelle Umgebung mit anschließendem "Smoke Test" (erster Probelauf). Sind alle vier Schritte mit positivem Ergebnis abgeschlossen, wird die Annahme erklärt, und die Weiterverarbeitung in den nachfolgenden Teststufen kann beginnen.

Bereits die Automatisierung der einzelnen Prozessschritte erhöht die Effizienz enorm, was besonders in Bezug auf die kurzen Iterationszyklen der agilen Entwicklung von Bedeutung ist. Darüber hinaus ist jedoch eine noch wesentlich komfortablere Lösung möglich: ein einziger automatisierter Ablauf von der Annahme über das Deployment bis zum Regressionstest mit anschließendem Reporting. Voraussetzung sind allerdings sehr klare, absolut durchgängige Standards, damit der Prozess nicht ungeplant ins Stocken gerät. Vor allem bei den Tests sollte zudem vorab geprüft werden, wo sich die Automatisierung wirklich lohnt, denn meist gilt in diesem Bereich das Pareto-Prinzip: Etwa 80 Prozent lassen sich sinnvoll automatisieren. Bei den restlichen 20 Prozent ist dagegen die Änderungsfrequenz so hoch, dass manuelles Testen die effizientere Lösung ist.

Optimale Strategien

In der Praxis erweisen sich bestimmte Maßnahmen in den meisten Unternehmen als nützlich, um den Übergang zur agilen Softwareentwicklung vorzubereiten - völlig unabhängig von der Ausgangssituation. Dazu zählen beispielsweise das Einführen von Entwicklungs- und Software-Integrationsstandards, virtualisierte Integrations- und Testumgebungen sowie die Konsolidierung der Infrastruktur. Dennoch ist es ratsam, vor einem Automatisierungsprojekt zunächst die individuellen Voraussetzungen genau zu analysieren: Welche Betriebssysteme sind im Einsatz? Welche Applikations-Server und Drittanbieter-Tools werden genutzt? Wer entwickelt welche Software, und wer integriert sie? Eine wirklich passgenaue Strategie für die Umstellung lässt sich nur auf Basis der realen Ausgangslage entwickeln.

Systemvielfalt reduzieren

Speziell im Client-Server-Umfeld ist beispielsweise häufig eine erstaunliche Vielfalt an Hardware und Betriebssystemen zu finden. Die Folge: Jede Technik muss für zahlreiche Umgebungen konfiguriert werden, der Aufwand für Build und Deployment potenziert sich. Bereits eine Konsolidierung der Infrastruktur kann also eine Systemintegration unterstützen, die mit dem Tempo der agilen Entwickler Schritt hält. Interessante Ansatzpunkte sind außerdem Applikations-Server und Queuing: In der Regel reichen in diesen Bereichen jeweils zwei Techniken aus, um alle Anforderungen abzudecken - beim Queuing genügt oft sogar eine einzige Lösung. Auch wenn die agile Entwicklung selbst vor allem auf die Funktionsfähigkeit der Applikationen zielt: Wer den Software-Engineers hier klare Vorgaben macht, vereinfacht die spätere Integration erheblich und spart zudem Personalkosten. Auch teures Spezialisten-Know-how für Installation, Konfiguration und Wartung muss er dann nur noch für maximal zwei Systeme vorhalten.

Größter Spielraum bei Prozessen

Noch größeren Optimierungsspielraum als die Technik bieten im Umfeld der Softwareintegration jedoch die Prozesse: Die Integration eines ganzen Release-Pakets ist durch Automatisierung in etwa einem Viertel der zuvor benötigten Zeit möglich. Gleichzeitig wird der gesamte Vorgang in übersichtliche Teilschritte zerlegt. Dies entspricht den kurzen Entwicklungszyklen agiler Vorgehensweisen, und auch Probleme lassen sich wesentlich schneller erkennen.

Unternehmen, die ihre Software intern entwickeln, sollten unbedingt das Konfigurations-Management im Auge behalten. Dort ist eine standardisierte Vorgehensweise mit einer einfachen, klaren Struktur einerseits die Voraussetzung für die Arbeit mit parallelen Entwicklungssträngen, die zeit spart und, wie etwa im Pair-Programming, der Qualitätskontrolle dient. Andererseits bidlet ein striktes Konfigurations-Management auch die unverzichtbare Ausgangsbasis für die Automatisierung der nachgelagerten Prozesse - besonders effektiv ist hier in der Regel die Abbildung des "Development-in-Head"-Konzepts.

Nächster Ansatzpunkt und gleichzeitig möglicher Nutznießer einer Prozess-Standardisierung ist die Schnittstelle, an der die Software in die IT-Systeme des Unternehmens gelangt. Denn gleichgültig, ob die Anwendungen von externen Dienstleistern oder einem internen IT-Shop entwickelt werden - volle Transparenz und Kontrolle sind nur dann gegeben, wenn der Weg der Sourcen in die Systemintegration eindeutig festgelegt ist. Sowohl Kunde als auch agiler Lieferant profitieren von definierten Prozess- und Infrastrukturstandards, denn die machen es möglich, Releases in leicht integrierbaren Installationspaketen anzuliefern. Praktischer Nebeneffekt für Outsourcing-Kunden: Sie können auf Wunsch den Build-Prozess und sogar die Kontrolle sowie die Speicherung des Sourcecodes auf den Lieferanten verlagern, statt selbst Kontroll-, Speicher- und Personalressourcen dafür vorzuhalten.

Ein Paket für alle Fälle

Wer seine Software dagegen selbst in installierbare Pakete umwandelt, sollte die Daten klar strukturieren und standardisieren - dann lassen sich dieselben Applikationen mit relativ wenig Aufwand in verschiedenen Systemtest-, Integrationstest- und Produktionsumgebungen nutzen: Die jeweilige Anpassung erfolgt über Umgebungs- und Softwareparameter, ohne die Software selbst zu verändern. Die nötigen Informationen werden bei der Anlieferung der Software dokumentiert übergeben und idealerweise automatisch verarbeitet, um auch hier Zeit zu sparen und Fehler zu vermeiden.

Liegen Software und Konfigurationen dann standardisiert vor, steht dem Bau des installierbaren Pakets nichts mehr im Weg. Auch hier ist es wieder sinnvoll, nur eine kleine Anzahl an Systemen zuzulassen: Die meisten Build-Tools geben Workflow und Integrationsstandards vor, und die sollten für alle Releases einheitlich sein. In der Regel reicht hier ein einziges Werkzeug aus, um alle Anforderungen zu erfüllen. Selbst wenn ein Team sich täglich abspricht, wie etwa beim Agile & Scrum, sollten zudem die Build-Skripte grundsätzlich versioniert werden - nicht zuletzt, weil dieses Vorgehen Revisionssicherheit verleiht und es durch die Versionierung möglich ist, Fixes für die Produktion automatisiert an neue Releases weiterzugeben.

Übergreifende Installationsroutine

Eine ähnliche Strategie wie im Build lässt sich für die Standardisierung des Deployments anwenden: Eine einzige, übergreifende Installationsroutine fasst alle zentralen Schritte zusammen, die für das Deployment notwendig sind. Diese Overlay-Komponente ist für alle Projekte gleich und wird bereits im Build-Prozess in jedes Softwarepaket integriert.

Ein solches Vorgehen ist nicht nur weniger aufwendig und fehleranfällig als eine manuelle Anpassung für jede einzelne Applikation - auch Änderungen werden jeweils nur am zentralen Overlay vorgenommen und gelangen beim nächsten Build automatisch in jedes einzelne Paket. Modifizieren Entwickler eine Anwendung also während eines agilen Entwicklungsprozesses, kann das Deployment ebenfalls sofort reagieren.

Als weiteren automatisierten Bestandteil eines ausgereiften agilen Deployment-Verfahrens enthält das Overlay ein Modul mit Prüfmechanismen, die beispielsweise die Erreichbarkeit der Applikations-Server und Ziel-Container, Datenbanken, Zielschemata oder der geforderten Queues kontrollieren. Ergeben sich dann bei der Auslieferung trotz erfolgreichem Test noch Fehler, ist deren Quelle bereits gut eingegrenzt: Sie liegt höchstwahrscheinlich in der Infrastruktur.

Fit für Agilität

Wie lange es letztlich dauert, eine gewachsene IT-Landschaft für die agile Softwareentwicklung fit zu machen, dazu lässt sich kaum eine allgemeingültige Aussage treffen: Zu groß sind die Unterschiede bezüglich der Anzahl der Applikationen und der Heterogenität der Infrastruktur. Zudem braucht nicht jeder Anwender alle hier beschriebenen Schritte zu absolvieren, da viele Unternehmen bereits mit der Industrialisierung begonnen und wichtige Standards umgesetzt haben. Nur auf Basis der individuellen Ausgangsbedingungen ist es also möglich, den Aufwand realistisch einzuschätzen. Eine gründliche und intensive Konzeptionsphase auf Technik- ebenso wie auf Prozessebene ist die wichtigste Voraussetzung, um Probleme von vornherein zu vermeiden. (ue)