Wie funktioniert Continuous Delivery in der Praxis?

22

Continuous Delivery hört sich gut an, aber meine jahrelange Erfahrung in der Softwareentwicklung legt nahe, dass es in der Praxis nicht funktionieren kann.

(Bearbeiten: Um es klar zu machen, werden immer viele Tests automatisch ausgeführt. Meine Frage ist, wie ich das Vertrauen erhalte, bei jedem Einchecken zu liefern. Ich verstehe, dass es sich um die vollständige Form der CD handelt. Die Alternative sind nicht jahrelange Zyklen Es handelt sich um wöchentliche Iterationen (die bei korrekter Ausführung für einige möglicherweise immer noch als CD betrachtet werden), zwei Wochen oder einen Monat, einschließlich einer altmodischen Qualitätssicherung am Ende jeder einzelnen, die die automatisierten Tests ergänzt.)

  • Eine vollständige Testabdeckung ist nicht möglich. Man muss viel Zeit investieren - und Zeit ist Geld - für jede Kleinigkeit. Das ist wertvoll, aber die Zeit könnte auf andere Weise für die Qualität aufgewendet werden.
  • Einige Dinge sind schwer automatisch zu testen. ZB GUI. Sogar Selen sagt Ihnen nicht, ob Ihre GUI wackelig ist. Der Datenbankzugriff ist ohne sperrige Geräte nur schwer zu testen, und selbst das wird seltsame Eckfälle in Ihrem Datenspeicher nicht abdecken. Ebenso Sicherheit und viele andere Dinge. Nur Business-Layer-Code kann effektiv in einer Einheit getestet werden.
  • Sogar in der Business-Schicht gibt es für die meisten Codes keine einfachen Funktionen, deren Argumente und Rückgabewerte zu Testzwecken einfach isoliert werden können. Sie können viel Zeit damit verbringen, Scheinobjekte zu erstellen, die möglicherweise nicht den tatsächlichen Implementierungen entsprechen.
  • Integrations- / Funktionstests ergänzen Komponententests, die jedoch viel Zeit in Anspruch nehmen, da sie in der Regel eine Neuinitialisierung des gesamten Systems bei jedem Test erfordern. (Wenn Sie nicht neu initialisieren, ist die Testumgebung inkonsistent.)
  • Refactoring oder andere Änderungen brechen viele Tests ab. Sie verbringen viel Zeit damit, sie zu reparieren. Wenn es darum geht, wichtige Spezifikationsänderungen zu validieren, ist das in Ordnung, aber oft brechen Tests wegen bedeutungsloser Implementierungsdetails auf niedriger Ebene ab, nicht wegen Dingen, die wirklich wichtige Informationen liefern. Häufig konzentriert sich die Optimierung auf die Überarbeitung der internen Daten des Tests und nicht auf die Überprüfung der getesteten Funktionalität.
  • Erfahrungsberichte zu Fehlern können nicht einfach mit der genauen Mikroversion des Codes abgeglichen werden.
Joshua Fox
quelle
Es funktioniert sehr gut für Etsy slideshare.net/OReillyOSCON/… !
YoTsumi
4
Kontinuierliche Lieferung nicht erforderlich Prüfung (aber es hilft). Es bezieht sich auf die Tatsache, dass die Dinge, die Sie regelmäßig bauen, bei Bedarf an den Kunden versendet werden KÖNNEN.
Es ist interessant, dass sich Ihre Einwände gegen die kontinuierliche Lieferung überwiegend auf das Testen als Bestandteil der CD konzentrieren. Dies ist jedoch nur ein Teil des Puzzles: Sie benötigen kompetente interne Tools, Entwickler, die sich strengen Qualitätsprüfungen verschrieben haben, einen umfassenden Priorisierungsansatz für Ihre automatisierten Tests sowie eine starke organisatorische Unterstützung. Es kann getan werden, aber es braucht eine Menge Leute, um sich für die Sache zu engagieren.
Stephen Gross
1
@Stephen Ja, ich konzentriere mich auf das Testen, da ich mich in allen anderen Aspekten einig bin. Ich bin auch für das Testen. Ich verstehe nur nicht, wie Sie genug Vertrauen haben können, um jedes Einchecken durchzuführen.
Joshua Fox
@ Thorbjørn Ravn Andersen. Auf jeden Fall scheint CD zu testen. Wie können Sie das Vertrauen haben, automatisch jeden Check-in ohne ihn zu versenden?
Joshua Fox

