Komentarze do zrobienia w terminach?

51

tło

Pracuję w zespole, który chce wdrożyć wdrożenia bez przestojów. Aby to osiągnąć, planujemy zastosować niebiesko-zieloną strategię wdrażania. Jedną z rzeczy, które zdaję sobie sprawę z przeprowadzania badań, jest to, jak skomplikowane jest wprowadzanie zmian w bazie danych. Prosta operacja, taka jak zmiana nazwy kolumny, może potrwać 3 pełne cykle wydania, aż do jej zakończenia!

Wydaje mi się, że pełne wdrożenie zmiany wymagającej wielu cykli wydawniczych wprowadza wiele potencjalnych błędów ludzkich. W połączonym artykule pokazuje, że zmiany kodu są konieczne dla 2 wydań, a migracja bazy danych jest wymagana dla 3 wydań.

Czego szukam

Obecnie, jeśli chcemy coś zrobić, możemy utworzyć bilet w naszym systemie zarządzania problemami, który tworzy bałagan, a także może zostać przeniesiony do późniejszego sprintu lub zaległości przez kierownictwo; lub możemy utworzyć komentarz do zrobienia TODO, o którym prawdopodobnie całkowicie zapomnimy.

To, czego szukam, to sposób, w jaki komentarz TODO może mieć przed sobą termin, a nasz system ciągłej integracji (obecnie niezdecydowany, którego użyjemy) odrzuci kompilację, jeśli ten termin upłynie.

Na przykład, jeśli zmienimy nazwę kolumny, możemy utworzyć dla niej początkową migrację, a następnie dwa komentarze DO ZROBIENIA, aby zapewnić utworzenie pozostałych dwóch migracji:

// 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

Wydaje się to dość proste do wdrożenia, ale zastanawiam się, czy coś takiego już istnieje, ponieważ nie chcę ponownie wymyślać koła.

Dodatkowe przemyślenia

Wydaje mi się, że mogę tu mieć problem z XY, biorąc pod uwagę, że wdrażanie cykliczne i wdrożenia niebiesko-zielone są uważane za najlepszą praktykę, wydaje się dziwne, że nie mogę znaleźć rozwiązania, które sprawi, że aktualizacje bazy danych będą mniej bolesne. Jeśli uważasz, że szukam całkowicie złej rzeczy, daj mi znać w komentarzu! To powiedziawszy, przykład bazy danych, który podałem, jest tylko jednym przykładem i myślę, że komentarze TODO z terminami byłyby przydatne również w innych sytuacjach, więc nawet jeśli podejdę do tej konkretnej sytuacji zupełnie źle, naprawdę chciałbym odpowiedzieć na moje aktualne pytanie. Dzięki!

EDYCJA: Właśnie pomyślałem o innej sytuacji, w której może to być pomocne. Jeśli używasz funkcji przełączania funkcji do włączania części aplikacji, gdy są one gotowe, musisz uważać, aby je wyczyścić, w przeciwnym razie możesz skończyć z funkcją przełączania długu . Komentarze z terminami mogą być dobrym sposobem na zapamiętanie tego.

Joshua Walsh
źródło
19
Problem TODO jest bardziej kwestią dyscypliny niż oprzyrządowania.
Brandon
16
Myślę, że wszyscy ludzie popełniają błędy, a oprzyrządowanie może być dobrym sposobem na złagodzenie tego.
Joshua Walsh
3
Co powiesz na robienie tego programowo? Mam na myśli napisanie członkom klasy swojej wersji. Nie można uruchomić aplikacji, jeśli wersja jest równa == 56 z komunikatem „klasa y” musi mieć tę funkcję, możesz mieć listę takich wiadomości. Co myślisz?
Tomer Ben David
6
Nie zgadzam się z reżyserami: „nie” - nasza baza kodu opiera się na wielu innych komponentach, nad którymi nie pracujemy, dlatego używamy TODO <Bug#>:do śledzenia obejść problemów z innymi komponentami. Po usunięciu błędu w jednym z tych elementów można łatwo znaleźć i rozwiązać odpowiednie obejścia. Nie zastępuje narzędzia do śledzenia problemów, ułatwia konserwację.
TemporalWolf

Odpowiedzi:

53

To pytanie to tak naprawdę dwa pytania w jednym.

Komentarze Todo

Ze wszystkich sposobów śledzenia przedmiotów akcji jest to najgorsze. Komentarze do zrobienia TODO są dobre podczas aktywnej pracy lub jako sugestia dla opiekuna: „oto coś, co można poprawić w przyszłości”. Ale jeśli polegasz na komentarzach TODO do wykonania pracy, jesteś skazany na porażkę.

Co z tym zrobić

Komentarze do zrobienia TODO są zasadniczo długiem technicznym, dlatego należy traktować je jak każdy inny dług techniczny. Zajmij się nimi od razu, jeśli masz czas, lub umieść je w zaległościach, aby można je było śledzić i ustalać priorytety.

Ogólnie rzecz biorąc, i to jest całkowicie opiniotwórcze i otwarte na debatę, komentarze TODO można uznać za zapach kodu. Jeśli komentarz do zrobienia pozwala na sprawdzenie wersji, musisz zadać sobie pytanie, czy naprawdę zamierzasz teraz to zrobić? Jeśli nie, to w porządku. Bądź ze sobą szczery i umieść go w zaległościach.

Sposób zarządzania tym zaległościami sprowadza się do procesów biznesowych, polityki firmy i być może osobistej autonomii. Ale nadal potrzebujesz śledzonego i nadanego priorytetowi zaległości, aby mieć pewność, że tak się stanie.

Zmiany w bazie danych

Tak, zmiany w bazie danych są trudne przy zastosowaniu zasady zerowego przestoju. Kilka sztuczek, dzięki którym będzie mniej bolesne:

Proces po wdrożeniu

Utwórz proces po wdrożeniu, który działa jako część tej samej wersji. Jakkolwiek chcesz, żeby to działało. W ostatnim systemie, nad którym pracowałem, zaprojektowałem wdrożenie 4-fazowe:

  1. skrypty bazy danych preapp
  2. internetowe aplikacje
  3. skrypty bazy danych postapp
  4. skrypty bazy danych okna konserwacji

Pomysł polegał na tym, że tam, gdzie to możliwe, wprowadzaliśmy jak najwięcej zmian w bazie danych do preappa.

Postapp był zarezerwowany dla nietypowych przypadków, w których musieliśmy wprowadzić niezgodne zmiany schematu. W takich przypadkach preapp wprowadziłby wystarczającą zmianę, aby nowy kod aplikacji był kompatybilny (być może stworzenie tymczasowego widoku zgodności), a postapp wyczyściłby wszelkie tymczasowe artefakty.

Faza okna konserwacji była zarezerwowana dla zmian, które naprawdę wymagały przestoju lub w których ryzyko lub koszt wdrożenia na żywo nie było tego warte. Na przykład skrypty zmieniające ogromne ilości danych mogą wymagać zablokowania całej tabeli.

Wdrażaj często

Jeśli wdrażasz nowe wersje wystarczająco często, możesz osiągnąć punkt, w którym przenoszenie zmian w 2 lub 3 wersjach jest banalne. Długie cykle wydawnicze zwiększają koszty zmian w bazie danych.

Brandon
źródło
18
Komentarze Todo to straszny sposób na śledzenie i ustalanie priorytetów pracy. Są ważnym sposobem na wyjaśnienie, dlaczego na wpół skończony fragment kodu trzepocze na wietrze. W idealnym świecie żaden kod tego nie robi. Tymczasem w tym ...
candied_orange
6
... czasem miło jest mieć sposób na śledzenie długu technicznego, którego nie może ukryć żadna deprioryzacja od szefa. Na pewno nie dostaniesz kredytu za naprawę. Czasami i tak to naprawiasz.
candied_orange
3
Więc strategia z aplikacjami po aplikacji polega na tym, że migracje są uruchamiane po pomyślnym wdrożeniu aplikacji? Co z kodem? Powiedzmy, że zmieniasz nazwę kolumny z nazwiska na nazwisko. Twój stary kod używa nazwiska. Dokonujesz migracji bazy danych, aby dodać nazwisko, i zmieniasz kod, aby używał nazwiska, jeśli jest dostępne, w przeciwnym razie nazwisko. Po pełnym wdrożeniu wdrożenia kolejną migrację upuść starą kolumnę ostatnia nazwa. Ale twój kod nadal zawiera kod dla nazwiska, który jest teraz nieużywany, a zatem techniczny dług. Jak wymusić czyszczenie tego?
Joshua Walsh
3
Chociaż zarządzanie elementami akcji w komentarzach jest naprawdę okropnym sposobem, posiadanie komentarzy automatycznie powodujących problemy w systemie śledzenia może być dobrym narzędziem, aby nie zapomnieć o tym, ponieważ jesteś w trakcie programowania i nie chcesz mocno zmieniać kontekst do systemu śledzenia problemów.
PlasmaHH
6
IMHO ta odpowiedź nie ma sensu. OP poprosił o rozwiązanie, w którym CI powiadomi zespół, gdy zapomniano o ważnej procedurze porządkowej, bez zaśmiecania „systemu zarządzania problemami” (komentarze TODO były tylko przykładem, a może nie idealnym rozwiązaniem do tego). OP podał kilka dobrych powodów, dla których nie chce z niego korzystać. Niemniej jednak ta odpowiedź sugeruje całkowite poleganie na zaległościach, które w przypadku PO są niczym innym jak „systemem zarządzania problemami”. Tak więc IMHO ta odpowiedź ignoruje sedno pytania i nie przedstawia rozwiązania.
Doc Brown
24

Nie używaj TODO. Masz już listę rzeczy do zrobienia w swoim projekcie. Nazywa się to śledzeniem problemów.

Myślę, że prawdziwy problem tkwi w tym zdaniu:

możemy utworzyć zgłoszenie w naszym systemie zarządzania problemami, który tworzy bałagan, a także może zostać przeniesiony do późniejszego sprintu lub zaległości przez kierownictwo.

Jeśli narzędzie do śledzenia problemów tworzy dużo bałaganu, znajdź sposoby, aby to naprawić. Może specjalny typ / tag wydania, który wymaga mniej ceremonii. Może pod-problemy. Może w sumie mniej ceremonii. Naprawdę nie możemy powiedzieć. Ale jeśli narzędzie do śledzenia problemów tworzy tyle pracy, że ludzie raczej formułują skomplikowane pytania na forum publicznym niż po prostu dodają ten problem, coś jest naprawdę nie tak.

Jeśli kierownictwo nadmiernie opóźnia ostatnią część zadania, masz dwie opcje:

  1. porozmawiaj z kierownictwem, dlaczego to zły pomysł.

  2. traktuj to jako jedno zadanie. To może być złoty standard rozwiązania. W idealnym świecie powinieneś być w stanie wprowadzić trzy zmiany potrzebne na każdym kroku. Zastosuj jedną do gałęzi głównej, pozwól jej zbudować i wdrożyć. W międzyczasie zastosuj drugą gałąź master, pozwól jej zbudować i wdrożyć itd., Aby wszystko działo się w tym samym sprincie, a jeśli tak się nie stanie, nie zostanie to zrobione. Może nawet coś automatycznego ma sens, gdy logicznie wykonujesz jedno wdrożenie, ale tak naprawdę jest ono podzielone na 3.

Jens Schauder
źródło
Dobra rada, pomyślę o tym, w jaki sposób możemy sprawić, by system zarządzania problemami działał w tym celu. Bardzo podoba mi się też pomysł „Może nawet coś automatycznego ma sens, gdy logicznie wykonujesz jedno wdrożenie”, staram się wymyślić, w jaki sposób możemy to zrobić. Nie jestem jednak pewien, czy to realistycznie możliwe.
Joshua Walsh
11
Komentarze do formularza są całkowicie uzasadnione // TODO(#12345): Frobnicate the sprocket before passing it along, pod warunkiem, że błąd nr 12345 jest „prawdziwym” numerem problemu, a problem został komuś przypisany. Ułatwia to odczytanie źródła, wyjaśniając: „Nie, krok odszyfrowania nie ukrywa się w jednej z metod pomocniczych, jest po prostu niezaimplementowany. Przejdź do błędu # 12345, aby uzyskać więcej kontekstu”. Idealnie byłoby, gdybyś codziennie przeglądał linijkę po bazie kodu, szukając oczywiście zamkniętych lub nieprawidłowych numerów problemów.
Kevin
9

To, czego szukam, to sposób, w jaki komentarz TODO może mieć przed sobą termin, a nasz system ciągłej integracji (obecnie niezdecydowany, którego użyjemy) odrzuci kompilację, jeśli ten termin upłynie.

To, o co prosisz, jest wykonalne, jeśli chcesz wykonać pracę i postępować zgodnie z nią.

// TODO do v55: Utwórz migrację, aby przenieść ograniczenia do nowej kolumny, usuń odniesienia do starej kolumny w aplikacji // TODO do v56: Utwórz migrację, aby usunąć starą kolumnę

grep, //TODO by v55kiedy nadszedł czas na wdrożenie v55. Wdróż kompilację uruchamia skrypt, który robi to jako test integracji.

Możesz powiązać 55 ze śledzeniem wersji lub po prostu o to poprosić.

Interesujące staje się, jeśli chcesz sprawdzić // TODO do v54 podczas wykonywania 55. Zamiast tego przeszukaj 55 razy bazę kodu, po prostu wyszukaj // TODO według. Następnie odfiltruj ten wynik od 1 do 55. Teraz 56 nie spowoduje niepowodzenia.

Możesz pomyśleć „och, nie będziemy tego potrzebować. Naprawimy je za każdym razem, dopóki będziemy mieli czek”. Nie, nie będziesz.

candied_orange
źródło
4
Jeśli tak, nie robimy tutaj rekomendacji.
candied_orange
3
Jeśli istnieje ogólna nazwa tego rodzaju rzeczy, którą można podać, ale jeśli czytasz stronę, którą
podłączyłeś
6
Żeby było jasne, sprzeciwiam się raczej twojemu komentarzowi niż całemu pytaniu.
candied_orange
2
Witryny @YM_Industries SE wydają się być niezależne, zalecenia są w zasadzie prostymi odpowiedziami z linkami do stron zewnętrznych lub zapraszają do google zamiast linku, ale ostatecznie to samo. Mogą wygasnąć i umrzeć. Pytanie o rekomendację jest więc nie na temat, ale czy ktoś chce wspomnieć o narzędziu jako uzupełnieniu odpowiedzi lub prostym komentarzu, może to zrobić.
Walfrat
2
„Zastanawiałem się, czy istnieje istniejące rozwiązanie” - spróbuj nas zapytać na softwarerecs.stackexchange.com
Mawg
4

W naszym zespole mieliśmy bardzo podobny problem. Aby rozwiązać ten problem, napisaliśmy kontrolę analizy statycznej, która obsługuje te TODO, sprawdzając problem JIRA lub problem Git, do którego się odnoszą. Nasza kompilacja kończy się niepowodzeniem, gdy określony problem przesuwa się poza kolumnę „W fazie rozwoju”.

Dlatego możemy wygodnie mieć TODO, nie martwiąc się, że zostaną zapomniani.

Stworzyłem implementację tego typu open source w Javie. Tak, zastrzeżeniem jest to, że napisałem to, ale tak jak powiedziałem, jest to całkowicie otwarte źródło i licencja.

Narzędzie nazywa się Westie, a przykład sprawdzania problemów Jira znajduje się na README.md. Zobacz także GitIssueAnalyser.

Aby zapobiec autopromocji w przypadku dalszych pytań, wyślij mi wiadomość. Jeśli zdecydujesz się go użyć i masz jakieś sugestie, prosimy o zgłaszanie problemów na github.

tjheslin1
źródło
1
To super! Używamy również JIRA, mogę się tym zająć. Naprawdę nie rozwiązuje moich obaw związanych z tworzeniem bałaganu w naszym systemie zarządzania problemami, ale przynajmniej zagwarantuje, że nie można ich zapomnieć.
Joshua Walsh
@YM_Industries Cieszę się. Z przyjemnością przyjmę wszelkie uwagi lub prace nad wszelkimi poruszonymi kwestiami.
tjheslin1
4

Nie rób tego. Zrób to teraz.

TLDR: Napisz (i przetestuj) skrypty DB teraz, nie później; wystarczy je zakodować, aby ich wykonanie zależało od wersji DB.

Przykład

Na przykład wyobraźmy sobie, że chcesz zmienić nazwę kolumny z SSNna TaxID, co jest powszechnym wymogiem podczas podróży międzynarodowych.

Aby tak się stało, być może tymczasowo będziesz mieć zarówno kolumnę, jak TaxIDi SSNkolumnę. Obsługując obie wersje, będziesz mieć wyzwalacz do aktualizacji jednej z drugiej. Ale nie chcesz utrzymywać tego wyzwalacza w nieskończoność, więc później, gdy zgodność wsteczna nie jest już potrzebna, chcesz, aby ten wyzwalacz został usunięty (i SSNkolumna została usunięta). Zamierzamy zakodować to wszystko z góry bez potrzeby wykonywania czynności do wykonania.

W naszym przykładzie będziemy wdrażać kompilację 102 (która ma nową kolumnę), zachowując zgodność z kompilacją 101 (która nie ma).

Oto kroki.

1. Skonfiguruj tabelę wersji

  1. Dodaj pojedynczą tabelę Configurationz dwiema kolumnami Namei Value.

  2. Dodaj wiersz z Name„TargetVersion” i ustaw Valuewersję nowej kompilacji do wdrożenia.

  3. Dodaj wiersz z Name„CompatibleWith” i ustaw Valueminimalną liczbę wersji, z którą wdrożenie musi być zgodne.

Sprawdź i zaktualizuj te wiersze przed każdym wdrożeniem.

2. Zmodyfikuj skrypty wdrażania

  1. Dodaj skrypt, który tworzy nową kolumnę TaxIDobok siebie SSNi wypełnia ją z SSNkolumny. Umieść ten kod w Ifinstrukcji, która sprawdza TargetVersion; jeśli wersja docelowa jest zbyt niska (tzn. TaxIDnie jest jeszcze potrzebna), pomiń.

    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. Dodaj skrypt, który tworzy wyzwalacz, który zapełnia się TaxIDpodczas wstawiania lub aktualizacji SSNi odwrotnie. Umieść ten kod w Ifinstrukcji, która sprawdza wersję docelową i wersję zgodną; pomiń, jeśli wartość TargetVersion jest zbyt niska ( TaxIDnie jest potrzebna) lub jeśli wersja CompatibleWith jest zbyt wysoka ( SSNpole nie jest potrzebne).

    SELECT @TargetVersion  = TargetVersion,
           @CompatibleWith = CompatibleWith 
    FROM Configuration
    IF @TargetVersion  < '102' THEN RETURN
    IF @CompatibleWith > '101' THEN RETURN
    CREATE TRIGGER SSNAndTaxIDTrigger ON Customer etc.
    
  3. Dodaj skrypt, aby usunąć SSNkolumnę. Dodaj do Ifinstrukcji, która usuwa kolumnę tylko wtedy, gdy wersja CompatibleWith jest wystarczająco wysoka ( SSNnie jest już potrzebna).

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

Przetestuj swoje wdrożenie przy użyciu dowolnej kombinacji numerów wersji niebiesko-zielonej, którą chcesz obsługiwać w produkcji. Możesz przetestować, gdy tylko kod będzie gotowy, manipulując Configurationtabelą w środowisku kontroli jakości.

4. W podręczniku wdrażania

Dodaj krok dla inżyniera, aby zaktualizował wiersze CompatibleWith wersji i TargetVersion. W przypadku wdrażania w kolorze niebieskim ustaw opcję TargetVersion na numer wersji Blue, a wersję CompatibleWith na numer wersji Green; odwróć je, jeśli wdrażasz zielony.

Pułapki

Jest OK dla twoje skrypty wdrażania odwoływać i powoływać się na te numery wersji przechowywanych w tej tabeli DB. NIE kod środowiska wykonawczego.

Jeśli zaczniesz pisać kod środowiska wykonawczego w celu sprawdzenia numerów wersji, wprowadzasz w aplikacji nowy poziom złożoności, który może potencjalnie stać się poważnym problemem w zakresie konserwacji. Każda ścieżka wykonania środowiska wykonawczego musi zostać przetestowana; jeśli będziecie sobie radzić z tymi warunkami, QA będzie musiała zebrać matrycę bólu, aby potwierdzić je przy każdym uwolnieniu. Radzę zachować takie warunki tylko w skryptach wdrażania.

Wynik tego wszystkiego

