Mamy wiele aplikacji i usług internetowych (niektóre produkty publiczne, niektóre wewnętrzne i część prywatnego „zaplecza”), które są od siebie zależne. Każdy z tych komponentów ma 4 środowiska (klastry serwerów / węzłów służące do określonych celów):
- Nieprodukcyjny
DEV
- Zintegrowane środowisko programistyczne, w którym CI buduje zmiany push; przydatne dla inżynierów w rozwiązywaniu trudnych do znalezienia błędów, które nie są lokalnie odtwarzalneQA
- Izolowane środowisko kontroli jakości / testowaniaDEMO
- Stabilne środowisko UAT dla interesariuszy biznesowych
- Produkcja
LIVE
- Nasze środowisko na żywo / produkcyjne
Promocja kodu idzie: LOCAL
(maszyna programisty) => DEV
=> QA
=> DEMO
=> LIVE
.
Załóżmy, że mamy wywoływaną aplikację, myapp
która jest wspierana przez usługę RESTful o nazwie Web myws
, która sama jest wspierana przez DB o nazwie mydb
.
Obecnie wśród tych zależności mamy coś, co nazwałbym „ zorganizowaną ” promocją: myapp-dev
punkty, do myws-dev
których wykorzystuje mydb-dev
. Podobnie myapp-qa
punkty, do myws-qa
których wykorzystuje mydb-qa
. To samo dotyczy DEMO
i LIVE
.
Problem polega na tym, że w każdej chwili dokonać zmiany, powiedzmy, myapp
wymaga to mnie do wprowadzania zmian myws
i mydb
jak dobrze. Ponieważ jednak każde DEV
środowisko wskazuje środowiska zależności DEV
, oznacza to, że muszę planować i wdrażać te zmiany jednocześnie. Ponadto, jeśli jedna kompilacja staje się niestabilna / zepsuta, często obniża inne komponenty początkowe; na przykład jeśli programista coś zepsuje podczas zmiany mydb-dev
, klastry myws-dev
i myapp-dev
zwykle również stają się niestabilne.
Aby rozwiązać ten problem, przygotowuję propozycję strategii promocyjnej „ wyciszonej ”: wszystkie zależności między komponentami są zgodne z następującymi wytycznymi:
- Upstream zależności zależy od
DEMO
środowiska, w ich dalszym zależności, dla wszystkich ich środowiska nieprodukcyjnego (DEV
,QA
iDEMO
); i - Zależności upstream zależą od
LIVE
środowiska dla ich dalszych zależności dla środowiska produkcyjnego
Korzystając z tej konwencji, myapp-dev
aktualny wskazywałby na to myws-demo
, co by wykorzystał mydb-demo
. Podobnie myapp-qa
wskazywałby również na myws-demo
i mydb-demo
.
Zaletą, którą mogę tutaj znaleźć, jest stabilizacja kompilacji : jest znacznie mniej prawdopodobne, że DEMO
środowisko dla określonego komponentu stanie się niestabilne, ponieważ kod nie może tego zrobić DEMO
bez rygorystycznego testowania zarówno na, jak DEV
i na QA
.
Jedyną wadą, jaką mogę znaleźć w tej metodzie, jest to, że jeśli ulegnie awarii DEMO
dla konkretnego komponentu, wszystkie środowiska nieprodukcyjne dla wszystkich zależności upstream zostaną nagle uszkodzone. Ale przeciwstawiłbym się, że powinno się to zdarzać niezwykle rzadko z powodu testów przeprowadzonych na DEV
i QA
.
To dostał się problem, że wielu deweloperów (o wiele mądrzejszy i doświadczeni niż ja) rozwiązali i nie zdziwiłbym się, gdyby tego problemu i jego rozwiązania mają już imiona dla nich (oprócz tego, co ja nazywam Orchestrated / autonomicznych). Pytam więc: czy zalety strategii wyciszenia przewyższają wady i jakie wady mogę tutaj przeoczyć?
Odpowiedzi:
Jeśli dobrze czytam twój post, to nie wygląda na to, że ta propozycja faktycznie rozwiązuje jeden z rzekomych problemów.
„Strategia promocyjna” wydaje się tylko pogorszyć sytuację. Jeśli myapp v2, myws v2 i mydb v2 działają tylko na DEV, a myapp v2 polega na tym, że mydb v2 nie ulega awarii, wtedy gdy spróbuję uruchomić moją aplikację v2 na DEV, uderzę w DEMO mydb v1 i nastąpi awaria. Zasadniczo będziesz zmuszony albo ciągle przesłonić silosy, albo wdrożyć mydb v2 do samego początku, zanim będziesz mógł rozpocząć pracę z myapp v2. Co ważniejsze, nigdy nie testowałbyś mydb v2 na DEV, więc jeśli jest zepsuty, nawet się nie dowiesz, dopóki nie zepsuje się w DEMO, a następnie wrócisz do punktu wyjścia.
W pewnym stopniu opisany problem jest nieunikniony bez względu na konfigurację przepływu pracy, ale można go zminimalizować. Sztuką jest upewnienie się, że interfejs między mydb i myws (oraz interfejs między myws i myapp) jest ściśle zdefiniowany i wymaga , aby wszystkie aktualizacje tego interfejsu były w pełni kompatybilne wstecz . W mojej pracy mamy schemat XML definiujący interfejs między naszymi aplikacjami i usługami, a wiele naszych wewnętrznych narzędzi po prostu nie pozwala nam na dokonywanie niezgodnych aktualizacji tych schematów.
Wydaje mi się, że to poważny problem, ale nie problem z wdrożeniem. Zepsuta baza danych z pewnością uniemożliwi prawidłowe działanie usługi i aplikacji, ale nie powinna stać się „niestabilna”. Powinny one zwracać jakieś komunikaty o błędach, aby każdy, kto uruchamia myapp na dev, zobaczył „Przykro nam, nasza baza danych ma dzisiaj problemy” zamiast po prostu upaść.
Jeśli problem polega na tym, że zepsuta baza danych w ogóle powoduje te problemy, możesz skonfigurować system „tymczasowego silosowania”, który pozwala powiedzieć, że „mydb DEV jest zepsuty, prześlij wszystkie zapytania myws DEV do mydb DEMO w celu czas płynie". Ale powinien to być tylko sposób na wykonanie tymczasowych poprawek, dopóki mydb DEV nie będzie działać normalnie. Jeśli wszystko jest domyślnie „wyciszone”, to powracasz do problemów, które opisałem powyżej, ponieważ nikt nigdy nie działa przeciwko mydb DEV.
Wydaje mi się, że prawdopodobnie w jakiś sposób źle zrozumiałem pańską propozycję, ale mam nadzieję, że ta odpowiedź przynajmniej zrozumie, co zostało źle zrozumiane i jak najlepiej je sformułować.
źródło