Mam pytanie do osób, które mają CD z prawdziwego zdarzenia - mam na myśli przykład chociażby Allegro, które robi kilkadziesiąt wdrożeń na produkcję dziennie. Kiedy u mnie w firmie proponowano częstsze mniejsze wdrożenia, to propozycja spotykała się z odpowiedzią, że zanim wdrożymy na produkcję, to wersja musi pochodzić co najmniej kilka dni na UAT. Tam zintegrują się z nią z inne zespoły i jest większa szansa, że wyłapiemy potencjalne błędy przed wejściem na produkcję. W sumie jest w tym trochę racji, ciężko mi się z tym nie zgodzić, ale jednocześnie chciałbym wdrażać mało i często, tak jak robi to wiele dużych firm i stosować podejście, które póki co znam jedynie z książek. Jak pogodzić ze sobą te 2 kwestie tak aby każdy był zadowolony? Dodam, że mówimy o architekturze mikroserwisów.
Możliwe, że to czego szukasz to continues deployment. Wtedy wdrażasz od razu na produkcję. Bez np pośredniego kroku, gdzie ktoś musi ręcznie zaakceptować.
Odpowiem: nie da się pogodzić wymagania "musi poleżeć na UAT przez x dni" z wdrożeniem od razu na produkcję. Musisz wyeliminować konieczność poleżenia na UAT przez parę dni. Klucz to testy automatyczne, gren/blue deployment, feature toggles i mnóstwo monitoringu. To też zależy jak wasze mikroserwisy się komunikują ze sobą, i jak dobrze są podzielone i odseparowane od siebie. To też kwestia myślenia, że trzeba być wstecznie kompatybilnym itd. Ciężko mi coś doradzić jak nie znam konkretnie sytuacji.
Można zacząć od zaproponowania tego podejścia na osobnym mikroserwisie lub kilku, a resztę zostawić jak jest i po prostu empirycznie udowodnić że to działa. Ważne, żeby te mikroserwisy nie były kluczowe i żeby firma nie padła jak się coś popsuje ;-) bo na początku będziecie pewnie popełniać błędy... tylko że wtedy też macie narzędzia do tego by je szybko naprawić.
CO do jakiś argumentów żeby Ci pomóc przekonać innych:
Do tego jeśli mam mikroserwis A, i wrzucę na UAT wersję A1, a potem za dwa dni A2, to co mogę zrobić? Wrzucić na proda A1 czy czekam znów na A2? Jak A1 skąd mam pewność że A1 nie jest z bugiem, który A2 naprawił i wszyscy tak naprawdę są zintegrowani z A2 i nie wyszedł?
Oraz co wam to rzeczywiście daje? Ile błędów i jakie na UAT wykrywacie? Jeśli żadnych... to jest argument. Jeśli dużo... to trzeba się skupić żeby je wyeliminować. Przy czym niektórzy mają podejście "Jak nie idzie na proda, to wrzućmy i zobaczmy co się stanie, najwyżej to tylko UAT który wybuchnie..." zamiast pomyśleć czy rzeczywiście można wrzucać. Jak to wygląda u was?
A dlaczego CI takie rozwiązanie przeszkadza? Wdrażasz mało i często - tylko nie na produkcję. Martwiłbym się raczej chwilami, gdy nawet z tego UAT przychodza Ci zwrotki i musisz fixowac błędy. W innym przypadku nie przejmowałbym się tym wcale. Poza tym to co jest na UAT - to też może być deployowane w porcjach i często. Wg mnie wasze obecne rozwiązanie jest bardzo dobre. Dodatkowe zabezpieczenie jest przecież jak najbardziej na plus.
Oraz co wam to rzeczywiście daje? Ile błędów i jakie na UAT wykrywacie? Jeśli żadnych... to jest argument. Jeśli dużo... to trzeba się skupić żeby je wyeliminować. Przy czym niektórzy mają podejście "Jak nie idzie na proda, to wrzućmy i zobaczmy co się stanie, najwyżej to tylko UAT który wybuchnie..." zamiast pomyśleć czy rzeczywiście można wrzucać. Jak to wygląda u was?
To się zgadza. Myślę, że wykrywamy raczej małą ilość błędów na UAT.
A dlaczego CI takie rozwiązanie przeszkadza?
Zdarzały się sytuację, gdzie dzień rozpoczynaliśmy od szukania fragmentu kodu, który rozwalił produkcję po wczorajszym wdrożeniu, które obejmowało wykonaną pracę przez ostatni miesiąc.
anckor napisał(a):
Zdarzały się sytuację, gdzie dzień rozpoczynaliśmy od szukania fragmentu kodu, który rozwalił produkcję po wczorajszym wdrożeniu, które obejmowało wykonaną pracę przez ostatni miesiąc.
To wygląda, że u Was na UATcie nic się nie dzieje...?
To wygląda, że u Was na UATcie nic się nie dzieje...?
Nie no dzieje się. Inne zespoły integrują się z naszymi usługami w ramach testów. A to, że rzadko wracają do nas błędy.. no cóż, staramy się xD
Ja jakby nie widzę problemu:
- implementuję ficzer
- merdżuję do mastera
- podbijam wersję kodu
- wrzucam na UAT
- leży kilka dni
- idzie na proda
Jest i continous delivery i kilka dni na uacie.
anckor napisał(a):
Zdarzały się sytuację, gdzie dzień rozpoczynaliśmy od szukania fragmentu kodu, który rozwalił produkcję po wczorajszym wdrożeniu, które obejmowało wykonaną pracę przez ostatni miesiąc.
No i to jest argument, że obecne podejście z big-bang deploymentem na produkcję jest po prostu złe.
Może w Twojej firmie time to market nie jest istotny i możecie sobie wdrażać raz na rok. Może Twoja firma nie musi/nie chce być agile. Może macie mała skale i da się wszystko przetestować.
Przy systemach rozproszonych, nad którymi pracuje kilkadziesiąt zespołów lepiej jest postawić na szybkie wdrożenia i szybkie fiksy. „Monitoring is new testing” jak to mówią. Plus to co pisali poprzednicy, przez wielkie merge zwalniają się ludzie.