Ostatecznie powinieneś być w stanie napisać cały kod z góry (i przetestować go również) bez obawy, że będzie on wykonywany zbyt wcześnie. Ponadto kod wyczyści wyzwalacz zgodności wstecznej, gdy nadejdzie czas, bez potrzeby martwienia się o to dalej.

W ten sposób możesz napisać i przetestować cały kod, gdy myślisz o tym, i nie musisz radzić sobie z tymi niechlujnymi komentarzami do zrobienia.

John Wu
źródło
Bardzo podoba mi się to podejście, jest bardziej eleganckie niż komentarze ToDo. Pomyślałem o tym wkrótce po zadaniu tego pytania i zastanawiałem się nad opublikowaniem kolejnego postu z pytaniem, jak najlepiej to wdrożyć, ale pomyślałem, że najpierw przeprowadzę własne badania. Sztuką dla nas jest to, że używamy Phinx do migracji baz danych i tak naprawdę to nie obsługuje. Kiedy będę mieć czas, szukam sposobu, aby go rozszerzyć, aby obsługiwał ten rodzaj przepływu pracy. To podejście nie rozwiązuje problemu, jak zapewnić, aby kod zgodności wstecznej został usunięty z mojej warstwy aplikacji, ale jest elegancki w przypadku problemu z DB.
Joshua Walsh
1

Dostajesz wiele zwrotów od swojego pomysłu do zrobienia, ale osobiście nie widzę z tym problemu. Ostatecznie najlepszym (i najłatwiejszym) sposobem upewnienia się, że migracja trafi do produkcji, jest niepowodzenie testu jednostkowego. Wytarcie pustej funkcji migracji, która zgłasza wyjątek, jeśli wersja ma 55 lub więcej (lub cokolwiek są wymagane), zajmie dosłownie mniej niż minutę.

Następnie, jeśli spróbujesz go zwolnić, zakończysz się niepowodzeniem testu i ktoś będzie musiał zamienić ten wyjątek w rzeczywisty kod migracji.

Eternal21
źródło
1
Tak, idealnie miałem nadzieję potraktować wygasłe TODO jako nieudany test. Powrotem do TODO trochę mnie zaskoczyło, wiem, że nie zastępują one systemu zarządzania problemami, ale biorąc pod uwagę powszechność TDD / BDD, jasne jest, że nie ma prawdziwego problemu z definiowaniem wymagań w kodzie i używaniem kodu do egzekwowania zakończenie funkcji.
Joshua Walsh
-2

Wydaje się, że nikt nie koncentruje się na źródłach jego skargi, a mianowicie na tym, że zmiany w bazie danych mogą zająć zbyt wiele cykli wydań. Chce kontynuować swój niebieski / zielony harmonogram wdrażania i rozwiązanie powinno już tam być, ale chyba, że ​​coś mi brakuje, jego opis wydaje się wskazywać, że istnieje tylko jedna baza danych, która jest współdzielona przez oba systemy. W takim przypadku nie jest to prawdziwy system niebiesko-zielony. Ponieważ wydaje się, że baza danych jest długim biegunem w namiocie, należy ją również zduplikować, aby bez względu na to, ile czasu i ile cykli wydania zajmie wdrożenie zmian w bazie danych w systemie offline, nie zostaną one uruchomione, dopóki nie zostaną zakończone i w pełni przetestowane. Tymczasowe skrypty systemowe offline mogą codziennie aktualizować bazę danych offline.

mpiazza
źródło
1
Replikacja bazy danych we wdrożeniu niebiesko-zielonym powoduje dużo bólu głowy. Kiedy mój prod env znajduje się gdzieś pomiędzy niebieskim a zielonym (na przykład 50% obciążenia rozdzielonego na każde), muszę mieć kod replikacji, aby synchronizować obie bazy danych, nawet jeśli ich schematy są różne. Z przeprowadzonych przeze mnie badań wynika, że ​​większość ludzi w prawdziwym świecie ma wspólną instancję DB między swoimi niebieskimi i zielonymi stosami. Nie uważam tego za poważny problem, o ile migracje baz danych są dość szybkie. Niebiesko-zielone stosy z natury muszą współdzielić niektóre zasoby, przynajmniej moduł równoważenia obciążenia / odwrotne proxy.
Joshua Walsh