Suche
Continuous Deployment richtig umsetzen

Continuous Deployment: Fluch oder Segen?

Michael Thomas

© Shutterstock.com/jesadaphorn

Führt Continuous Deployment, also die automatische Überführung von Änderungen in die Produktion, zu schnelleren Releases und höherer Qualität? Oder führt es im Gegenteil nur dazu, das schlechte Software schneller geliefert wird? Kyle Nordeen, Blogger und Demand Generation Specialist bei Zephyr, hat sich auf die Suche nach Antworten begeben.

Das Herz der meisten Entwickler dürfte wohl in erster Linie für die Entwicklung guter Software und den erfolgreichen Abschluss von Projekten schlagen. Agile Methoden und ein angemessenes Tooling können diesen Herzensangelegenheiten sehr zuträglich ein, doch auch hier gilt wie so oft: Augen auf. Denn es geht, wie der DevOps-Experte Jeff Sussna im Interview mit JAXenter so schön formulierte, bei Continuous Delivery und Co. keinesfalls darum, „immer schneller Schrott abzuliefern“.

Lesen Sie auch: Continuous-Delivery-Horrorstorys… und wie man sie verhindert

Wie es um das von Sussna an die Wand gemalte Schreckgespenst in Bezug auf Continuous Deployment – das je nach Sichtweise als Teil einer Triade von aufeinanderfolgender Schritte (Continuous Integration – Continuous Delivery – Continuous Deployment) oder als Bestandteil eines übergeordneten Continuous Delivery-Begriffs betrachtet werden kann – bestellt ist, dieser Frage ging Kyle Nordeen, seines Zeichens Blogger und Demand Generation Specialist bei Zephyr, einem Anbieter von Echtzeit-Testmanagement-Lösungen, nach.

Die Tücken von „Continuous“-Bestrebungen …

Wie Nordeen eingangs konstatiert, kann die im Vergleich zu althergebrachten monolithischen Lösungen höhere Entwicklungsgeschwindigkeit ihre ganz eigenen Nachteile mit sich bringen: Im Rückgriff auf entsprechende Aussagen der Agile Alliance weist er beispielsweise darauf hin, dass es einem Team leicht passieren kann, auf ein falsches Ziel hin zu optimieren, sprich: Anstatt eine auf bessere Qualität abzielende Kultur zu etablieren steht die höchstmögliche Deployment-Frequenz im Mittelpunkt.

Lesen Sie auch: Continuous Delivery – mit welchen Maßnahmen es steht und fällt

Die für Continuous Deployment notwendige Infrastruktur öffnet Fehlern, die von automatisierten Tests nicht erkannt werden, Nordeen zufolge also Tür und Tor, was im schlimmsten Fall zu ernsthaften Problemen wie Abstürzen und inkompatiblen Elementen führen kann, die das Deployment faktisch unbrauchbar machen. Ein weiteres Problem sieht Nordeen darin, dass Teams mitunter nicht darauf achten, das alles auch ordnungsgemäß funktioniert, also beispielsweise Test-Metriken zu wenig Beachtung schenken, während sich ein Projekt durch die Deployment-Pipeline bewegt, was eine Messung bzw. Bewertung des Projektfortschritts und seines allgemeinen Werts erschwert.

… und ihr Wert

Doch trotz dieser Fallstricke kann Continuous Deployment unschätzbare Vorteile (z. B. eine kürzere Time-to-Market) bergen. Wie Franco Mancini (CA Technologies) in einem Artikel über DevOps-Continuous-Delivery feststellte, können Entwickler beispielsweise deutlich schneller Feedback erhalten und bereits zu einem frühen Zeitpunkt des Entwicklungsprozesses Verbesserungen vornehmen, die ihn insgesamt verbessern. Wie Nordeen des Weiteren anmerkt, kann die unter dem Einfluss der agilen Softwareentwicklung erfolgte Einbeziehung der Qualitätssicherung in den gesamten Lebenszyklus eines Projekts zu besseren Testentscheidungen führen.

Lesen Sie auch: Zum Erfolg mit Continuous Delivery – die Geschichte zweier Teams

Last but not least kann Continuous Deployment veraltetem Code entgegenwirken: Anstatt neue Versionen einer Software auf die im Grunde immer gleiche Urversion aufzubauen – was zu Konflikten zwischen neuen und alten Features führen kann – werden Teams dazu angehalten, ihren Code ständig in Richtung Produktion zu schieben, was es der QA-Abeilung ermöglicht, frühzeitige Tests durchzuführen, Feedback zu liefern und somit sicherzustellen, dass die beim Endnutzer ankommende Version auch wirklich ordnungsgemäß funktioniert.

Der Werkzeugkasten

Aufgrund des Tempos agiler Methoden kann es, so Nordeen, natürlich eine nicht unerhebliche Herausforderung darstellen, allen von der QA-Abteilung aufgedeckten Problemen Rechnung zu tragen, weshalb ein ausgeklügeltes Issue-Tracking-System, das jeder Änderung, jedem Bug und jeder Featureanfrage ein eigenes Ticket zuweist, zur Grundausstattung gehören sollte. Somit wird die Nachverfolgung des Projektfortschritts erleichtert; gleichzeitig kann ein derartiges System zumeist problemlos in den Testbetrieb eingebunden werden. Auch unnötige Doppelarbeit wird durch Tickets i. d. R. effektiv unterbunden.

Lesen Sie auch: 6 Grundregeln, wie Sie Contiuous Delivery erfolgreich umsetzen

Damit die QA-Abteilung einen besseren Überblick über den Testbetrieb hat, bieten sich Nordeens Ansicht nach zudem Testverwaltungstools an, die manuelle wie automatisierte Operationen zulassen und zugleich als Plattform für die Zusammenarbeit von Qualitätssicherung und Entwicklung dienen. Zudem, so Nordeen weiter, können Priorisierungs-Funktionen dafür sorgen, dass die QA-Teams durch die Konzentration ihrer Bemühungen auf die wichtigsten Elemente die allgemeine Qualität des Projekts verbessern.

Aufmacherbild: Businessman confused von Shutterstock.com / Urheberrecht: jesadaphorn

Geschrieben von
Michael Thomas
Michael Thomas
Michael Thomas studierte Erziehungswissenschaft an der Johannes Gutenberg-Universität Mainz und arbeitet seit 2013 als Freelance-Autor bei JAXenter.de. Kontakt: mthomas[at]sandsmedia.com
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: