TODO-Kommentare mit Fristen?

51

Hintergrund

Ich arbeite in einem Team, das Bereitstellungen ohne Ausfallzeiten implementieren möchte. Wir planen eine blau / grüne Bereitstellungsstrategie, um dies zu erreichen. Eines der Dinge, die mir bei der Recherche klar werden, ist, wie kompliziert es wird, Datenbankänderungen vorzunehmen. Ein einfacher Vorgang wie das Umbenennen einer Spalte kann 3 vollständige Release-Zyklen dauern, bis sie abgeschlossen ist!

Es scheint mir, dass die vollständige Einführung einer Änderung mehrere Veröffentlichungszyklen in Anspruch nimmt und viel Potenzial für menschliches Versagen mit sich bringt. In dem verlinkten Artikel wird gezeigt, dass Codeänderungen für 2 Releases erforderlich sind und eine Datenbankmigration für 3 Releases erforderlich ist.

Was ich suche

Derzeit können wir, wenn wir uns daran erinnern möchten, etwas zu tun, ein Ticket in unserem Issue-Management-System erstellen, das Unordnung schafft und möglicherweise auch zu einem späteren Sprint oder dem Rückstand des Managements übergeht. oder wir können einen TODO-Kommentar erstellen, der wahrscheinlich komplett vergessen wird.

Was ich suche, ist eine Möglichkeit, dass ein TODO-Kommentar eine Deadline haben kann, und unser Continuous Integration-System (derzeit unentschlossen, welches wir verwenden) würde den Build ablehnen, wenn diese Deadline abgelaufen wäre.

Wenn wir beispielsweise eine Spalte umbenennen, können wir die ursprüngliche Migration für sie erstellen und anschließend zwei TODO-Kommentare, um sicherzustellen, dass die verbleibenden zwei Migrationen erstellt werden:

// TODO by v55: Create migration to move constraints to new column, remove references to old column in app
// TODO by v56: Create migration to drop old column

Dies scheint ziemlich einfach zu implementieren zu sein, aber ich frage mich, ob so etwas bereits existiert, weil ich das Rad nicht neu erfinden möchte.

Zusätzliche Gedanken

Ich habe das Gefühl, dass ich hier möglicherweise unter einem XY-Problem leide, da fortlaufende Bereitstellungen und blau / grüne Bereitstellungen als bewährte Methoden angesehen werden. Es scheint seltsam, dass ich keine Lösung finden kann, um Datenbankaktualisierungen weniger schmerzhaft zu gestalten. Wenn Sie der Meinung sind, dass ich mich komplett mit dem Falschen befasse, lassen Sie es mich bitte in einem Kommentar wissen! Das Datenbankbeispiel, das ich gegeben habe, ist jedoch nur ein Beispiel, und ich denke, dass TODO-Kommentare mit Fälligkeitsterminen auch in anderen Situationen nützlich sind. Selbst wenn ich mich dieser speziellen Situation ganz falsch nähere, würde ich wirklich gerne auf meine antworten eigentliche Frage auch. Vielen Dank!

EDIT: Ich dachte gerade an eine andere Situation, in der dies hilfreich sein könnte. Wenn Sie Feature Toggles verwenden, um Teile Ihrer App zu aktivieren, wenn sie bereit sind, müssen Sie darauf achten, sie zu bereinigen, da Sie andernfalls möglicherweise Toggle Debt erhalten . Kommentare mit Fristen könnten eine gute Möglichkeit sein, sich daran zu erinnern.

Joshua Walsh
quelle
19
Das Thema TODO ist mehr eine Frage der Disziplin als des Werkzeugs.
Brandon
16
Ich denke, alle Menschen machen Fehler, und Werkzeuge können ein guter Weg sein, dies zu mildern.
Joshua Walsh
3
Wie wäre es damit, dies programmatisch zu tun? Ich meine, schreiben Sie in einem Klassenmitglied Ihre Version. Wenn die App nicht gestartet werden kann, wenn die Version gleich ist == 56 mit der Meldung "Klasse y", muss diese Funktion verfügbar sein. Sie können eine Liste solcher Meldungen erstellen. Was denkst du?
Tomer Ben David
6
An die Neinsager gerichtet, stimme ich nicht zu: Unsere Codebasis stützt sich auf viele andere Komponenten, an denen wir nicht arbeiten, sodass wir TODO <Bug#>:Workarounds für Probleme mit anderen Komponenten nachverfolgen können . Wenn ein Fehler in einer dieser Komponenten behoben ist, können Sie die entsprechenden Problemumgehungen leicht finden und beheben. Es ersetzt keinen Issue Tracker und erleichtert die Wartung.
TemporalWolf

Antworten:

53

Diese Frage ist wirklich zwei Fragen in einer.

Todo kommentiert

Dies ist die schlechteste Möglichkeit, Aktionselemente zu verfolgen. TODO-Kommentare eignen sich gut für die aktive Arbeit oder als Anregung für einen Betreuer: "Hier ist etwas, das möglicherweise in Zukunft verbessert werden könnte." Wenn Sie sich jedoch auf TODO-Kommentare verlassen, um die Arbeit zu erledigen, sind Sie zum Scheitern verurteilt.

Was tun?

Bei TODO-Kommentaren handelt es sich im Grunde genommen um technische Schulden. Sie sollten daher wie jede andere technische Schuld behandelt werden. Nehmen Sie sie sofort in Angriff, wenn Sie Zeit haben, oder stellen Sie sie in den Rückstand, damit sie nachverfolgt und priorisiert werden können.

Im Allgemeinen können TODO-Kommentare als Code-Geruch betrachtet werden, und dies ist völlig einsichtig und offen für Debatten. Wenn ein TODO-Kommentar es bis zum Einchecken in die Versionskontrolle schafft, müssen Sie sich fragen, ob Sie ihn jetzt tatsächlich ausführen werden? Wenn nicht, ist das in Ordnung. Sei einfach ehrlich zu dir selbst und schreibe es in den Rückstand.

Wie Sie diesen Rückstand bewältigen, hängt vom Geschäftsprozess, der Unternehmenspolitik und möglicherweise von einer gewissen persönlichen Autonomie ab. Sie benötigen jedoch weiterhin einen nachverfolgten und priorisierten Rückstand, um sicherzustellen, dass dies geschieht.

Datenbankänderungen

Ja, Datenbankänderungen sind schwierig, da keine Ausfallzeiten gelten. Einige Tricks, um die Schmerzen zu lindern:

Post-Deployment-Prozess

Erstellen Sie einen Post-Deployment-Prozess, der als Teil derselben Version ausgeführt wird. Sie möchten jedoch, dass es funktioniert. Auf dem letzten System, an dem ich gearbeitet habe, habe ich eine 4-Phasen-Bereitstellung entworfen:

  1. Preapp-Datenbank-Skripte
  2. Web-Apps
  3. PostApp-Datenbank-Skripte
  4. Wartungsfenster-Datenbank-Skripte

Die Idee war, dass wir, wo immer möglich, so viele Datenbankänderungen wie möglich in Preapp umsetzen.

Postapp war für die ungewöhnlichen Fälle reserviert, in denen wir inkompatible Schemaänderungen vornehmen mussten. In diesen Fällen würde die Voranwendung eine ausreichende Menge an Änderungen vornehmen, um den neuen Anwendungscode kompatibel zu machen (möglicherweise wird eine temporäre Ansicht zur Kompatibilität erstellt), und die Nachanwendung würde solche temporären Artefakte bereinigen.

Die Wartungsfensterphase war Änderungen vorbehalten, die Ausfallzeiten erforderten oder bei denen sich das Risiko oder die Kosten einer Live-Bereitstellung nicht gelohnt hatten. Beispielsweise müssen Skripts, die große Datenmengen ändern, möglicherweise eine gesamte Tabelle sperren.

Häufig bereitstellen

Wenn Sie häufig genug neue Releases bereitstellen, können Sie einen Punkt erreichen, an dem das Übertragen einer Änderung auf zwei oder drei Releases trivial ist. Lange Veröffentlichungszyklen erhöhen die Kosten für Datenbankänderungen.

Brandon
quelle
18
Todo-Kommentare sind eine schreckliche Möglichkeit, die Arbeit zu verfolgen und zu priorisieren. Sie sind eine gute Möglichkeit zu erklären, warum ein halbfertiges Stück Code im Wind flattern kann. In einer perfekten Welt macht das kein Code. In diesem ...
candied_orange
6
... es ist manchmal schön, eine Möglichkeit zu haben, technische Schulden nachzuverfolgen, die sich nicht verbergen lässt, wenn man die Prioritäten gegenüber dem Chef herabsetzt. Sicher, Sie erhalten keine Gutschrift für die Behebung. Manchmal reparierst du es trotzdem.
candied_orange
3
Die Strategie für Post-App lautet also, dass diese Migrationen ausgeführt werden, sobald die App-Bereitstellung erfolgreich abgeschlossen wurde. Was ist mit dem Code? Angenommen, Sie benennen eine Spalte von Nachname in Nachname um. Ihr alter Code verwendet Nachname. Sie migrieren die Datenbank, um den Nachnamen hinzuzufügen, und ändern Ihren Code, um den Nachnamen zu verwenden, sofern dieser verfügbar ist, andernfalls den Nachnamen. Nachdem die Bereitstellung vollständig bereitgestellt wurde, führen Sie die nächste Migration aus, indem Sie die alte Spalte last_name löschen. Ihr Code enthält jedoch immer noch den Code für last_name, der jetzt nicht verwendet wird und daher eine technische Verschuldung darstellt. Wie erzwingen Sie das Aufräumen?
Joshua Walsh
3
Während das Verwalten von Aktionselementen in Kommentaren in der Tat eine schreckliche Sache ist, kann das automatische Erstellen von Problemen in einem Tracking-System ein gutes Werkzeug sein, um dies nicht zu vergessen, da Sie gerade dabei sind, etwas zu codieren und nicht hart wechseln möchten Zusammenhang mit dem Issue-Tracking-System.
PlasmaHH
6
IMHO dieser Antwort fehlt der Punkt. Das OP forderte eine Lösung, bei der das CI das Team benachrichtigt, wenn eine wichtige Bereinigung vergessen wurde, ohne das "Issue Management System" zu überfrachten (TODO-Kommentare waren nur ein Beispiel, möglicherweise nicht die ideale Lösung dafür). Das OP gab einige gute Gründe an, warum er es aus diesem Grund nicht verwenden möchte. Dennoch schlägt diese Antwort vor, sich vollständig auf den Rückstand zu verlassen, der im Falle des OP nichts anderes ist als sein "Issue Management System". Also meiner Meinung nach ignoriert diese Antwort den Kern der Frage und präsentiert keine Lösung.
Doc Brown
24

Verwenden Sie keine TODOs. Sie haben bereits eine TODO-Liste in Ihrem Projekt. Es heißt Issue Tracker.

Ich denke, das eigentliche Problem liegt in diesem Satz:

Wir können in unserem Issue-Management-System ein Ticket erstellen, das für Unordnung sorgt und möglicherweise auch von der Verwaltung zu einem späteren Sprint oder zum Rückstand verschoben wird.

Wenn Ihr Issue-Tracker zu viele Probleme verursacht, suchen Sie nach Möglichkeiten, dies zu beheben. Vielleicht eine Sonderausgabe, die weniger Zeremonie erfordert. Vielleicht Unterprobleme. Vielleicht weniger Zeremonie insgesamt. Wir können es nicht wirklich sagen. Wenn Ihr Issue-Tracker jedoch so viel Arbeit verursacht, dass die Leute in einem öffentlichen Forum eher eine ausführliche Frage formulieren, als nur dieses Problem hinzuzufügen, stimmt etwas nicht.

Wenn Ihr Management den letzten Teil einer Aufgabe übermäßig verzögert, haben Sie zwei Möglichkeiten:

  1. Sprechen Sie mit Ihrem Management, warum dies eine schlechte Idee ist.

  2. behandeln Sie es als eine einzige Aufgabe. Dies könnte die Goldstandardlösung sein. In einer perfekten Welt sollten Sie in der Lage sein, die drei in jedem Schritt erforderlichen Änderungen vorzunehmen. Wenden Sie einen Zweig auf den Master-Zweig an, lassen Sie ihn erstellen und bereitstellen. Wenden Sie in der Zwischenzeit die zweite auf den Master-Zweig an, lassen Sie ihn erstellen und bereitstellen und so weiter, damit alles im selben Sprint abläuft. Wenn dies nicht der Fall ist, wird dies nicht ausgeführt. Vielleicht macht sogar etwas Automatisches Sinn, wenn Sie logischerweise eine Bereitstellung durchführen, aber es ist tatsächlich in 3 aufgeteilt.

