Wie funktioniert Continuous Delivery in der Praxis?

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.

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).

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.

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).

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.

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.

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.