Workflow und Software-Entwicklung ‒ passt das?

Anbieter zum Thema

Rittal GmbH & Co. KG

dtm Datentechnik Moll GmbH

VON ZUR MÜHLEN'SCHE GmbH

Beurteilen Sie Ihre Prozesse

Manche Softwareprozesse sind einfacher als andere. Wenn die Abläufe in der Pipeline einfach und vorhersagbar genug sind, kann es relativ simpel sein, einen wiederkehrenden Arbeitsablauf zu definieren, sodass das fertige Produkt wie vom Fließband kommt.

Das ist in der Realität jedoch selten so, vor allem in großen Firmen. Meistens ist die Entwicklung von Software weitaus komplizierter. Viele einzelne Schritte sind nötig, die festgelegt, durchgesehen, überarbeitet, parallel ausgeführt, zurückgestellt, neu gestartet, gespeichert, korrigiert, getestet, erneut getestet und tausende Male modifiziert werden.

CD, also Continuous Delivery, bügelt diese unebenen Prozesse bereits bis zu einem gewissen Grad glatt. Alleine mit Hilfe von CD lässt sich die Komplexität jedoch nicht wirklich vereinfachen. Selbst in den ausgeklügeltsten Pipelines sind Stopps, Rückschläge und Neuanläufe vorprogrammiert. Die Geschäftsprozesse müssen das abfedern.

Die Parameter für die Vorgangssteuerung

Je komplexer eine Pipeline wird, desto mehr Zeit und Geld müssen für die Aufgabe bereitgestellt werden. Die Lösung liegt in der Automatisierung der Pipeline. Ziel sollte es daher sein, einen Workflow zu gestalten, der den Build automatisch und ergebnisorientiert von einer Station zur nächsten führt.

Speziell für komplexere Pipelines sind hierbei etliche Parameter zu beachten. Hier eine Auswahl:

• Mehrere Phasen – in großen Unternehmen müssen etliche unterschiedliche Ebenen unter einen Hut gebracht werden. Manche davon sind geteilt, was mehrere Teams erfordert.

• Verzweigungen und Schleifen – Pipelines sind nicht immer gerade. Manchmal müssen Prozesse neu aufgebaut und getestet werden, speziell, wenn eine Fehlersuche vonnöten ist.

• Stromausfälle – speziell bei einer langen Pipeline ist eine Workflow-Engine unabdingbar, welche den Status Quo regelmäßig und zuverlässig speichert.

• Menschliche Interaktion – Für manche Prozess-Schritte ist die persönliche Kontrolle des Builds durch das Team nötig. Workflows sollten diese „Interventionen“ (sowohl die geplanten als auch die ungeplanten) verrechnen können.

• Fehler – Sobald ein Fehler ersichtlich wird, sollte eine automatische Rückkehr an einen frei gewählten Punkt möglich sein.

• Wiederbenutzbare Builds – im Falle eines fortlaufenden Fehlers, sollte das System Builds erlauben, wiederbenutzt zu werden, um den Prozess so nicht aufzuhalten.

In der Vergangenheit haben Software-Teams Teile ihrer Pipeline-Prozesse durch eine Vielzahl von Werkzeugen und Plugins automatisiert. Sie verbinden Ressourcen auf verschiedene Weisen, wobei diese sich von Aufgabe zu Aufgabe ändern. Pipelines werden definiert und Builds von Ort zu Ort bewegt – manchmal automatisch, ein andermal unter menschlicher Leitung, und alles jeweils mit unterschiedlichem Erfolg.

Tools und Comunities

Vor dem Hintergrund der Weiterentwicklung automatisierter Pipelines gibt es nun Tools, die auch viele der oben genannten Variablen mit einschließen, Variablen, die bisher ein Problem für komplexe Pipelines darstellten. Manche dieser Tools werden von bekannten Namen wie Chef, Puppet, Serena und Pivotal bereitgestellt. Andere beliebte CD-Tools haben ihren Ursprung im Open Source, so beispielsweise Jenkins.

Apropos Jenkins, die Community veröffentlichte kürzlich Funktionen, die speziell automatisierte Workflows verbessern. Das Jenkins Workflow-Plugin gibt einem Softwareteam die Möglichkeit, den gesamten Application-Lifecycle zu automatisieren, seien das einfache oderkomplexe Prozesse. Die Teams können nun dank Jenkins den gesamten Software-Delivery-Prozess redigieren, wobei der Code – unter Messung der Performance an jeder Stelle – von einem Ort zum nächsten bewegt wird.

* Sacha Labourey ist CEO und Gründer von Cloudbees, dem Enterprise Jenkins Unternehmen. Bevor er Cloudbees im Jahr 2010 gründete, war er Mitgeschäftsführer von Red Hat´s Middleware-Divsion. Zu Red Hat kam Sacha Labourey im Zuge der Übernahme des Unternehmens JBoss, hier war er als CTO tätig.

(ID:43558521)