© Excellent backgrounds/Shutterstock.com
Feature Toggles als Hilfsmittel einsetzen

On/off


Continuous Delivery (CD) ist aus der modernen Softwareentwicklung nicht mehr wegzudenken. Es hat den Anspruch, Softwareprodukte bei gleichbleibender ­Qualität jederzeit lieferfähig zu halten. Dieser Artikel zeigt, wie Feature Toggles bei der Erreichung dieses Ziels helfen können und Probleme, die bei CD auftreten, vermieden werden können.

Eine im Rahmen von CD eingesetzte Technik ist Continuous Integration, kurz CI. Die Voraussetzung für den Einsatz von CI ist, dass alle Teammitglieder auf demselben Entwicklungszweig arbeiten und dort den entwickelten Programmcode ablegen. Da so alle Änderungen der Teammitglieder unmittelbar integriert werden, bleibt der Integrationsaufwand minimal; außerdem können eventuelle Integrationsprobleme sofort behoben werden. Durch die Integration ergibt sich ein weiterer Vorteil für CD: Der aktuelle Entwicklungsstand kann bereits getestet und die Softwarequalität geprüft werden.

Nach jeder Änderung im Entwicklungszweig und deren erfolgreicher Integration kommt Continuous Inspection zum Einsatz. Dabei handelt es sich um eine Technik, die zur Überprüfung der Softwarequalität eingesetzt wird. Zu diesem Zweck wird eine Inspektionssoftware, z. B. SonarQube [1], verwendet, die den Programmcode scannt und auf die Verletzung von Regeln untersucht. Durch die Nutzung dieser Technik ist es möglich, Mängel der Software frühzeitig zu identifizieren und im Anschluss zu beheben, was wiederum die Softwarequalität langfristig verbessert.

Auch die nächste Technik wird erst nach erfolgreicher Integration ausgeführt: automatische Softwaretests. Hier wird der Entwicklungsstand mittels automatisierter Testfälle durchlaufen. Sofern es eine gewünschte bzw. erforderliche Testabdeckung gibt, können diese Tests Fehler aufdecken. Trotzdem ist auch bei einer hundertprozentigen Testabdeckung nicht garantiert, dass Fehler gefunden werden. Erst durch ständiges Testen der Software können Aussagen über die Qualität getroffen werden.

Nach jeder Änderung im Entwicklungszweig werden die CD-Techniken in der gleichen Reihenfolge durchlaufen. So wird gewährleistet, dass Weiterentwicklungen ohne großes Risiko ausgeliefert werden können, da durch CI und das permanente automatisierte Testen eine Aussage über die Qualität der Software getroffen wird. Doch im Fall von kurzfristigen Änderungswünschen, unfertigen bzw. fehlerhaften Funktionen oder zu kurzen Auslieferungszeiten ist die Lieferfähigkeit einer Software in Gefahr, da auch trotz Integration und kontinuierlicher Tests nicht alle Fehlerquellen ausgeschlossen werden können [2]. Folgende möglichen Problemszenarien können auftreten:

Angenommen, die Auslieferung der Software soll im Rhythmus von drei Wochen erfolgen. Nun tritt auf, was wohl jedem Entwickler bekannt ist: Eine Aufgabe im Entwicklungsprozess gestaltet sich schwieriger und zeit­intensiver, als das im Vorhinein geplant war und nimmt bspw. die doppelte Zeit in Anspruch. Durch die kontinuierliche Integration steckt nun eine unfertige Komponente im Auslieferungspaket, was dazu führt, dass die Auslieferung auf dem Produktivsystem nicht planmäßig stattfinden kann. Denn unfertige Funktionen werden höchstwahrscheinlich Fehler auslösen. Auch ein kurzfristiger Änderungswunsch unmittelbar vor der Auslieferung kann zu ungeahnten Problemen führen. Die geforderten Änderungen können mitunter Fehler oder unbekannte Probleme verursachen, deren Behebung einen erheblichen Aufwand zur Folge hat. Dadurch ist der Auslieferungszeitpunkt geringstenfalls gefährdet oder kann im schlimmsten Fall überhaupt nicht eingehalten werden.

Damit solche Probleme bzw. Fehler nicht die termingerechte Auslieferung gefährden, werden in der Praxis häufig Feature Branches eingesetzt, die man symbolisch als Zweig betrachten kann. Neben dem Haupt-Branch gibt es weitere Branches, sog. Feature Branches (kurz FBs), die ausgehend vom Haupt-Branch erzeugt werden. Mithilfe dieser FBs werden neue Funktionen und Komponenten entwickelt oder Fehler behoben [3]. Der Haupt-Branch enthält hierbei den Entwicklungsstand, der ausgeliefert wird. Bevor der Programmcode eines FBs ausgeliefert werden kann, muss dieser vorher in den Haupt-Branch integriert werden (Abb. 1).

mueller_stefan_1.tif_fmt1.jpgAbb. 1: Haupt-Branch und FBs

Die Nutzung von FBs bietet viele Vorteile. Zunächst ist hier zu erkennen, dass die neue Komponente unabhängig vom Haupt-Branch entwickelt wird. Änderungen im Haupt-Branch haben demnach keine Auswirkungen auf den Code des FB und andersherum. Sollte mehr Entwicklungszeit nötig sein, als der Auslieferungszyklus andauert, so ist das unerheblich für die neue Komponente und die Auslieferung, da sie sich noch immer auf dem FB befindet. Kommt es zu Fehlern oder unbekannten Problemen, können diese unabhängig von der Auslieferung behoben werden. Der Auslieferungszeitpunkt ist somit nicht in Gefahr. Zunächst scheint es durchaus sinnvoll, Branches im Softwareentwicklungsprozess einzusetzen. Allerdings ergeben sich bei genauerer Betrachtung auch einige Nachteile.

Der Programmcode befindet sich nun auf einem FB. Da dadurch die Techniken von CD während der Entwicklung nicht durchlaufen werden, bedeutet dies, dass der Programmcode nicht mehr kontinuierlich integriert und getestet wird. Alle bisher erläuterten Vorteile der CD-Techniken sind also nicht auf die FBs anwendbar.

Ein Beispiel aus der Praxis soll das verdeutlichen: Angenommen, Kundenbela...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang