Helfen Sie mir, meinen Continuous Deployment-Workflow zu verbessern

Lesezeit: 8 Minuten

Benutzer-Avatar
Josh Smith

Ich habe einen Workflow zum Üben eines weitgehend automatisierten entwickelt kontinuierlicher Einsatz Zyklus für ein PHP-Projekt. Ich hätte gerne Feedback zu möglichen prozessualen oder technischen Engpässen in diesem Workflow, Verbesserungsvorschläge und Ideen zur besseren Automatisierung und Verbesserung der Benutzerfreundlichkeit für mein Team.


Kernkomponenten:


BEARBEITEN: Ich habe die Workflow-Grafik geändert, um die Beiträge von ircmaxwell zu berücksichtigen, indem ich: entferne PHPUnit‘s Erweiterung für Selenium RC und Ausführen dieser Tests nur als Teil der QC-Phase; Hinzufügen einer QC-Stufe; Verschieben von UI-Tests nach der Codeüberprüfung, aber vor Zusammenführungen; Verschieben von Zusammenführungen nach der QC-Phase; Verschieben der Bereitstellung nach der Zusammenführung.

Diese Workflow-Grafik beschreibt den Prozess. Meine Fragen / Gedanken / Bedenken folgen.

Continuous Deployment-Workflow

Meine Bedenken / Gedanken / Fragen:

  • Allgemeine Schwierigkeit bei der Verwendung dieses Systems.

  • Zeitaufwand.

  • Schwierigkeiten bei der Beschäftigung Gerrit.

  • Schwierigkeiten bei der Beschäftigung Puppet.

  • Wir werden aufstellen Amazon EC2 Instanzen später. Wenn wir über die Einrichtung gehen Debian Pakete mit Puppet und Bereitstellung an Linode Scheiben jetzt, gibt es ein Potenzial für eine funktionierende Bereitstellung auf Linode anbrechen EC2? Sollten wir stattdessen unsere Builds und Deployments auf EC2 vom Anfang an?

  • Noch eine Frage bzgl.: EC2 und Puppet. Wir erwägen auch, Scalr als Lösung zu verwenden. Wäre es so sinnvoll, den Overhead zu vermeiden Puppet allein dafür und stattdessen in Scalr investieren? Ich habe hier eine sekundäre (ha!) Sorge um die Kosten; das Selenium Tests sollten nicht ausgeführt werden das oft das EC2 Build-Instanzen laufen rund um die Uhr, aber für so etwas wie einen fünfminütigen Build zahlt man eine Stunde EC2 Verbrauch scheint ein bisschen viel.

  • Mögliche Prozessengpässe bei Zusammenführungen.

  • Könnte “A” verschoben werden?

Kredite: Teile dieses Workflows sind inspiriert von Diggs großartigem Beitrag zur kontinuierlichen Bereitstellung. Die Workflow-Grafik oben ist inspiriert vom Android OS Project.

  • Also – denken Sie, dass sich diese Art von Prozess lohnt? Mir scheint, dass für die eigentliche Entwicklung nicht mehr viel Zeit bleibt.

    – Stann

    16. Januar 2011 um 8:53 Uhr

  • @Andre Nein, es lohnt sich nicht für den Aufwand, den ich alleine in dieses System stecken müsste, wie beschrieben. Allerdings hat PHP Fog dafür eine anständige Lösung, die es wert ist, angesehen zu werden.

    – Josh Smith

    17. Januar 2011 um 3:38 Uhr


  • Mit welchem ​​Tool haben Sie dieses Workflow-Diagramm erstellt?

    – Ja

    21. Februar 2012 um 20:39 Uhr

  • @ Jason omnigroup.com/products/OmniGraffle

    – Josh Smith

    22. Februar 2012 um 21:12 Uhr

  • Eine zu reale und interessante Frage. Warum wurde es nicht geschlossen? Oder hat es? 🙂

    – mlvljr

    26. Juli 2013 um 16:30 Uhr

Wie viele Leute arbeiten daran? Wenn Sie nur vielleicht 10 oder 20 Entwickler haben, bin ich mir nicht sicher, ob es Sinn macht, einen so aufwändigen Workflow einzurichten. Wenn Sie 500 verwalten, sicher …

