Strategien zur Abhängigkeitsförderung: isoliert oder orchestriert?

Wir haben viele Apps und Webdienste (einige öffentlich zugängliche Produkte, einige interne und Teil eines privaten "Backends"), die voneinander abhängig sind. Jede dieser Komponenten verfügt über 4 Umgebungen (Cluster von Servern / Knoten, die bestimmten Zwecken dienen):

• Nichtproduktion
  • DEV- Integrierte Entwicklungsumgebung, in der CI Push-Änderungen erstellt; nützlich für Ingenieure, um schwer zu findende Fehler zu beheben, die lokal nicht reproduzierbar sind
  • QA - Isolierte QS / Testumgebung
  • DEMO - Stabile UAT-Umgebung für Geschäftsinteressenten
• Produktion
  • LIVE - Unsere Live- / Produktionsumgebung

Code-Promotion lautet: LOCAL(Entwicklermaschine) => DEV=> QA=> DEMO=> LIVE.

Angenommen, wir haben eine Anwendung namens myapp, die von einem aufgerufenen RESTful-Webdienst unterstützt wird myws, der selbst von einer aufgerufenen Datenbank unterstützt wird mydb.

Derzeit haben wir unter diesen Abhängigkeiten eine so genannte " orchestrierte " Werbung: die myapp-devPunkte, zu myws-devdenen sie verwendet werden mydb-dev. Ebenso myapp-qaPunkte, auf myws-qadie verwendet wird mydb-qa. Gleiches gilt für DEMOund LIVE.

Das Problem dabei ist, dass ich jedes Mal, wenn ich beispielsweise eine Änderung myappvornehme, Änderungen an mywsund mydbauch vornehmen muss . Da jedoch jede DEVUmgebung auf die Umgebungen ihrer Abhängigkeiten verweist DEV, muss ich diese Änderungen alle gleichzeitig planen und einführen. Wenn ein Build instabil / defekt wird, werden häufig andere vorgelagerte Komponenten heruntergefahren. Wenn beispielsweise ein Entwickler beim Ändern etwas kaputt macht mydb-dev, werden die myws-devund myapp-dev-Cluster normalerweise auch instabil.

Um dies zu lösen, stelle ich einen Vorschlag für eine so genannte " isolierte " Werbestrategie zusammen: Alle Abhängigkeiten zwischen Komponenten folgen dieser Richtlinie:

• Upstream-Abhängigkeiten hängen von der DEMOUmgebung für ihre Downstream-Abhängigkeiten und für alle Nicht-Produktionsumgebungen ab ( DEV, QAund DEMO). und
• Upstream-Abhängigkeiten hängen von der LIVEUmgebung für ihre Downstream-Abhängigkeiten für ihre Produktionsumgebung ab

Die Verwendung dieser Konvention myapp-devwürde tatsächlich darauf hinweisen myws-demo, welche verwenden würde mydb-demo. Ebenso myapp-qawürde auch auf myws-demound verweisen mydb-demo.

Der Vorteil, den ich hier finden kann, ist die Build-Stabilisierung : Es ist viel weniger wahrscheinlich, dass die DEMOUmgebung für eine bestimmte Komponente instabil wird, da Code es nicht DEMOohne strenge Tests sowohl auf DEVals auch schafft QA.

Der einzige Nachteil, den ich bei dieser Methode feststellen kann, ist, dass, wenn DEMOfür eine bestimmte Komponente eine Unterbrechung auftritt, plötzlich alle Nichtproduktionsumgebungen für alle vorgelagerten Abhängigkeiten unterbrochen werden. Ich würde jedoch entgegnen, dass dies aufgrund der an DEVund durchgeführten Tests äußerst selten vorkommen sollte QA.

Dies hat bekommt ein Problem sein , dass viele Entwickler (viel schlauer und erfahrener als ich) gelöst haben, und ich wäre nicht überrascht, wenn dieses Problem und seine Lösungen bereits Namen zu ihnen haben (außer dem, was ich rufe orchestrierte / Silo). Also frage ich: Wiegen die Vorzüge einer isolierten Werbestrategie die Nachteile auf, und welche Nachteile kann ich hier übersehen?

