Strategie promocji zależności: zamilczane czy koordynowane?

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 odtwarzalne
  • QA - Izolowane środowisko kontroli jakości / testowania
  • DEMO - 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ę, myappktó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-devpunkty, do myws-devktórych wykorzystuje mydb-dev. Podobnie myapp-qapunkty, do myws-qaktórych wykorzystuje mydb-qa. To samo dotyczy DEMOi LIVE.

Problem polega na tym, że w każdej chwili dokonać zmiany, powiedzmy, myappwymaga to mnie do wprowadzania zmian mywsi mydbjak 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-devi myapp-devzwykle 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, QAi DEMO); i
• Zależności upstream zależą od LIVEśrodowiska dla ich dalszych zależności dla środowiska produkcyjnego

Korzystając z tej konwencji, myapp-devaktualny wskazywałby na to myws-demo, co by wykorzystał mydb-demo. Podobnie myapp-qawskazywałby również na myws-demoi 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ć DEMObez rygorystycznego testowania zarówno na, jak DEVi na QA.

Jedyną wadą, jaką mogę znaleźć w tej metodzie, jest to, że jeśli ulegnie awarii DEMOdla 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 DEVi 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ć?

Jeśli dobrze czytam twój post, to nie wygląda na to, że ta propozycja faktycznie rozwiązuje jeden z rzekomych problemów.

za każdym razem, gdy dokonam zmiany, powiedzmy, myapp, wymaga to również wprowadzenia zmian w myws i mydb. Ale ponieważ każde środowisko DEV wskazuje na środowiska zależności DEV swoich zależności, oznacza to, że muszę zaplanować i wprowadzić te zmiany w tym samym czasie

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

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 również zwykle stają się niestabilne.

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