Mein persönliches Gefühl ist KISS. Halten Sie es einfach, dumm … Sie möchten einen Prozess, der sowohl effizient als auch noch wichtiger ist: einfach. Wenn es kompliziert ist, wird es entweder niemand richtig machen, oder Teile werden mit der Zeit verrutschen. Wenn Sie es einfach machen, wird es zur zweiten Natur und nach ein paar Wochen würde niemand den Prozess in Frage stellen (naja, die Semantik davon sowieso) …

Und das andere persönliche Gefühl ist, dass Sie immer alle Ihre UNIT-Tests durchführen. Auf diese Weise können Sie in Ihrem Flussdiagramm einen ganzen Entscheidungsbaum überspringen. Was ist schließlich teurer, ein paar Minuten CPU-Zeit oder die Gehirnzyklen, um den Unterschied zwischen dem teilweisen Bestehen des Tests und dem massiven Nichtbestehen des Tests zu verstehen. Denken Sie daran, dass ein Fehlschlag ein Fehlschlag ist, und es gibt keinen praktischen Grund dafür, dass Code jemals einem Reviewer gezeigt werden sollte, der das Potenzial hat, den Build zu scheitern.

Nun, Selen-Tests sind in der Regel ziemlich teuer, also könnte ich zustimmen, diese zu verschieben, bis der Gutachter zugestimmt hat. Aber darüber musst du nachdenken…

Oh, und wenn ich das implementieren würde, würde ich dort eine formelle QC-Phase einbauen. Ich möchte, dass sich menschliche Tester alle vorgenommenen Änderungen ansehen. Ja, Selenium kann Dinge überprüfen, über die Sie wissen, aber nur ein Mensch kann Dinge finden, an die Sie nicht gedacht haben. Führen Sie ihre Ergebnisse in neue Selenium- und Integrationstests ein, um Regressionen zu verhindern …

  • Wir sind im Moment ein sehr kleines Team, also stimme ich sicherlich zu, dass KISS der richtige Weg ist. Allerdings hätte ich gerne einen Prozess, der skalierbar ist, obwohl das nicht unbedingt bedeutet, dass er komplex ist. Im Moment besteht unser Prozess nur aus kontinuierlicher Integration und ist uns im Grunde zur zweiten Natur geworden. Schreiben und führen Sie Tests lokal aus; verpflichte dich zum Master, wenn du bereit bist; Hudson erstellt und führt Tests auf dem Server durch und erstattet Bericht. Spülen und wiederholen.

    – Josh Smith

    13. September 2010 um 19:10 Uhr

  • Denken Sie daran, dass Sie, wenn Sie Ihren Prozess von Anfang an erstellen, ihn in Abschnitten skalieren können. Im Grunde hätten Sie also eine Reihe von Phasen (z. B. Testen, Verifizieren, QC und Bereitstellen). Wenn Sie dann einen Prozess hinzufügen müssen, fügen Sie ihn dort hinzu, wo er benötigt wird. Wenn Sie feststellen, dass die Überprüfungsphase zu lange dauert oder nicht richtig funktioniert, passen Sie das an. Sie brauchen kein ausgeklügeltes System, um es zu skalieren. Sie brauchen nur ein intelligentes, einfaches System, an das die Menschen glauben. Wenn andere sich nicht engagieren, wird es nicht passieren, egal wie gut der Workflow ist …

    – ircmaxell

    13. September 2010 um 19:13 Uhr

  • Nun, meiner Meinung nach wollen Sie eine QC von Pre-Alpha bis zum Ende. Andernfalls übersehen Sie möglicherweise einen Architekturfehler, und es ist viel teurer, ihn später zu beheben. Lassen Sie Ihr QC-Team die Selen-Tests schreiben und pflegen. Auf diese Weise ist es in ihrem Interesse, sie zu schreiben (da es ihr Leben einfacher macht), und es ist ihr Problem, zu überprüfen, ob einer fehlschlägt (dass es kein falsches Positiv war). Ich bin ein Fan von “Eskalation”. Wo Sie Dev->Review->QC->Production haben. Eine Ebene kann zur nächsten übergehen, aber nicht weiter. Sobald es also aus einer Hand ist, brauchen sie sich keine Sorgen zu machen, es sei denn, sie hören zurück (und können weitermachen).

    – ircmaxell

    13. September 2010 um 19:18 Uhr

  • Jetzt, wo ich es mir anschaue, sehe ich eigentlich nicht viel, was ich loswerden könnte. Führen Sie möglicherweise auch die Sauce-Tests vor der Zusammenführung aus (da dies den Code testet) und führen Sie auch alle Komponententests aus, wenn Sie gerade die Sauce-Tests ausführen (da Sie die Zusammenführung und nicht nur die lokale Kopie testen). Ich schätze, ich zögere nur bei einem signifikanten Grad an Komplexität (sogar automatisiert), da es später schwieriger sein wird, die Automatisierung zu warten oder zu ändern … Verwenden Sie die Automatisierung einfach, aber machen Sie es nicht kompliziert, da Sie es sind an die Komplexität gebunden (und wenn etwas kaputt geht, viel Spaß) …

    – ircmaxell

    13. September 2010 um 19:36 Uhr

  • Das ist ziemlich nah an dem, was ich tun würde (der Fokus auf “Stufen”, die dedizierten QC-Schritte usw.) … Sieht für mich gut aus …

    – ircmaxell

    13. September 2010 um 20:41 Uhr