Wenn ich Ihren Beitrag richtig lese, scheint dieser Vorschlag keines der angeblichen Probleme zu lösen.

Jedes Mal, wenn ich beispielsweise Änderungen an myapp vornehme, muss ich Änderungen an myws und mydb vornehmen. Da jedoch jede DEV-Umgebung auf die DEV-Umgebungen ihrer Abhängigkeiten verweist, muss ich diese Änderungen alle gleichzeitig planen und einführen

Die "alberne Werbestrategie" scheint dies nur noch schlimmer zu machen. Wenn myapp v2, myws v2 und mydb v2 nur auf DEV basieren und myapp v2 darauf angewiesen ist, dass mydb v2 nicht abstürzt, wenn ich versuche, myapp v2 auf DEV auszuführen, drücke ich mydb v1 DEMO und es stürzt ab. Sie wären im Wesentlichen gezwungen, entweder die Silos ständig zu überschreiben oder mydb v2 bis zum Produkt bereitzustellen, bevor Sie überhaupt mit der Arbeit an myapp v2 beginnen können. Noch wichtiger ist, dass Sie mydb v2 niemals auf DEV testen würden. Wenn es also kaputt ist, finden Sie es erst heraus, wenn es auf DEMO kaputt geht, und dann sind Sie wieder auf dem ersten Platz.

Bis zu einem gewissen Grad ist das von Ihnen beschriebene Problem unvermeidlich, unabhängig davon, wie Ihr Workflow eingerichtet ist, es kann jedoch minimiert werden. Der Trick besteht darin, sicherzustellen, dass die Schnittstelle zwischen mydb und myws (und die Schnittstelle zwischen myws und myapp) streng definiert ist und dass alle Aktualisierungen dieser Schnittstelle vollständig abwärtskompatibel sind . Bei meiner Arbeit haben wir ein XML-Schema, das die Schnittstelle zwischen unseren Apps und Diensten definiert, und viele unserer internen Tools lassen uns einfach keine inkompatiblen Aktualisierungen dieser Schemas vornehmen.

Wenn ein Build instabil / defekt wird, werden häufig andere vorgelagerte Komponenten heruntergefahren. Wenn beispielsweise ein Entwickler beim Ändern von mydb-dev etwas kaputt macht, werden die Cluster myws-dev und myapp-dev normalerweise ebenfalls instabil.

Dies klingt für mich nach einem ernsthaften Problem, aber nicht nach einem Bereitstellungsproblem. Eine kaputte Datenbank verhindert sicherlich, dass der Dienst und die App ordnungsgemäß funktionieren, sollte jedoch nicht "instabil" werden. Sie sollten Fehlermeldungen zurückgeben, damit jeder, der myapp auf dev ausführt, sieht "Es tut uns leid, unsere Datenbank hat heute Probleme", anstatt einfach abzustürzen.

Wenn das Problem darin besteht, dass eine kaputte Datenbank diese Probleme überhaupt verursacht, können Sie ein "temporäres Siloing" -System einrichten, mit dem Sie sagen können, dass "mydb DEV jetzt defekt ist". Bitte leiten Sie alle myws DEV-Abfragen an mydb DEMO weiter vorerst ". Dies sollte jedoch nur eine Möglichkeit sein, temporäre Korrekturen durchzuführen, bis mydb DEV wieder normal funktioniert. Wenn auf diese Weise standardmäßig alles "isoliert" ist, sind Sie wieder bei den oben beschriebenen Problemen, da niemand jemals gegen mydb DEV läuft.

Ich habe das Gefühl, dass ich Ihren Vorschlag wahrscheinlich irgendwie falsch verstehe, aber hoffentlich macht diese Antwort zumindest deutlich, was missverstanden wurde und wie man es am besten umformuliert.