In der modernen Softwareentwicklung spielen die Rückmeldungen aus der Produktion eine entscheidende Rolle bei der kontinuierlichen Verbesserung und dem Erhalt von stabilen Systemen. Es ist eine etablierte Praxis, verschiedene Mechanismen zu implementieren, die es ermöglichen, Aktivitäten und Probleme in Echtzeit zu überwachen. Diese Rückmeldungen kommen nicht nur aus dem direkten Nutzerverhalten, sondern auch aus Fehlerprotokollen und Systemereignissen, die auf potenzielle Schwachstellen hinweisen.

Ein Beispiel, das den Wert von Feedback aus der Produktion verdeutlicht, stammt aus meiner eigenen Erfahrung mit Software für einen Online-Marktplatz. Diese Software überwachte aktiv die Fehlercodes, die den Nutzern angezeigt wurden. Ein ständig aktualisierter Graph zeigte die Anzahl der Fehler im Zeitverlauf. Diese Information war für das Entwicklungsteam von entscheidender Bedeutung, da unerwartete Spitzen in der Fehleranzahl darauf hinwiesen, dass möglicherweise durch ein Update ein Problem eingeführt wurde. Bei meinem Einstieg war dieser Graph jedoch in einem Zustand, in dem nur eine geringe Anzahl an Fehlern regelmäßig angezeigt wurde. Diese Fehler wurden als weniger dringlich angesehen, da sie zu einem konstanten Bestandteil der Nutzererfahrung geworden waren. Einige Mitglieder aus den Teams für Betrieb und Entwicklung erkannten jedoch die zugrunde liegenden Ursachen dieser Fehler und forderten deren Behebung. Ihre Erinnerungen an den Ursprung der Fehler, die Situationen, in denen sie auftraten, und ihr Wissen darüber, wer sie beheben konnte, waren entscheidend, um den Zustand des Systems zu verbessern. Letztlich konnte das Team den Graphen auf null Fehler zurücksetzen. Diese Erfahrung hatte auch Auswirkungen auf zukünftige Tests, da die Bedeutung einer proaktiven Überwachung und Fehlervermeidung vor der Veröffentlichung von Software weiter hervorgehoben wurde.

Die Überwachung und Benachrichtigung sind zwei weitere wesentliche Komponenten in diesem Prozess. Sie bieten nicht nur Feedback während der Interaktion der Nutzer mit der Produktionsumgebung, sondern stellen auch eine testbare Komponente des Systems dar. Bei der Konfiguration eines neuen Überwachungsmechanismus sollte dieser idealerweise getestet werden, indem ein Problem simuliert wird, das der Überwachungsmechanismus erkennen soll. Wenn es nicht möglich ist, das Problem in einer realen Umgebung zu verursachen, kann auch mit simulierten Daten gearbeitet werden, um das Szenario nachzustellen. Die Möglichkeit, Testdaten zu kontrollieren, erleichtert es, zwischen echten Systemaktivitäten und den Tests zu unterscheiden.

Es ist auch wichtig, die Benachrichtigungsfunktionen zu testen. Wenn ein Monitor ausgelöst wird, sollte überprüft werden, ob die Benachrichtigung erfolgreich zugestellt wird und ob die entsprechenden Alarme in der richtigen Weise bearbeitet werden. Zudem muss sichergestellt werden, dass nach dem Vorfall auch eine ordnungsgemäße Bereinigung der Benachrichtigungen erfolgt. Dazu gehört die Frage, ob der Alarm als gelöst markiert wird, archiviert oder entfernt wird, und ob eine entsprechende Benachrichtigung über die Behebung des Problems versendet wird. Es ist auch wichtig, den gesamten Benachrichtigungsprozess zu hinterfragen. Wenn eine Benachrichtigung korrekt ausgelöst wird, aber die erforderliche Reaktion nicht klar ist, ist das Monitoring-System insgesamt gescheitert.

Ein weiterer Aspekt von Feedback in der Produktion ist die Analyse von Nutzeraktivitäten. Analytische Daten, die durch die Interaktion der Nutzer mit einer Anwendung oder einem System gesammelt werden, sind von unschätzbarem Wert für die kontinuierliche Verbesserung eines Produkts. Diese Daten können direkt durch die Messung von Aktionen, wie dem Besuch einer Webseite, oder indirekt durch Sensoren und Tracking-Funktionen, wie etwa bei Fitness-Trackern, erfasst werden. Große Organisationen sammeln eine Vielzahl solcher Daten, um das Verhalten ihrer Nutzer besser zu verstehen und darauf zu reagieren. Die Erhebung dieser Daten kann durch spezialisierte Teams erfolgen, die häufig Kenntnisse in Informatik, Statistik und maschinellem Lernen besitzen.

Bei der Erhebung und Analyse von Daten müssen Entwickler jedoch darauf achten, welche Daten erfasst werden und ob sie korrekt gestaltet sind, um langfristig einen Mehrwert zu bieten. Das Testen der Analytik konzentriert sich oft nicht auf das einzelne Ereignis, sondern auf das gesamte System, wie Nutzer durch verschiedene Arbeitsabläufe verfolgt werden. So könnte ein Testbeispiel die Frage aufwerfen, ob Transaktionen in einem Online-Banking-Workflow sowohl als "Schnellüberweisung" als auch als "Zahlung" erfasst werden sollten oder ob diese Daten getrennt gespeichert werden sollten, um differenzierte Einblicke zu ermöglichen.

Zusätzlich ist es wichtig, die Protokollierung im System zu überprüfen. Log-Dateien bieten eine detaillierte Aufzeichnung von Transaktionen, Fehlern und Systemzuständen, die für die Diagnose von Problemen unerlässlich sind. Diese Logs können aus der eigenen Software, von Drittanbieter-Anwendungen oder aus der zugrunde liegenden Plattform stammen. Sie liefern oft die ersten Hinweise auf die Ursache eines Problems, und daher ist es von entscheidender Bedeutung, dass das Entwicklungsteam ein Verständnis dafür entwickelt, welche Arten von Informationen in diesen Protokollen enthalten sein sollten. Dabei ist eine ordnungsgemäße Klassifizierung von Nachrichten als Fehler, Warnungen, Informationen oder Debugging-Daten unerlässlich.

Zusammengefasst zeigt sich, dass eine effektive Rückmeldung aus der Produktion nicht nur auf Monitoring und Benachrichtigungen angewiesen ist, sondern auch eine gründliche Analyse der Nutzeraktivitäten und der internen Systemdaten umfasst. Es reicht nicht aus, lediglich die Fehlerquote oder Systemzustände zu überwachen; vielmehr müssen diese Daten in einem größeren Kontext betrachtet und genutzt werden, um fundierte Entscheidungen zu treffen und die Qualität des Systems kontinuierlich zu verbessern. Ein umfassender Test der verschiedenen Feedback-Mechanismen und die kontinuierliche Feinabstimmung der Monitoring-, Analyse- und Logging-Prozesse sind daher unerlässlich, um ein funktionierendes und benutzerfreundliches Produkt zu gewährleisten.

Warum Randomisierung bei Werbemessungen entscheidend ist: Eine Betrachtung der A/B-Tests und Beta-Tests

Randomisierung spielt eine fundamentale Rolle in der Durchführung von Experimenten, insbesondere in der Messung des Einflusses von Werbung auf das Kaufverhalten von Konsumenten. Durch den Einsatz von Zufallszuweisungen der Testgruppen wird sichergestellt, dass die Unterschiede zwischen den Bedingungen nicht durch vorab festgelegte Merkmale der Konsumenten erklärt werden können. Dies wird durch die probabilistische Äquivalenz ermöglicht, die besagt, dass bei ausreichend großen und wirklich zufällig ausgewählten Stichproben jeder Unterschied im Kaufverhalten einzig und allein durch die Werbung selbst bedingt ist. Der Vorteil der Randomisierung besteht darin, dass sie alle relevanten Konsumentenmerkmale gleichzeitig berücksichtigt – von Geschlecht und Online-Verhalten bis hin zu unbekannten und potenziell relevanten Faktoren, die dem Experimentator nicht bewusst sind. Auf diese Weise wird der Einfluss der Werbung isoliert und der Vergleich der Bedingungen so durchgeführt, als ob Konsumenten in zwei parallelen Welten existieren würden.

In einem typischen Experiment, das diese Art von Randomisierung verwendet, könnte ein Konsument entweder einer Kontrollgruppe oder einer Versuchsgruppe zugewiesen werden, die eine neue Anzeige sieht. Dabei muss sichergestellt werden, dass jede Interaktion des Konsumenten im Experiment konsistent mit seiner Gruppenzuordnung ist. Ist der Konsument der Kontrollgruppe zugewiesen, sollte er die Kontrollanzeige in jedem weiteren Schritt des Experiments sehen. Bei der Versuchsgruppe, die mit der neuen Anzeige konfrontiert wird, muss diese Anzeige konsequent in allen relevanten Aspekten der Nutzererfahrung erscheinen. Diese Konsistenz ist entscheidend, um Verzerrungen durch zufällige Wechsel zwischen den Bedingungen zu vermeiden.

A/B-Tests, bei denen zwei Versionen eines Produkts oder einer Anzeige miteinander verglichen werden, sind eine häufige Methode zur Durchführung solcher Experimente. Es gibt jedoch mehrere Einschränkungen, die beachtet werden sollten. Ein bekanntes Beispiel ist die Geschichte von Google, das A/B-Tests nutzte, um zu bestimmen, welche Farbnuance von Blau die besten Klickzahlen auf ihrer Toolbar erzielte. Obwohl dies trivial erscheinen mag, rechtfertigte Marissa Mayer, damals Vice President für Suchprodukte bei Google, das Experiment: „So trivial die Wahl der Farbe auch erscheinen mag, Klicks sind ein wesentlicher Teil des Umsatzes von Google, und jede Verbesserung bedeutet mehr Geld.“ Dieser Vorfall zeigt, wie kleinste Änderungen, selbst solche, die auf den ersten Blick unbedeutend wirken, erhebliche Auswirkungen auf die Unternehmensgewinne haben können.

Dennoch sollte A/B-Testing niemals zur einzigen Entscheidungsgrundlage werden. Ein Unternehmen, das sich ausschließlich auf diese Methode verlässt, könnte in eine Art Entscheidungsparalyse verfallen. Wenn alle Entscheidungen ausschließlich auf Basis von Nutzerdaten getroffen werden, verliert das Entwicklungsteam die notwendige Autonomie, um auch kühnere, langfristige Designentscheidungen zu treffen. Kundenverhalten kann helfen, inkrementelle Verbesserungen zu verstehen, jedoch kann es auch zu negativen Reaktionen auf tiefgreifende Innovationen führen, die die gewohnten Erwartungen der Konsumenten herausfordern. Ein oft falsch zugeschriebenes Zitat von Henry Ford – „Wenn ich die Menschen gefragt hätte, was sie wollen, hätten sie schnellere Pferde gesagt“ – illustriert die Gefahr, Entscheidungen nur auf Nutzerwünsche zu stützen.

Ein weiteres wichtiges Testverfahren in der Softwareentwicklung ist das Beta-Testing. Hierbei wird eine neue Version einer Software an eine ausgewählte Benutzergruppe freigegeben, um deren Eignung für eine breitere Veröffentlichung zu testen. Im Gegensatz zu A/B-Tests, bei denen der Fokus auf der Messung von Nutzerpräferenzen und -verhalten liegt, dient Beta-Testing primär der Fehlerbehebung. Die teilnehmenden Benutzer werden gebeten, Bugs zu entdecken, die durch ihre individuellen Nutzungsgewohnheiten und die spezifische Hardware- und Softwareumgebung bedingt sein können. Dies liefert eine Vielzahl an Perspektiven, die intern nicht ohne Weiteres verfügbar sind. Ein weiterer Vorteil des Beta-Tests besteht darin, dass er die Software in einer realistischen Umgebung auf die Probe stellt, die sich nicht immer in den Testumgebungen des Entwicklungsteams nachbilden lässt. In vielen Fällen wird Beta-Testing als Teil einer Produktstrategie eingesetzt, um den Markteintritt zu beschleunigen und die Software bereits vor der offiziellen Veröffentlichung als innovativ und aufregend zu positionieren.

Trotz seiner Vorteile weist auch das Beta-Testing gewisse Einschränkungen auf. Ein häufig genannter Kritikpunkt ist die unzureichende Repräsentativität der Beta-Tester. Diese Selbstselektion führt oft zu einer Verzerrung der Ergebnisse, da Beta-Tester in der Regel frühe Technologiebefürworter sind, deren Erwartungen möglicherweise nicht mit denen des breiten Marktes übereinstimmen. Ein weiteres Problem besteht darin, dass Beta-Tester häufig nur oberflächliche Tests durchführen, wodurch potenzielle Probleme unentdeckt bleiben. Auch die Meldebereitschaft von Usability-Problemen kann gering sein, da Tester diese häufig als weniger bedeutend erachten oder sich unsicher sind, ob ihre Beobachtungen wichtig sind.

In der Praxis ist es daher sinnvoll, das Beta-Testing mit anderen Testmethoden zu kombinieren. Das Entwicklungsteam kann beispielsweise eigene Tests der Benutzerfreundlichkeit, der Performance und der Sicherheit durchführen, um auch die nicht-funktionalen Aspekte der Software zu prüfen. Eine enge Zusammenarbeit zwischen den Entwicklern und den Beta-Testern kann ebenfalls von großem Nutzen sein. Eine Möglichkeit, dies zu erreichen, ist das sogenannte „Pairing“, bei dem ein Entwickler zusammen mit einem Tester die Software nutzt und gemeinsam Probleme identifiziert.

Die Kombination von A/B-Tests, Beta-Tests und der kontinuierlichen Beobachtung von Nutzerfeedback ermöglicht es Unternehmen, ihre Produkte nicht nur zu verfeinern, sondern auch Innovationen zu fördern. Es ist jedoch wichtig, bei der Anwendung dieser Methoden eine Balance zu finden, die sowohl die Bedürfnisse der Nutzer als auch die strategischen Ziele des Unternehmens berücksichtigt. Übermäßige Abhängigkeit von Daten und Tests kann zu einer Kultur der Zögerlichkeit führen, die den kreativen Innovationsprozess behindert. Testergebnisse sollten niemals als alleinige Grundlage für Entscheidungen dienen, sondern als wertvolle Unterstützung bei der Entwicklung besserer, benutzerorientierter Lösungen.

Wie Etsy und Spotify die Herausforderungen des kontinuierlichen Deployments meistern

Etsy, ein führendes Online-Marktplatzunternehmen, hat kontinuierliches Deployment zu einem zentralen Bestandteil seiner Softwareentwicklungsstrategie gemacht. Mit mehr als 25 Änderungen pro Tag in der Produktionsumgebung ist Etsy ein Paradebeispiel für die Komplexität und Dynamik eines solchen Ansatzes. Bei Etsy wird jeder Release minutiös verfolgt, und das System bietet zahlreiche Metriken zur Überwachung der Performance. Doch diese Metriken können nur die Auswirkungen von Veränderungen anzeigen – nicht jedoch deren Ursachen. Mike Brittain, damals Lead Software Engineer bei Etsy, erläuterte das anhand eines Beispiels von PHP-Fehlern. Ein plötzlicher Anstieg von Fehlern auf der Webseite könnte mit einem Rückgang von Nutzerlogins oder Traffic auf den Servern zusammenhängen. Doch die Herausforderung bestand darin, den Ursprung des Problems zu identifizieren. Ohne eine präzise Verknüpfung von Deployment-Daten und Systemmetriken könnte es zu erheblichen Verzögerungen bei der Ursachenanalyse kommen.

Ein weiteres wichtiges Element in der Überwachung von Produktionsänderungen ist das sogenannte "Tracking Every Release". Etsy stellt sicher, dass jede Änderung, die an den Produktionsservern vorgenommen wird, zeitlich exakt erfasst wird. Diese Tracking-Methode ermöglicht es den Entwicklern, schnell zu bestimmen, ob ein Problem durch eine menschliche Änderung (z. B. eine Codeänderung) oder durch externe Faktoren wie Hardwarefehler oder API-Ausfälle verursacht wurde. Die grafische Darstellung von Deployments als vertikale Linien im Monitoring-Dashboard von Etsy bietet eine visuelle Möglichkeit, Anomalien in den Systemmetriken mit den jeweiligen Deployments zu korrelieren. Dieses einfache, aber äußerst effektive System hilft den Entwicklern, schnell zu reagieren, wenn ein unerwartetes Problem auftritt.

Bei Etsy wird Monitoring jedoch nicht als alleinige Lösung für die Qualitätssicherung betrachtet. Vielmehr ist es Teil einer umfassenden Strategie zur Fehlererkennung und -behebung. Noah Sussman, ein Testarchitekt bei Etsy, erklärte, dass sie durch kleine, häufige Releases ein kontinuierliches Testen und Überwachen ermöglichen. Jedes Update wird vor und nach der Bereitstellung automatisiert getestet, um sicherzustellen, dass keine wichtigen Funktionen beeinträchtigt werden. Manuelle Tests und eine fortwährende Überwachung durch das Team ergänzen diesen Prozess. Ein zentrales Element der Strategie ist es, Fehler in Echtzeit zu beheben – häufig innerhalb weniger Stunden nach ihrer Entdeckung.

Ein weiterer prominenter Ansatz zur Fehlerbewältigung und Verbesserung der Infrastruktur kommt von Spotify. Spotify, ein Musikstreaming-Dienst mit über 100 Millionen monatlich aktiven Nutzern, setzte frühzeitig auf Containertechnologie, um die Herausforderungen einer skalierbaren und zuverlässigen Architektur zu meistern. Bereits 2013 führte Spotify Docker ein, um die Bereitstellung von Diensten in einer komplexen Infrastruktur zu vereinfachen. Mit über 250 Servern pro Betriebsingenieur war es eine der größten Herausforderungen, die Konfiguration über alle Maschinen hinweg konsistent zu halten und eine effiziente Nutzung der Hardware zu gewährleisten.

Docker ermöglichte es Spotify, wiederholbare Infrastrukturen zu schaffen, bei denen dasselbe Container-Image in Entwicklung, Test und Produktion verwendet werden konnte. Die Vorteile von Docker lagen auf der Hand: Es erleichtert nicht nur das Management von zahlreichen Diensten, sondern sorgt auch dafür, dass das Deployment effizienter und fehlerresistenter wird. Rohan Singh, ein Infrastrukturingenieur bei Spotify, erklärte, dass Docker das Problem der Hardwarefehlfunktionen und der Inkonsistenz von Maschinen adressiert. Die Container garantieren, dass bei einem Fehler nicht das gesamte System fehlschlägt. Stattdessen wird der fehlerhafte Container einfach neu gestartet, wodurch die Ausfallzeiten minimiert werden.

Doch Docker allein löste nicht alle Herausforderungen von Spotify. Mit der zunehmenden Zahl an Diensten und Hosts stieß das Unternehmen auf das Problem der Skalierbarkeit. Hier kam das Tool Helios ins Spiel, ein Docker-Orchestrierungsframework, das Spotify dabei half, mehrere Dienste auf vielen Hosts effizient zu verwalten. Helios ermöglicht eine gezielte Zuweisung von Diensten zu Hosts und sorgt dafür, dass die Dienste kontinuierlich laufen. Es löst das Problem der sogenannten "NM-Problematik", bei der die Anzahl der Dienste (N) und Hosts (M) nicht immer in einem einfachen Verhältnis zueinander standen.

Beide Unternehmen, Etsy und Spotify, setzen unterschiedliche, aber komplementäre Technologien ein, um ihre Infrastruktur und Deployments zu optimieren. Etsy setzt auf ein fein abgestimmtes System zur Überwachung und schnellen Fehlerbehebung, während Spotify auf Containertechnologien und Orchestrierung setzt, um ihre Produktionstools effizient zu verwalten. Beide Beispiele zeigen, wie kontinuierliches Deployment und die Überwachung von Produktionsumgebungen ein Schlüssel zu einer erfolgreichen und flexiblen Softwareentwicklung sind.

Wichtig zu verstehen ist, dass kontinuierliches Deployment nicht nur eine technische Herausforderung darstellt, sondern auch tiefgreifende organisatorische und kulturelle Veränderungen mit sich bringt. Die Fähigkeit, Software schnell und fehlerfrei zu veröffentlichen, setzt eine enge Zusammenarbeit zwischen Entwicklern, Testern und Operations-Teams voraus. Darüber hinaus erfordert die hohe Frequenz von Deployments eine sorgfältige Planung und Automatisierung von Tests und Überwachungsprozessen. Es wird zunehmend klar, dass Fehlerbehebung und die Suche nach Ursachen nicht nur technische Prozesse sind, sondern auch mit einer neuen Herangehensweise an Zusammenarbeit und Risikomanagement verbunden sind.

Wie Continuous Deployment, Continuous Delivery und DevOps zusammenhängen

Im Jahr 2009, dem gleichen Jahr, in dem DevOps entstanden ist, prägte Timothy Fitz den Begriff "Continuous Deployment". "Continuous Deployment ist einfach: Schicke deinen Code so oft wie möglich an die Kunden." Dieser Ansatz setzte auf eine schnelle und kontinuierliche Bereitstellung von Software. Etwas mehr als ein Jahr später, im Jahr 2010, wurde das Buch "Continuous Delivery" von Jez Humble und David Farley veröffentlicht, das eine leicht abweichende Definition von Continuous Deployment präsentierte und sich schließlich stärker durchsetzte. Laut Humble und Farley bedeutet Continuous Delivery sicherzustellen, dass Software während ihres gesamten Lebenszyklus immer produktionsbereit ist. Es geht darum, dass jeder Build potenziell mit einem einzigen Klick in Produktion gehen kann – automatisch, innerhalb von Sekunden oder Minuten.

Continuous Delivery hat dabei einen engeren Fokus als DevOps. Es konzentriert sich auf die technischen Praktiken, die es einem Entwicklungsteam ermöglichen, schnell zu arbeiten. Dies umfasst Praktiken wie Codierung, Source Control Management und Konzepte wie Feature Flagging, das es ermöglicht, Code in Produktion zu schicken, ohne ihn sofort für die Benutzer verfügbar zu machen. Laut Humble ist das Ziel von Continuous Delivery "unsere Codebasis immer in einem deploybaren Zustand zu halten, selbst wenn Teams von tausenden Entwicklern täglich Änderungen vornehmen. Dadurch eliminieren wir vollständig die traditionellen Phasen der Integration, Tests und Härtung, die nach dem Erreichen des Status 'Dev Complete' folgten."

Es ist durchaus möglich, dass Entwicklungsteams innerhalb einer Organisation Continuous Delivery anwenden, ohne Änderungen im Betriebsteam vorzunehmen. Dieser begrenzte Umfang könnte ein sinnvoller erster Schritt zur Verbesserung des Release-Prozesses sein, aber irgendwann wird dies zu Spannungen führen, da die Teams unterschiedliche Rhythmen verfolgen. DevOps hingegen ist eine breitere kulturelle Veränderung, die diese Spannungen adressiert.

Die Wurzeln von DevOps liegen in der agilen Softwareentwicklung. Agile begann als Manifest mit zwölf Prinzipien, die das Denken der an der Softwareentwicklung beteiligten Personen herausfordern sollten. Es gab jedoch keine detaillierten Implementierungsrichtlinien. DevOps hingegen ist eine deutlichere und praxisorientiertere Antwort auf diese Herausforderung und fokussiert sich auf das Verhältnis zwischen Entwicklung und Betrieb. DevOps hat ein einziges Ziel: die Zuverlässigkeit und Häufigkeit von Releases zu verbessern. Ohne Agile hätte es DevOps möglicherweise nie gegeben. Wenn die Mitglieder eines Entwicklungsteams beginnen, anders zu denken und unter agilen Prinzipien kollaborativ zu arbeiten, gelingt es ihnen, regelmäßig kleinere, nützliche Softwareteile zu erstellen. Dies erzeugt Spannungen mit anderen Bereichen der Organisation, die an einen langsameren Prozess gewöhnt sind. DevOps adressiert diese Spannungen, indem es die Zusammenarbeit zwischen den Entwicklern und denjenigen, die die Software unterstützen, fördert.

