W skrócie polega to na tym, że wdrażamy kod na produkcję/staging z Pull requesta jeszcze przed mergowaniem do mastera!
Dopiero po potwierdzeniu że wszystko jest ok, kod jest mergowany. Takie podejście od lat jest używane w Github i zastanawiam się czy ktoś z Was miał wcześniej do czynienia z taką praktyką?
Więcej do poczytania tutaj: https://github.blog/2023-02-02-enabling-branch-deployments-through-issueops-with-github-actions/#understanding-the-branch-deploy-model
Pracowałem kiedyś w firmie, w której były 5 stagingów. Programiści robili pull requesta, a potem odpalali komendę (z lokala):
./wrzuć-na-staging --number=4
i potem pod PR'em dodawali komentarz "Wrzucone na staging nr 4". I potem można było wejść na staging4.application.com i działać.
Nie specjalnie lubiłem to podejście.
Z automatycznym deployem na staging z PR'a nie pracowałem jeszcze.
Ja do tej pory pracowałem zawsze w tradycyjnym modelu, czyli merge PR do mastera a potem deploy z master brancha. Tutaj programiści Github proponują całkowicie coś innego. Mianowicie wdrażają PR na produkcję i jeżeli wszystko jest ok, to wówczas dopiero merge do mastera :) Jeżeli nie, to szybko mogą wycofać zmianę ponieważ master jest traktowany jako stabilny branch.
Adam Boduch napisał(a):
Ja do tej pory pracowałem zawsze w tradycyjnym modelu, czyli merge PR do mastera a potem deploy z master brancha. Tutaj programiści Github proponują całkowicie coś innego. Mianowicie wdrażają PR na produkcję i jeżeli wszystko jest ok, to wówczas dopiero merge do mastera :) Jeżeli nie, to szybko mogą wycofać zmianę ponieważ master jest traktowany jako stabilny branch.
Pomysł bardzo fajny, orginalny. Myślę że dla niektórych aplikacji to mogłoby być bardzo fajne.
Ja sam osobiście wyznaję podejście Continuous Integration (nie że Jenkins, tylko w rozumieniu XP, takim, że commity się robi często, i są małe, i od razu są integrowane z innymi programistami), i z tego powodu feature branchy staram się nie używać.
Ale pomysł bardzo fajny.
Wydaje mi się, że ma to sens przy charakterystyce Githuba czyli:
Podobna sytuacja jak ten post z przeszłości, gdzie ktoś pisał, że w instagramie nie ma testów tylko wrzucają na proda i patrzą na błędy metryki.
Akurat bardzo mnie zaciekawiło jak rozwiązują problem 2 PRów w jednym czasie, i w starym artykule piszą:
As soon as a branch is deployed, Hubot locks the environment so no other branches can be deployed to it. This prevents others from accidentally deploying while a developer is testing their branch.
Czyli zmiany są silnie uszeregowane. Ma to pewnie sens, jeśli jest ich niewiele (pytanie ile czasu autor kodu testuje zmianę - 10 minut? godzinę? dzień?), co trochę przeczy idei CD, ale zapewne jeśli cała organizacja w to wchodzi to jest spoko.
EDIT: czy to jest monolit? Wtedy ma to znacznie więcej sensu. W przypadku systemu rozproszonego to się raczej nie sprawdzi :)
kelog napisał(a):
EDIT: czy to jest monolit? Wtedy ma to znacznie więcej sensu. W przypadku systemu rozproszonego to się raczej nie sprawdzi :)
Był monolit. Przeszli na mikroserwisy.
Mialem w jednym projekcie deployment każdej branchy na vercela, ale to tylko apki w react które miały jeden wspólny backend który się podmienialo kiedy trzeba było
Dobrze rozumiem że to po prostu podejście"testy na produkcji"? Bo dajesz nieprzetestowany kod klientowi.
Trzeba mieć dobrze ustawione observability aplikacji bo jakoś się musisz dowiedzieć że to co przed chwilą wrzuciłeś nie działa.
Roman Mokrzan napisał(a):
Dobrze rozumiem że to po prostu podejście"testy na produkcji"? Bo dajesz nieprzetestowany kod klientowi.
To była moja pierwsza myśl :) Ale mają oni wcześniej środowisko testowe oraz staging i zakładam, że tam idzie w pierwszej kolejności :)
Pracowałem w takim modelu i działa, chociaż wymaga sporego narzutu toolingu, obsługi kolejek i Dx. Przy odpowiedniej skali ma to sens, mikroserwisy pomagają w zasadzie jeszcze bardziej bo blokowanie się nie zachodzi w obrębie jednego repo.
I nie, to nie jest testowanie na produkcji - wszystkie checki są wykonywane na poziomie PR i środowiska pre-prod, tylko wtedy lecimy na proda a po przejściu healthchecku kod wraca do mastera jak „carbon copy” produkcji.
Z plusów - w przypadku incydentów masz zawsze stabilnego mastera który „już był” na produkcji.
Adam Boduch napisał(a):
W skrócie polega to na tym, że wdrażamy kod na produkcję/staging z Pull requesta jeszcze przed mergowaniem do mastera!
Mogę kod z dowolnej gałęzi wrzucić na które środowisko chcę, tylko w sumie nie wiem czy kiedykolwiek z tego skorzystałem. Tak czy siak, to raczej opcja niż standardowe podejście.
Rozumiem to podejście pod kątem szybkiej procedury hotfixowej. Coś poszło nie tak w pierwszych chwilach po wdrożeniu? Revert do mastera. Wszystko git, równamy mastera.
Czasem sprawdzam dodatkowo swój branch na devie (deploy robie z niego) ale zazwyczaj wierze w testy które napisałem. Podejscie ze są środowiska per branch od czasu do czasu mają swoje plusy zwłascza jak jakas zmiana wymaga spora roboty, breaking changes - pozwala to sporo testować na żywo mimo wszystko. Ale ogólnie nie żeby to robić z masterem.
@psmyrdek: napiszesz coś więcej? Jak rozwiązaliście obslugę kolejki? Co z blokowaniem środowisk? Widzę, że na czas "testów" ludzie z githuba mogą blokować dane środowisko aby nikt inny w tym czasie nie zrobił swojego deploy i nie nadpisał zmian.
@Adam Boduch: Wewnętrzny tooling z lockowaniem/unlockowaniem deploymentów. Powstał do tego dedykowany mikroserwis przechowujący stan deploymentów w firmie w obrębie danego serwisu. Parametry unlockowania są już detalem implementacyjnym - do decyzji co to znaczy "udało się wyjść na produkcję" - healtcheck, etc.
Dodatkowo, jest tutaj case na race conditions:
User A robi checkout z mastera, pracuje z PR 1
User B robi równolegle checkout z mastera, pracuje z PR 2
User A chce wyjść na produkcje, zaczyna deployment
User B ustawia się w kolejce
User A wychodzi na produkcję
PR 1 zostaje wbity do mastera
User B dostaje zielone światło, jest pierwszy ale nie jest "up to date" z masterem (PR 1 zmergowany), więc tooling dociąga ostatnie zmiany i wraca do etapu "pre-prod" - jak przejdzie to idzie na prod
etc...
Na początku uciążliwe ale weszło w nawyk.
W jednym projekcie tak robiliśmy, dzięki temu trochę mniej zamieszania było przy potrzebie hotfixów po wgraniu nowej wersji. Jeśli już wersja na prodzie wygrzała się, to dopiero wtedy mergowaliśmy do mastera.
Skoro to ma rozwiązywać problemy z niestabilnym masterem na prodzie, to naturalnie powstaje pytanie - z czego wynikał niestabilny master na prodzie?
Brak testów?
Rzadkie wdrożenia dużych partii kodu od różnych twórców?
Coś jeszcze innego?