Antworten:

29

Meine jahrelange Erfahrung in der Softwareentwicklung legt nahe, dass es in der Praxis nicht funktionieren kann.

Hast du es versucht? Dave und ich haben das Buch auf der Grundlage unserer langjährigen Erfahrung mit ThoughtWorks geschrieben und dabei die Dinge getan, die wir besprochen haben. Nichts in dem Buch ist spekulativ. Alles, was wir besprechen, hat sich auch bei großen, verteilten Projekten bewährt. Wir raten jedoch davon ab, es im Glauben anzunehmen. Natürlich sollten Sie es selbst versuchen und bitte aufschreiben, was für Sie funktioniert und was nicht, einschließlich des relevanten Kontexts, damit andere aus Ihren Erfahrungen lernen können.

Continuous Delivery legt großen Wert auf automatisierte Tests. Wir verbringen ungefähr 1/3 des Buches damit, darüber zu reden. Wir tun dies, weil die Alternative - manuelles Testen - teuer und fehleranfällig ist und eigentlich keine großartige Möglichkeit zum Erstellen hochwertiger Software darstellt (wie Deming sagte: "Hören Sie mit der Abhängigkeit von der Masseninspektion auf, um Qualität zu erzielen. Verbessern Sie den Prozess und bauen Sie Qualität ein das Produkt an erster Stelle ")

Eine vollständige Testabdeckung ist nicht möglich. Man muss viel Zeit investieren - und Zeit ist Geld - für jede Kleinigkeit. Das ist wertvoll, aber die Zeit könnte auf andere Weise für die Qualität aufgewendet werden.

Eine vollständige Testabdeckung ist natürlich nicht möglich, aber was ist die Alternative: keine Testabdeckung? Es gibt einen Kompromiss. Irgendwo dazwischen ist die richtige Antwort für Ihr Projekt. Im Allgemeinen sollten Sie ungefähr 50% Ihrer Zeit damit verbringen, automatisierte Tests zu erstellen oder zu warten. Das mag teuer klingen, bis Sie die Kosten für umfassende manuelle Tests und die Behebung von Fehlern in Betracht ziehen, die bei den Benutzern auftreten.

Einige Dinge sind schwer automatisch zu testen. ZB GUI. Sogar Selen sagt Ihnen nicht, ob Ihre GUI wackelig ist.

Na sicher. Schauen Sie sich den Testquadranten von Brian Marick an. Sie müssen noch explorative Tests und Usability-Tests manuell durchführen. Aber genau dafür sollten Sie Ihre teuren und wertvollen Menschen einsetzen - und nicht für Regressionstests. Der Schlüssel ist, dass Sie eine Bereitstellungs-Pipeline einrichten müssen, damit Sie nur teure manuelle Überprüfungen für Builds durchführen müssen, die eine umfassende Reihe automatisierter Tests bestanden haben. Auf diese Weise reduzieren Sie sowohl den Betrag, den Sie für manuelle Tests ausgeben, als auch die Anzahl der Fehler, die es jemals zum manuellen Test oder zur manuellen Produktion geschafft haben (bis dahin ist die Behebung sehr teuer). Das automatisierte Testen, das richtig durchgeführt wird, ist über den gesamten Lebenszyklus des Produkts viel billiger, aber es ist natürlich eine Investition, die sich im Laufe der Zeit amortisiert.

Der Datenbankzugriff ist ohne sperrige Geräte nur schwer zu testen, und selbst das wird seltsame Eckfälle in Ihrem Datenspeicher nicht abdecken. Ebenso Sicherheit und viele andere Dinge. Nur Business-Layer-Code kann effektiv in einer Einheit getestet werden.

Der Datenbankzugriff wird implizit durch Ende-zu-Ende-Szenario-basierte Funktionstests für die Akzeptanz getestet. Für die Sicherheit ist eine Kombination aus automatisierten und manuellen Tests erforderlich - automatisierte Penetrationstests und statische Analysen zum Auffinden von (z. B.) Pufferüberläufen.

Sogar in der Business-Schicht gibt es für die meisten Codes keine einfachen Funktionen, deren Argumente und Rückgabewerte zu Testzwecken einfach isoliert werden können. Sie können viel Zeit damit verbringen, Scheinobjekte zu erstellen, die möglicherweise nicht den tatsächlichen Implementierungen entsprechen.

Natürlich sind automatisierte Tests teuer, wenn Sie Ihre Software und Ihre Tests schlecht erstellen. Ich empfehle dringend, das Buch "Objektorientierte Software entwickeln, die von Tests geleitet wird" zu lesen, um zu verstehen, wie dies richtig gemacht wird, damit Ihre Tests und Ihr Code im Laufe der Zeit gewartet werden können.

Integrations- / Funktionstests ergänzen Komponententests, die jedoch viel Zeit in Anspruch nehmen, da sie in der Regel eine Neuinitialisierung des gesamten Systems bei jedem Test erfordern. (Wenn Sie nicht neu initialisieren, ist die Testumgebung inkonsistent.)

Eines der Produkte, an denen ich gearbeitet habe, verfügt über eine Reihe von 3.500 End-to-End-Abnahmetests, deren Ausführung 18 Stunden dauert. Wir führen es parallel auf einem Raster von 70 Boxen aus und erhalten eine Rückmeldung in 45m. Immer noch länger als ideal, weshalb wir es als zweite Phase in der Pipeline ausführen, nachdem die Komponententests in wenigen Minuten durchgeführt wurden, damit wir unsere Ressourcen nicht für ein Build verschwenden, für das wir nicht über eine gewisse Grundstufe verfügen Selbstbewusst in.

Refactoring oder andere Änderungen brechen viele Tests ab. Sie verbringen viel Zeit damit, sie zu reparieren. Wenn es darum geht, wichtige Spezifikationsänderungen zu validieren, ist das in Ordnung, aber oft brechen Tests wegen bedeutungsloser Implementierungsdetails auf niedriger Ebene ab, nicht wegen Dingen, die wirklich wichtige Informationen liefern. Häufig konzentriert sich die Optimierung auf die Überarbeitung der internen Daten des Tests und nicht auf die Überprüfung der getesteten Funktionalität.

Wenn Ihr Code und Ihre Tests gut gekapselt und lose gekoppelt sind, werden durch das Refactoring viele Tests nicht unterbrochen. In unserem Buch beschreiben wir, wie Sie dasselbe auch für Funktionstests tun können. Wenn Ihre Akzeptanztests fehlschlagen, ist dies ein Zeichen dafür, dass Sie einen oder mehrere Komponententests verpassen. Ein Teil der CD umfasst daher die ständige Verbesserung der Testabdeckung, um zu einem früheren Zeitpunkt im Lieferprozess Fehler zu finden, bei denen die Tests detaillierter und detaillierter sind Fehler sind billiger zu beheben.

Erfahrungsberichte zu Fehlern können nicht einfach mit der genauen Mikroversion des Codes abgeglichen werden.

Wenn Sie testen und häufiger (Teil des Punktes CD) die Freigabe dann ist relativ einfach , um die Änderung zu identifizieren, die den Fehler verursacht hat . Der springende Punkt der CD ist, den Feedback-Zyklus zu optimieren, damit Sie Fehler so schnell wie möglich identifizieren können, nachdem sie in die Versionskontrolle eingecheckt wurden - und zwar vorzugsweise bevor sie eingecheckt wurden (aus diesem Grund führen wir Build- und Unit-Tests durch vor dem Check-in).

Jez Humble
quelle
Danke für deine Antwort. Ja, ich glaube an das Testen. Meine Projekte hatten eine gute Codeabdeckung durch automatisierte Tests, die mit dem täglichen Build ausgeführt wurden. Ich sage nur, dass Sie eine Art Iteration benötigen, bevor Sie freigeben. "Sie müssen noch Erkundungstests durchführen ... manuell." Ich verstehe nicht Bei jedem Einchecken wird ein vollständiges CD-System bereitgestellt. Wie können Sie das tun, wenn Sie manuelle Tests einschließen?
Joshua Fox
3
Ich unterscheide gerne zwischen kontinuierlicher Zustellung und kontinuierlicher Bereitstellung. Hier ist der Unterschied. Kontinuierliche Lieferung bedeutet, dass Sie die Anlage jederzeit produktionsbereit halten und auf Knopfdruck bei Bedarf freigeben können. Release ist eine Geschäftsentscheidung. Die fortlaufende Bereitstellung ist ein begrenzender Fall, in dem Sie jeden fehlerfreien Build freigeben (beachten Sie nicht jedes Einchecken - einige Einchecken führen nicht zu einem freigebbaren Build). In beiden Fällen können Sie manuelle Überprüfungen einschließen: Der Schlüssel ist das Konzept der Bereitstellungspipeline .
Jez Humble
Zu "Der Datenbankzugriff wird implizit durch Ihre End-to-End-Szenario-basierten Funktionstests für die Akzeptanz getestet." Das Hauptproblem ist, dass dies implizit ist . Die Leute scheinen damit zufrieden zu sein, aber dies ist ein sehr zeitraubender Ansatz. Anstatt das Problem mitzuteilen "Das habe ich von der DB erwartet und stattdessen bekommen", heißt es "Etwas ist in einer der 100 Schichten gerissen".
7.
11

Erstens erfordert CD eine große mentale Anpassung - Sie müssen zugeben, dass manchmal Dinge kaputt gehen, egal was Sie tun. Am Ende des Tages können Sie kein Negativ beweisen.

Sobald Sie dies überwunden haben, stellen Sie fest, dass Sie Tools und Verfahren benötigen, um a) diese Fehler sehr schnell abzufangen und b) entweder ein Rollback durchzuführen oder das Update sehr effizient bereitzustellen. Wenn Sie wirklich den CD-Cocktail trinken, liefern Sie tatsächlich viele kleine, gezielte Änderungen, die leicht rückgängig zu machen sind und keine größeren, anwendungsweiten Fehler verursachen sollten. Sogar die Jungs, die wirklich CD üben, handhaben größere Umstellungen auf eine traditionellere Art und Weise.

Wyatt Barnett
quelle
msgstr "kleine ... Änderungen ... sollten keine anwendungsweiten Fehler verursachen können". Dies kann auch in gut faktorisiertem Code vorkommen. Beispielsweise fügen Sie ein Div hinzu, das ein anderes Div in einem bestimmten Browser aus der Ansicht drückt. Beispielsweise wird in einem unerwarteten Eckfall ein Nullwert angezeigt, der eine Ausnahme auslöst und verhindert, dass die GUI überhaupt gerendert wird. Ja, Sie sollten, wie ich, alles Mögliche testen, aber es kommt unweigerlich zu Fehlern, und kleine Fehler können die gesamte App stören.
Joshua Fox
Sie sind jedoch immer noch leicht zu finden und zu beheben, was den Hauptschwerpunkt darstellt.
Wyatt Barnett
2

Jedes System birgt Risiken und jedes Risiko birgt potenzielle Kosten. Wenn die Kosten für ein kleines Risiko, wie es Monate oder Jahre dauern kann, um es bei umfangreichen Tests und Qualitätssicherungsmaßnahmen zu ermitteln, hoch genug sind (die Software in Ihrem Herzschrittmacher), werden Sie nicht ohne einen umfangreichen Testzeitraum für a ausgeliefert eingefrorene Version. Wenn die Ausfallkosten niedrig genug sind, versenden Sie möglicherweise ununterbrochen mit Null-Tests (Facebook-Seite Ihrer Katze).

hotpaw2
quelle
Ja. Bei den meisten Produktionsanwendungen liegt das Risiko irgendwo dazwischen. Und es scheint mir, dass das Risiko so groß ist, dass wir selbst bei automatisierten Tests nicht bei jedem Einchecken bereitstellen möchten. Es scheint, dass immer eine Runde QS benötigt wird. Aber ungefähr wöchentliche Veröffentlichungen scheinen mir machbar.
Joshua Fox
1

Eine vollständige Testabdeckung ist nicht möglich. Man muss viel Zeit investieren - und Zeit ist Geld - für jede Kleinigkeit. Das ist wertvoll, aber die Zeit könnte auf andere Weise für die Qualität aufgewendet werden.

Sie benötigen keine 100-prozentige Abdeckung, Sie müssen sich auf Ihr System verlassen können, damit Änderungen an einer Stelle nicht zu Problemen führen, für die Sie sich zuvor als erfolgreich erwiesen haben.

Einige Dinge sind schwer automatisch zu testen. ZB GUI. Sogar Selen
sagt Ihnen nicht , ob Ihre GUI wackelig ist. Der Datenbankzugriff ist ohne sperrige Geräte nur schwer zu testen, und selbst das deckt keine seltsamen Eckfälle in Ihrem Datenspeicher ab.

Der Datenbankzugriff ist jedoch trivial zu schreiben. Sie sollten nicht viele Tests auf Ihrer Datenebene benötigen, da nur Daten abgerufen und festgelegt werden. Das Wichtigste ist, sicherzustellen, dass bei einem Fehler ein Rollback ausgeführt und das Problem protokolliert wird, damit Sie es beheben können.

Ebenso Sicherheit und viele andere Dinge. Nur Business-Layer-Code kann effektiv in einer Einheit getestet werden. Sogar in der Business-Schicht gibt es für die meisten Codes keine einfachen Funktionen, deren Argumente und Rückgabewerte zu Testzwecken einfach isoliert werden können.

Dann sind viele Ihrer Funktionen / Klassen zu groß. Sie sollten so geschrieben sein, dass sie testbar sind.

Sie können viel Zeit damit verbringen, Scheinobjekte zu erstellen, die möglicherweise nicht den tatsächlichen Implementierungen entsprechen.

Die E / A des Scheinobjekts sollte jedoch den Erwartungen entsprechen. Was drin passiert ist unwichtig.

Integrations- / Funktionstests ergänzen Komponententests, die jedoch viel Zeit in Anspruch nehmen, da sie in der Regel eine Neuinitialisierung des gesamten Systems bei jedem Test erfordern. (Wenn Sie nicht neu initialisieren, ist die Testumgebung inkonsistent.)

Diese sollten nicht ständig ausgeführt werden. So wie es gebraucht wird.

Refactoring oder andere Änderungen brechen viele Tests ab. Sie verbringen viel Zeit damit, sie zu reparieren. Wenn es darum geht, wichtige Spezifikationsänderungen zu validieren, ist das in Ordnung, aber oft brechen Tests wegen bedeutungsloser Implementierungsdetails auf niedriger Ebene ab, nicht wegen Dingen, die wirklich wichtige Informationen liefern. Häufig konzentriert sich die Optimierung auf die Überarbeitung der internen Daten des Tests und nicht auf die Überprüfung der getesteten Funktionalität.

Dann ist Ihr Code zu eng gekoppelt und Ihre Tests sind schlecht geschrieben.

Erfahrungsberichte zu Fehlern können nicht einfach mit der genauen Mikroversion des Codes abgeglichen werden.

Sie sind sich nicht sicher, was Sie hier vorhaben? Wenn es einen Fehler gibt, schreiben Sie einen Test, um seine Existenz zu beweisen, und beheben Sie ihn.

CaffGeek
quelle
"Die E / A des Scheinobjekts sollten den Erwartungen entsprechen." "Das Erstellen von MOs, die eine Schnittstellenspezifikation vollständig implementieren, ist zeitaufwändig. Schlimmer noch, man muss sie kontinuierlich aktualisieren, damit der gesamte Code zweimal (einmal) geschrieben wird für die Produktion und einmal für MOs)
Joshua Fox
1

Funktioniert gut für uns, aber unsere Kunden sind größtenteils intern. Mehrere Builds werden während des Tages ausgeführt, fehlerhafte Builds werden nicht toleriert. Der Webstart-Mechanismus wird verwendet, damit Benutzer bei jedem Start die neueste Version erhalten. Eine Sache ist, dass CD viele Probleme beseitigt. Ja, Sie haben die ganze Zeit Kompatibilitätsprobleme. Da Sie jedoch jedes Mal nur kleine Änderungen bereitstellen, sind diese Probleme sehr einfach zu handhaben. Das Stresslevel der CD ist VIEL niedriger als bei großen Updates und wir mussten hoffen, dass alles richtig war, da es im Falle eines Bruchs so viel Code zu überprüfen gab.

Brian Knoblauch
quelle
-4

Um ehrlich zu sein, ALLE Software wird ständig ausgeliefert! Das Wichtigste ist, es aus der Tür zu bekommen! Bringen Sie Ihre Benutzer dazu, es zu verwenden, und priorisieren Sie die Featureanforderungen und das anschließende Bug Squashing.

"Echtes Künstlerschiff"
- Steve Jobs.

Gary Willoughby
quelle
Die Alternative zu CD sind nicht jahrelange Zyklen. Es sind Iterationen jede Woche, zwei Wochen oder einen Monat.
Joshua Fox