© svetabelaya/Shutterstock.com
Continuous Delivery mit Feature-Toggles

An- und Ausschalter


Seit einigen Jahren kommen lineare Vorgehensweisen wie die des Wasserfallmodells kaum noch zur Anwendung. Sie wurden durch agile Methoden wie Scrum oder Kanban ersetzt. Dadurch ist unser Arbeitsalltag in einem Softwareentwicklungsteam angenehmer und effizienter geworden. Im Zuge dessen haben auch Praktiken wie Continuous Integration (CI) und Continuous Delivery (CD) Einzug in unseren Arbeitsalltag gehalten. Durch CI-Server wie Jenkins, GitHubCI oder TravisCI werden lästige und ineffiziente Tätigkeiten wie das immer wiederkehrende Integrieren weitestgehend automatisiert.

Auch Continuous Delivery [1], [2] sorgt für eine weitere Verkürzung der Entwicklungszeit und Time to Market. Durch automatisierte Deployments wird dafür gesorgt, dass jeder Commit direkt beim Kunden ankommen kann.

Im Zuge von Scrum und der damit verbundenen Arbeitsweise in Sprints werden neue Features in der Regel erst am Sprintende veröffentlicht, obwohl sie den Nutzern eigentlich schon viel früher zugänglich gemacht werden könnten. Einen deutlich besseren Job macht an dieser Stelle die Entwicklung nach Kanban. Durch sie fällt die Denkweise in Sprints weg und es werden täglich neue Versionen der Software veröffentlicht.

Das geht allerdings nur, wenn auf ein hohes Maß der Automatisierung gesetzt wird und unnötige Tätigkeiten eliminiert werden. Tests und Deployments werden vollständig automatisiert, auf händisch gepflegte Releaseinformationen wird verzichtet und es muss auch kein Vorgesetzter mehr Releases freigeben. Zugunsten der Entwicklungsgeschwindigkeit und der Time to Market wird also eine Menge Ballast abgeworfen.

Was sich seither allerdings hartnäckig gehalten hat, ist die Verwendung von Feature Branches. Wie selbstverständlich wird diese Arbeitsweise mit jeder Evolutionsstufe des Vorgehensmodells übernommen und in den seltensten Fällen hinterfragt.

Zugegeben, früher waren die Schmerzen, die durch Feature-Branches entstanden sind, noch deutlich größer als heute. Branches lebten in der Regel monatelang bis zu einem Code-Freeze. Was bedeutete, dass oft erst zum Zeitpunkt des Code-Freeze der Big Bang stattfand und alle Änderungen mühselig integriert werden mussten. Die lange Lebensdauer der Branches sorgte dafür, dass es in der Regel viele Änderungen an vielen Stellen im Code gab, die es zu integrieren galt. Das erhöhte natürlich auch die Gefahr von Merge-Konflikten, die zwar durch den Fortschritt moderner Versionsverwaltungen wie Git weniger aufwendig zu beheben sind, jedoch nicht vo...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang