Jak to u Was jest? Czy posiadacie cykle wydawnicze i wdrażacie np. co 2 tygodnie, czy raczej stosujecie continuous deployment i wdrażacie nawet kilka razy dziennie?
Czy stosujecie git flow? Czy raczej uproszczoną wersję czyli github flow?
Jak to u Was jest? Czy posiadacie cykle wydawnicze i wdrażacie np. co 2 tygodnie, czy raczej stosujecie continuous deployment i wdrażacie nawet kilka razy dziennie?
Czy stosujecie git flow? Czy raczej uproszczoną wersję czyli github flow?
zależy od projektu ale zazwyczaj każdy zakończony task jest wypychany od razu na proda.
Wdrażamy, gdy potrzebujemy, czyli czasem jest to kilka razy dziennie, a czasem nic się nie dzieje przez tydzień albo dwa (bo robimy biblioteki albo inne rzeczy, a nie API).
Żadnego git/github flowa nie mamy, po prostu feature branch na zadanie i squash do mastera.
ehhhhh napisał(a):
zależy od projektu ale zazwyczaj każdy zakończony task jest wypychany od razu na proda.
A nie macie czegoś w rodzaju staging
gdzie można sobie jeszcze potestować aplikacje?
W starej firmie cykle wydawnicze - średnio duża wersja dla wszystkich aplikacji z całej firmy raz na kwartał plus mniejsze wehikuły (ograniczone systemowo) w miesiącach pomiędzy. Wdrożenia w nocy w weekendy.
W aktualnej firmie continuous deployment, wdrożenia na proda pon-pt 8-16 tak jak siedzimy w pracy. Ale sam proces zatwierdzenia zmiany od Dev na produkcję tak zaostrzony że raczej o wdrażaniu tej samej apki kilka razy dziennie nie ma mowy.
W obu przypadkach przejścia przez środowiska testowe. (W starej firmie 3 różne środowiska zanim zmiana trafi na prod)
Adam Boduch napisał(a):
ehhhhh napisał(a):
zależy od projektu ale zazwyczaj każdy zakończony task jest wypychany od razu na proda.
A nie macie czegoś w rodzaju
staging
gdzie można sobie jeszcze potestować aplikacje?
W jednym projekcie ale w sumie to działa bardziej jako demo dla klientów naszego klienta.
co roku nowa "duża wersja" a w ciągu roku 11 mniejszych (generalnie +- parę dni co miesiąc) + przed każdą wersją jest wersja beta. Jeden miesiąc w roku jest generalnie bez tasków funkcyjnych, na taski techniczne i uzbierane bugi, które nie są na tyle "złe", że można z nimi poczekać. To jest dla części instalowanej, część chmurowa generalnie aktualizuje się jak coś poprawią albo dodadzą :)
Mam w projekcie aplikacje mobilne / desktopowe i backend.
Dla aplikacji cykl wydawniczy jest dość upierdliwy, bo koszt błędu wysłanego do klienta jest zbyt duży. Leci tam dość tłusty cykl wydawniczy oparty na ~gitflow.
Dla backendu, idziemy w kierunku CI/CD + trunk based development. Największym problemem jest tłum firmowych specjalistów od "jakości" i procedura sprawdzenia, czy wszystkie metryki są zielone, która trwa około tygodnia. Próbujemy z tym jakoś walczyć, ale idzie to opornie i biurokracja niestety nas powstrzymuje. Od strony technicznej jesteśmy właściwie gotowi do wdrożenia CI/CD - mamy testy automatyczne, pipeliny do deploymentu itd. ale wciąż problemem nie do przejścia jest zebranie się stada świeżo zacerowanych dziewic, które muszą pokręcić nosem nad np. testami jednostkowymi i konieczność przygotowania dokumentacji do tego release. W sumie dokumentację na tyle ile się da, już też generujemy w CI.
Raz na dwa miesiące się staramy. Mamy staging
i teraz dodatkowo walczymy o preproda który będzie 100% zgodny z produkcją. Użytkownicy cisną o nowe feature więc w zasadziej jak cokolwiek stabilnego uda się zrobić to idzie na proda
Co sprint release na uat a potem to już różnie, w zależności od tego czy jakimś cudem tam ktoś znajdzie buga albo zmienią się nagle założenia :D
Jak funkcjonalność jest gotowa i działa na localhost, to leci na dev tam jest testowana i wrzucamy na proda(wiadomo, jak potrzebne są fronty do tego albo backend to się czeka).
W innym projekcie jest Dev do zabawy, QA do testów oraz prod. Obydwa projekty podpięte pod CI/CD
Duży zbiorczy release ze zmianami na życzenie klienta - co 3 tygodnie. 2 tyg developmentu, 1 tydzień na internal + client tests.
Branża ubezpieczeniowa dla USA więc jeśli nastąpi zmiana w prawie i trzeba coś szybko zmienić/załatać to wrzucamy to na proda od razu.
Co firma i projekt to inaczej.
W poprzedniej firmie po 2 tygodniowym sprincie, wdrożenie, bez flow.(Firma produktowa)
W obecnej na bardziej wewnętrznych apkach dla firm to co dzień rano po zaczęciu pracy (pn-pt). Używamy git flow.
Na apkach które są otwarte na świat pon-wt, max środa rano. Czwartek, pt odpada bo nikt w weekend nie ma zamiaru gasić pożarów.
To wszystko oczywiście przy featurach. Jeśli chodzi o hotfix gaszący pożar to kiedy jest potrzeba xD
Mamy dwa sklepy, jeden dosyć duży, drugi jest mniejszy więc jest wersją staging.
Wrzucamy na mniejszy, fixujemy i dopiero wrzucamy na większy :>
U nas mamy CD i w zależności od potrzeb zmiany wypychane są na produkcję, używane są 3 instancje dev
, staging
i produkcja
Poprzednio mój projekt trafił na produkcje po 2.5 roku
Jak robiłem backend w korpo to raz na dwa tygodnie, jak trzeba było to częściej, rzadko się zdarzało, że nie było czego wydawać przynajmniej wtedy gdy byłem w projekcie. Mieliśmy jakąś wariację git flow. Teraz robię desktopową aplikację i główny release mamy raz w roku ;)
Jak potrzeba. Jeśli jest funkcjonalność skończona idzie na proda. Najszybciej w jeden dzień roboczy, bo min 4h działa na środowisku integracyjnym dla wyłapania problemów, a później falami co ustalony czas na kolejne produkcje bo jest ich wiele a wave&bake daje czas na odpalenie alertów w razie problemów nie do wyłapania przy testahc. Minimum raz w tygodniu, żeby wdrożyć nowe wersje bibliotek, odświeżyć instancje. Przy akcjach typu łatanie log4shell
to taka zmiana idzie bez opóźnień.
Adam Boduch napisał(a):
Jak to u Was jest? Czy posiadacie cykle wydawnicze i wdrażacie np. co 2 tygodnie, czy raczej stosujecie continuous deployment i wdrażacie nawet kilka razy dziennie?
Why not both.
Raz na miesiąc-dwa jest pełnoprawny release. Pilne poprawki mogą zostać wypchnięte w międzyczasie.
Ale kilka razy dziennie to byłoby niewykonalne.
Średnio raz na 3 miechy :( ubolewam nad tym, bo architektura jest bardzo fajna (mikroserwisy + pełne CI/CD ale tylko dla deva) i trzymając dyscyplinę + dobre testy dałoby się wdrażać w dowolnym momencie przy małym ryzyku + prosty rollback, a tak leci wszystko hurtem (wymagania branży).
@kelog: Jaka branża wymaga wdrażania nieczęściej niż raz na 3 miesiące? Pytam, bo parę razy słyszałem taką wymówkę i najczęściej było to opowiadanie bzdur.