Jens Schauder
quelle
Guter Rat, ich werde mir überlegen, wie wir das Issue-Management-System für diesen Zweck einsetzen können. Ich mag auch die Idee "Vielleicht macht sogar etwas Automatisches Sinn, wenn Sie logischerweise eine Bereitstellung durchführen", und ich versuche darüber nachzudenken, wie wir das tun können. Ich bin mir nicht sicher, ob es realistisch möglich ist.
Joshua Walsh
11
Es ist völlig vernünftig, Kommentare zum Formular zu haben // TODO(#12345): Frobnicate the sprocket before passing it along, vorausgesetzt, Fehler # 12345 ist eine "echte" Ausgabenummer und die Ausgabe ist jemandem zugewiesen. Dies erleichtert das Lesen der Quelle, indem klargestellt wird: "Nein, der Frobnikat-Schritt verbirgt sich nicht in einer der Hilfsmethoden, sondern ist einfach unimplementiert. Weitere Informationen finden Sie unter Fehler # 12345." Im Idealfall wird die Codebasis täglich nach geschlossenen oder ungültigen Ausgabenummern durchsucht.
Kevin
9

Was ich suche, ist eine Möglichkeit, dass ein TODO-Kommentar eine Deadline haben kann, und unser Continuous Integration-System (derzeit unentschlossen, welches wir verwenden) würde den Build ablehnen, wenn diese Deadline abgelaufen wäre.

Was Sie verlangen, ist machbar, wenn Sie bereit sind, die Arbeit zu erledigen und durchzuhalten.

// TODO by v55: Erstellen Sie eine Migration, um Einschränkungen in eine neue Spalte zu verschieben. Entfernen Sie Verweise auf die alte Spalte in der App. // TODO by v56: Erstellen Sie eine Migration, um die alte Spalte zu löschen

grep für //TODO by v55wann es Zeit ist, v55 bereitzustellen. Deploy Build führt ein Skript aus, das dies als Integrationstest ausführt.

Sie können 55 in Ihre Versionsverfolgung einbinden oder nur danach fragen.

Es wird interessant, wenn Sie bei 55 nach // TODO by v54 suchen möchten. Suchen Sie stattdessen 55-mal in der Codebasis nach // TODO by. Filtern Sie das Ergebnis dann nach 1 bis 55. Jetzt löst 56 keinen Fehler aus.

Sie könnten denken "Oh, das werden wir nicht brauchen. Wir werden dies jedes Mal beheben, solange wir den Scheck haben". Nein, wirst du nicht.

kandierte_orange
quelle
4
Andernfalls werden hier keine Empfehlungen gegeben.
candied_orange
3
Wenn es einen generischen Namen für diese Art von Dingen gibt, der angegeben werden kann, aber wenn Sie die Seite lesen, auf der Sie die Zeile mit den Empfehlungen verlinkt haben, weisen Sie darauf hin: softwareengineering.meta.stackexchange.com/a/6487/131624
candied_orange
6
Um es klar zu sagen, es ist Ihr Kommentar, den ich eher ablehne als die ganze Frage.
candied_orange
2
@YM_Industries SE-Sites sind in der Regel in sich geschlossen. Empfehlungen sind im Grunde einfache Antworten mit Links zu externen Sites. Sie können auch anstelle eines Links googeln, aber am Ende ist es dasselbe. Sie können ablaufen und tot werden. Eine Frage zur Empfehlung ist also nicht zum Thema, aber wenn jemand ein Tool als Ergänzung einer Antwort oder eines einfachen Kommentars erwähnen möchte, kann er dies tun.
Walfrat
2
"Ich habe mich gefragt, ob es eine vorhandene Lösung gibt" - fragen Sie uns bei softwarerecs.stackexchange.com
Mawg
4

Wir hatten ein sehr ähnliches Problem in unserem Team. Um dieses Problem zu lösen, haben wir eine statische Analyseprüfung geschrieben, die diese TODOs durch Überprüfen des JIRA-Problems oder des Git-Problems, auf das sie verweisen, behandelt. Unser Build schlägt fehl, wenn das angegebene Problem über die Spalte "In Entwicklung" hinausgeht.

Deshalb können wir bequem TODO's haben, ohne uns Sorgen machen zu müssen, dass sie vergessen werden.

Ich habe eine Open-Source-Implementierung davon in Java erstellt. Ja, ein Haftungsausschluss ist, dass ich das geschrieben habe, aber wie ich schon sagte, es ist komplett Open Source und lizenziert.

Das Tool heißt Westie und ein Beispiel für den Jira-Issue-Checker finden Sie in der README.md. Siehe auch den GitIssueAnalyser.

Wenn Sie weitere Fragen haben, senden Sie mir eine Nachricht, um die Eigenwerbung zu verhindern. Wenn Sie es verwenden möchten und Vorschläge haben, wenden Sie sich bitte an github.

tjheslin1
quelle
1
Das ist cool! Wir verwenden auch JIRA, ich könnte dies untersuchen. Es behebt nicht wirklich meine Bedenken, Unordnung in unserem Issue-Management-System zu schaffen, aber es wird zumindest garantieren, dass sie nicht vergessen werden können.
Joshua Walsh
@YM_Industries Ich bin froh. Ich würde mich freuen, Beiträge entgegenzunehmen oder an den angesprochenen Themen zu arbeiten.
tjheslin1
4

Nicht zu tun. Mach es jetzt.

TLDR: Schreiben (und testen) Sie Ihre DB-Skripte jetzt und nicht später. Codieren Sie sie einfach, damit ihre Ausführung von der DB-Version abhängt.

Beispiel

Stellen Sie sich zum Beispiel vor, Sie möchten einen Spaltennamen von SSNin ändern. Dies TaxIDist eine häufige Anforderung, wenn Sie international arbeiten.

Um dies zu erreichen, haben Sie möglicherweise vorübergehend eine TaxIDund eine SSNSpalte. Und während beide Versionen unterstützt werden, haben Sie einen Auslöser, um eine Aktualisierung von der anderen durchzuführen. Sie möchten diesen Auslöser jedoch nicht auf unbestimmte Zeit beibehalten. Wenn später keine Rückwärtskompatibilität mehr erforderlich ist, möchten Sie, dass dieser Auslöser entfernt wird (und die SSNSpalte gelöscht wird). Wir werden das alles im Voraus codieren, ohne ToDo-Elemente zu benötigen.

In unserem Beispiel werden wir Build 102 (mit der neuen Spalte) implementieren und gleichzeitig die Kompatibilität mit Build 101 (ohne diese Spalte) aufrechterhalten.

Hier sind die Schritte.

1. Richten Sie die Versionierungstabelle ein

  1. Fügen Sie eine einzelne Tabelle Configurationmit zwei Spalten hinzu, Nameund Value.

  2. Fügen Sie eine Zeile mit Nameder Bezeichnung "TargetVersion" hinzu und stellen Sie die Valueauf die Version des neuen Builds ein, der bereitgestellt werden soll.

  3. Fügen Sie eine Zeile mit dem NameWert "CompatibleWith" hinzu, und legen Sie Valuedie Mindestversionsnummer fest, mit der die Bereitstellung kompatibel sein muss.

Überprüfen und aktualisieren Sie diese Zeilen vor jeder Bereitstellung.

2. Ändern Sie die Bereitstellungsskripts

  1. Fügen Sie ein Skript hinzu, das TaxIDnebeneinander eine neue Spalte von erstellt SSNund diese aus der SSNSpalte auffüllt. Schließen Sie diesen Code in eine IfAnweisung ein, die TargetVersion überprüft. Wenn die Zielversion zu niedrig ist (dh die TaxIDnoch nicht benötigt wird), überspringen Sie.

    SELECT @TargetVersion = TargetVersion FROM Configuration
    IF @TargetVersion < '102' THEN RETURN
    ALTER TABLE Customer ADD COLUMN taxID VarChar(12) NOT NULL
    UPDATE Customer SET TaxID = SSN
    
  2. Fügen Sie ein Skript hinzu, das einen Auslöser erstellt, der TaxIDbeim Einfügen oder Aktualisieren ausgefüllt wird, SSNund umgekehrt. Fügen Sie diesen Code in eine IfAnweisung ein, die die Zielversion und die kompatible Version überprüft. Überspringen, wenn TargetVersion zu niedrig ist (das TaxIDwird nicht benötigt) oder wenn die CompatibleWith-Version zu hoch ist (das SSNFeld wird nicht benötigt).

    SELECT @TargetVersion  = TargetVersion,
           @CompatibleWith = CompatibleWith 
    FROM Configuration
    IF @TargetVersion  < '102' THEN RETURN
    IF @CompatibleWith > '101' THEN RETURN
    CREATE TRIGGER SSNAndTaxIDTrigger ON Customer etc.
    
  3. Fügen Sie ein Skript hinzu, um die SSNSpalte zu entfernen . Fügen Sie eine IfAnweisung ein, die die Spalte nur dann entfernt, wenn die CompatibleWith-Version hoch genug ist ( SSNnicht mehr benötigt wird).

    SELECT @CompatibleWith = CompatibleWith FROM Configuration
    IF @CompatibleWith <= '101' THEN RETURN
    IF OBJECT_ID('SSNAndTaxIDTrigger') IS NOT NULL DROP TRIGGER SSNAndTaxIDTrigger
    IF EXISTS (SELECT * FROM syscolumns c JOIN sysobject o ON o.id = c.is WHERE o.Name = 'Custeomr' AND c.Name = 'SSN') BEGIN
        ALTER TABLE Customer DROP COLUMN SSN
    END
    

3. Testen

Stellen Sie sicher, dass Sie Ihre Bereitstellung mit einer beliebigen Kombination von Blau- / Grün-Versionsnummern testen, die Sie in der Produktion unterstützen möchten. Sie können testen, sobald der Code fertig ist, indem Sie die ConfigurationTabelle in Ihrer QA-Umgebung bearbeiten.

4. In Ihrem Bereitstellungs-Playbook

Fügen Sie einem Bearbeiter einen Schritt hinzu, um die Zeilen CompatibleWith-Version und TargetVersion zu aktualisieren. Wenn Sie auf Blau bereitstellen, setzen Sie TargetVersion auf die Versionsnummer von Blau und CompatibleWith auf die Versionsnummer von Grün. kehren Sie sie um, wenn Sie Green einsetzen.

Fallstricke

Es ist in Ordnung, dass Ihre Implementierungsskripten auf die in dieser DB-Tabelle enthaltenen Versionsnummern verweisen und sich darauf verlassen. NICHT Laufzeitcode.

Wenn Sie mit dem Schreiben Ihres Laufzeitcodes beginnen, um die Versionsnummern zu überprüfen, führt dies zu einer neuen Komplexität in Ihrer Anwendung, die möglicherweise zu einem großen Problem bei der Wartbarkeit führen kann. Jeder Laufzeit-Ausführungspfad muss getestet werden. Wenn Sie diese Zustände in Zukunft fortführen, muss die Qualitätssicherung eine Schmerzmatrix zusammenstellen , um sie bei jeder Veröffentlichung zu validieren. Mein Rat ist, Bedingungen wie diese nur in Bereitstellungsskripten beizubehalten.

Das Ergebnis all dessen

Am Ende sollten Sie in der Lage sein, den gesamten Code im Voraus zu schreiben (und ihn auch zu testen), ohne befürchten zu müssen, dass er zu früh ausgeführt wird. Außerdem bereinigt der Code den Abwärtskompatibilitäts-Trigger, wenn der Zeitpunkt gekommen ist, ohne dass Sie sich weitere Sorgen machen müssen.

Auf diese Weise können Sie den gesamten Code im Voraus schreiben und testen, wenn Sie darüber nachdenken, und müssen sich nicht mit diesen unordentlichen Aufgabenkommentaren befassen.

John Wu
quelle
Ich mag diesen Ansatz sehr, er ist eleganter als ToDo-Kommentare. Kurz nachdem ich diese Frage gestellt hatte, habe ich darüber nachgedacht, einen weiteren Beitrag zu verfassen, in dem ich gefragt habe, wie dies am besten umgesetzt werden kann, aber ich dachte mir, ich würde zuerst meine eigene Forschung betreiben. Der Trick für uns ist, dass wir Phinx für unsere Datenbankmigrationen verwenden und dies nicht wirklich unterstützen. Wenn ich Zeit habe, suche ich nach einer Möglichkeit, sie zu erweitern, um diese Art von Workflow zu unterstützen. Dieser Ansatz behebt nicht das Problem, wie sichergestellt werden kann, dass der Abwärtskompatibilitätscode aus meiner App-Schicht entfernt wird, ist jedoch elegant für das DB-Problem.
Joshua Walsh
1

Ihre TODO-Idee stößt auf großen Widerhall, aber ich persönlich sehe kein Problem damit. Am Ende besteht der beste (und einfachste) Weg, um sicherzustellen, dass die Migration in die Produktion geht, darin, einen Komponententest nicht zu bestehen, wenn dies nicht der Fall ist. Es dauert buchstäblich weniger als eine Minute, um eine leere Migrationsfunktion zu löschen, die eine Ausnahme auslöst, wenn die Version 55 oder höher ist (oder welche Anforderungen auch immer).

Wenn Sie dann versuchen, es freizugeben, ist der Test fehlgeschlagen, und jemand muss diese Ausnahme in einen tatsächlichen Migrationscode umwandeln.

Eternal21
quelle
1
Ja, ich hatte im Idealfall gehofft, einen abgelaufenen TODO als fehlgeschlagenen Test zu behandeln. Das Ausmaß des Pushbacks gegen TODOs hat mich ein wenig überrascht. Ich weiß, dass sie kein Ersatz für ein Issue-Management-System sind, aber angesichts der Verbreitung von TDD / BDD ist klar, dass es kein wirkliches Problem gibt, Anforderungen im Code zu definieren und Code zur Durchsetzung zu verwenden Feature-Vervollständigung.
Joshua Walsh
-2

Niemand scheint sich auf die Wurzel seiner Beschwerde zu konzentrieren, die darin besteht, dass Datenbankänderungen zu viele Veröffentlichungszyklen in Anspruch nehmen können. Er möchte seinen blau / grünen Bereitstellungsplan fortsetzen, und die Lösung sollte bereits vorhanden sein. Wenn ich jedoch etwas vermisse, scheint seine Beschreibung darauf hinzudeuten, dass es nur eine Datenbank gibt, die von beiden Systemen gemeinsam genutzt wird. Kein echtes Blau / Grün-System, wenn das der Fall ist. Da es den Anschein hat, dass die Datenbank der lange Pfahl im Zelt ist, sollte sie auch dupliziert werden, damit die Datenbankänderungen auf dem Offline-System unabhängig von der Dauer oder der Anzahl der Veröffentlichungszyklen erst nach Abschluss und in Betrieb genommen werden vollständig getestet. In der Zwischenzeit können Offlinesystem-Skripte die Offlinedatenbank täglich vollständig aktualisieren.

mpiazza
quelle
1
Das Replizieren der Datenbank in einer blau / grünen Bereitstellung verursacht viele Kopfschmerzen. Wenn sich mein Produkt in einem Bereich zwischen Blau und Grün befindet (z. B. 50% Lastverteilung auf beide), muss der Replikationscode beide Datenbanken synchron halten, auch wenn die Schemata unterschiedlich sind. Nach meinen Recherchen scheinen die meisten Menschen in der realen Welt eine gemeinsame DB-Instanz zwischen ihren blauen und grünen Stapeln zu haben. Ich sehe dies nicht als großes Problem an, solange die Datenbankmigrationen ziemlich schnell sind. Blau / Grün-Stapel müssen von Natur aus einige Ressourcen gemeinsam nutzen, zumindest den Load Balancer / Reverse Proxy.
Joshua Walsh