Doch kann man DevOps auch ohne Agile durchführen? Ja, das ist möglich. DevOps kann die Beziehungen zwischen den Beteiligten stärken, egal welche Methodik angewendet wird. Das Ziel der Verbesserung der Release-Zuverlässigkeit könnte zum Beispiel darin bestehen, die Zahl der notwendigen Support-Patches zu verringern oder die Ausfallzeiten für Benutzer zu minimieren. Häufigere Releases könnten ebenfalls ein Ziel sein. In einem nicht-agilen Umfeld könnte ein Release monatlich oder jährlich erfolgen. DevOps erfordert also nicht zwangsläufig stündliche oder minütliche Releases. Es wird jedoch schwieriger, DevOps ohne die Prinzipien von Agile umzusetzen, da Menschen aus verschiedenen Disziplinen möglicherweise nicht bereit sind, eng zusammenzuarbeiten. Agile bietet dabei die Grundlage für die erfolgreiche Umsetzung von DevOps, weshalb dieses Buch insbesondere für diejenigen gedacht ist, die DevOps in einem agilen Kontext anwenden möchten.

Ein weiteres bedeutendes Thema im Zusammenhang mit DevOps und Agile ist das Testen. In der Literatur zu DevOps wird das Thema Testen oft übersehen, da der Fokus traditionell auf der Entwicklung und dem Betrieb liegt. Das hat verständlicherweise dazu geführt, dass Tester in vielen Organisationen unsicher sind, wo ihre Rolle innerhalb des DevOps-Modells liegt. Dan Ashby erklärt, dass "Testen an jedem einzelnen Punkt im Modell stattfinden muss" und visualisiert dies als einen kontinuierlichen Prozess, der eng mit allen Phasen der Softwareentwicklung verbunden ist. Humble und Farley stellen in ihrem Buch zu Continuous Delivery fest: "Testen ist eine funktionsübergreifende Aktivität, die das gesamte Team betrifft und kontinuierlich vom Beginn eines Projekts an durchgeführt werden sollte."

Die Herausforderung für Tester besteht darin, ihre spezifische Rolle zu erkennen, wenn Testen als allgegenwärtiger Bestandteil des gesamten Entwicklungsprozesses betrachtet wird. Es stellt sich die Frage, wie Tester zu dieser kontinuierlichen Aktivität beitragen können und ob es sinnvoll ist, das Testen von anderen Aufgaben innerhalb des Entwicklungsteams zu unterscheiden. Auch wenn Testen in DevOps häufig als eine grundlegende Aufgabe angesehen wird, die in den gesamten Entwicklungsprozess integriert ist, bleibt es wichtig, dass Tester ihr Verständnis und ihre Verantwortung für diese kontinuierlichen Prüfungen im Team kommunizieren.

Bevor man jedoch in die Praxis des Testens in einem DevOps-Kontext eintritt, ist es entscheidend, die bestehende Teststrategie und die Vision für DevOps innerhalb der Organisation zu verstehen. Eine regelmäßige Überprüfung der Teststrategie im Team stellt sicher, dass alle auf dem gleichen Stand sind und dass die Implementierung von Best Practices für das Testen durch alle Beteiligten verstanden wird. Dieser Prozess kann auch dazu beitragen, Unterschiede zwischen den Praktiken innerhalb der Organisation und denen der Branche zu erkennen und darauf basierend Verbesserungen zu erarbeiten.

In der DevOps-Kultur hängt die konkrete Umsetzung des Testens stark von der jeweiligen Testpraxis, der Vision für DevOps in der Organisation und der Bereitschaft zur Zusammenarbeit über die Entwicklungsteams hinaus ab. Tester müssen ihre Rolle in einem kontinuierlichen Integrations- und Bereitstellungsprozess neu definieren und aktiv die Zusammenarbeit mit anderen Disziplinen suchen. Nur so kann die Qualität der Software von Anfang an sichergestellt und gleichzeitig der gesamte Entwicklungsprozess effizienter gestaltet werden.

Wie haben frühe Seefahrer ihre Richtung bestimmt und welche Bedeutung hatten Zheng Hes Expeditionen?
Wie die S-Matrix in Streuprozessen funktioniert und ihre Rolle in der Quantenfeldtheorie
Wie man den Kontext seiner Studie etabliert und die Grundlage für eine Dissertation schafft