Wichtig zu machen testet extrem schnelldh kein IO und Lauffähigkeit parallel und verteilte Tests. Ich weiß nicht, wie anwendbar es mit PHP ist, aber wenn Sie Codeeinheiten mit In-Memory-DB testen und die Umgebung verspotten können, sind Sie besser dran.

Wenn Sie zwischen dem Commit und der Produktion eine QA / QC oder einen anderen Menschen im Weg haben, haben Sie ein Problem, zu einem zu gelangen vollständig kontinuierliche Bereitstellung. Der Schlüssel ist Ihr Vertrauen in Ihre Tests, Überwachung und Autoreaktion (Immunsystem), um fehleranfällige Prozesse, die Menschen entwickeln, aus Ihrem System zu eliminieren.

Alle Übergaben zwischen Funktionen bewirken eine Verlangsamung und damit eine Erhöhung der Änderungsmenge (und damit des Risikos), die mit einer Bereitstellung einhergeht.

Manuelle Quality Gates sind per Definition eine Akzeptanz dafür, dass Qualität nicht von Anfang an eingebaut wurde. Der einzige Grund, warum Code später überprüft werden muss, ist, dass einige glauben, dass die Qualität bereits nicht gut genug ist.

Aus genau diesem Grund versuche ich derzeit, die formale Codeüberprüfung aus unseren Pipelines zu entfernen. Es verursacht Rückkopplungsverzögerungen und zitiert Martin Fowler:

„Der springende Punkt der Continuous Integration ist es, schnelles Feedback zu liefern. Nichts saugt das Blut einer CI-Aktivität mehr als ein Build, der lange dauert.“

Stattdessen möchte ich eine Codeüberprüfung zu etwas machen, das die Einsender bei Bedarf anfordern oder anderweitig zum Zeitpunkt der Codierung von Teammitgliedern durchgeführt werden, vielleicht a la XP-Paar-Programmierung.

Ich denke, es sollte Ihr Ziel sein, dass der Code, sobald er mit der Quellcodeverwaltung zusammengeführt wurde, absolut vorhanden ist nein mehr manuelle Eingriffe.

Benutzer-Avatar
Eran Harel

Ich weiß nicht, ob dies für PHP relevant ist, aber Sie können zumindest einen Teil der Codeüberprüfungsphase durch statische Analysen ersetzen.

Die Qualität von Code-Reviews hängt von der Qualität der Reviewer ab, während die statische Analyse auf Best Practices und Mustern beruht und vollautomatisch erfolgt. Ich sage nicht, dass Code-Reviews aufgegeben werden sollten, ich denke einfach, dass es offline durchgeführt werden kann.

Sehen

http://en.wikipedia.org/wiki/Static_code_analysis

http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis

1217070cookie-checkHelfen Sie mir, meinen Continuous Deployment-Workflow zu verbessern

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy