Czy to polska firma? Bo raczej polaczek przelozony bylby tylko zdolny tak manipulowac ludzmi zeby w sobote musieli pracowac.
5
0
Kilka - kilkanaście razy dziennie od poniedziałku do czwartku. W piątek jakoś nie chcą, moim zdaniem zbędna ostrożność, no ale też rozumiem biznesowe powody takiej blokady.
1
Misiek_Uszaty napisał(a):
Czy to polska firma? Bo raczej polaczek przelozony bylby tylko zdolny tak manipulowac ludzmi zeby w sobote musieli pracowac.
Co jest złego w pracy w sobotę (czy w niedzielę nawet)? Jeśli ktoś chce sobie dorobić więcej kasy i mu odpowiada taki styl pracy, to jego sprawa.
A jak komuś nie odpowiada taka praca, to może się zwolnić i poszukać innej firmy.
Ja się tam cieszę, że ludzie (np. pracownicy sklepów) pracują w soboty (uważam, że powinni mieć też prawo pracowania w niedzielę, jak kiedyś było).
1
Podobnie poza punktem z łataniem bugów w sobotę - bugi muszą dojrzeć1
- Przypadkowo podobnie jest przy samobójstwach bez udziału osób trzecich, zazwyczaj w piątek ale sekcja jest dopiero w poniedziałek. Polecam ten styl w IT.
2
Kto się zgadza na deploy w piątek ten naprawia w sobotę.
Proste.
0
W 3ech na 5 projektów które overseeuję mam continuous deployment, więc deploy jest wtedy kiedy ktoś zrobi push.
46
W obecnym projekcie deploy na proda robimy w pon. Oczywiście jest to poprzedzone deployem na środowisko testowe w okolicach czwartku, gdzie wychodzą ew bugi i ich łatanie. Na 8/10 przypadków nic dodatkowego na prodzie nie wychodzi a jak już to marginalne bugi do zrobienia w krótkim czasie. IMO zależy od domeny i produktu. Jeśli takowy nie jest krytyczny (np internalny tool), to z powodu braku działania w weekend (gdzie znaczna większość nie pracuje), nie powinno być większych kwasów.
0
Trochę tak było. U mnie to ogólnie "deploy" wiąże się z całym cyrkiem, bo teoretycznie, gdybym chciał wrzucać coś na produkcję, to muszę tydzień wcześniej mieć wypełniony "ticket", co samo w sobie zajmuje kilka godzin. później musi przez tydzień nabrać ważności (pokisić się w inboxie tak na oko ~20 osób) i ostatecznie trafić na zebranie gdzie te 20 osób, których każda ma kilkanaście/kilkadziesiąt lat doświadczenia w niedostarczaniu oprogramowania powie z dumą "yes". Ten cyrk odbywa się co tydzień i jakże by inaczej, w piątki.
Sam deploy robimy w poniedziałek trwa to około 15 minut i sprowadza się do kliknięcia guzika "deploy" oraz szybkich smoke testów.
Oczywiście są wyjątki i w nagłych sytuacjach można pójść szybką ścieżką. Jak ostatnio klient chciał małego ficzerka, to implementacja testy, wypchnięcie na środowisko testowe zajęły coś koło 4 godzin. Przez kolejne 2 dni, 3 piętra (jeżeli dobrze liczę) mojego kierownictwa zastanawiały się czy poprosić swoich szefów o zgodę.
0
lambdadziara napisał(a):
Czy u Was w firmie tak to dziala - deploy raz na ruski rok i traktowany jak swieto narodowe, a jak w koncu do tego dochodzi to sie okazuje ze nic nie dziala i leca propozycje do ludzi by siedziec w sobote i naprawiac bledy.
Gdyby mi się coś takiego przydarzyło, to zacząłbym się zastanawiać czemu do jasnej anielki te bugi nie wyszły przed deploy'em; czyżby testy za słabe?
6
@Riddle: Z doświadczenia, jak masz release raz na rok, to nie masz też testów. Powód jest prosty - wszyscy są zajęci dopychaniem kolanem release i ładowaniem tam wszystkiego co zdaniem biznesu "musi być" a oczywiście wymyślona rok temu data wydania paczki jest jednocześnie pozbawiona znaczenia i wyryta w kamieniu. Mając release co tydzień/codziennie nikt za bardzo się nie przejmuje, czy coś się tam zmieści, czy spadnie, bo nawet jak spadnie, to będzie jutro/za tydzień.