Dlaczego nie wdrożyć w piątek? [Zamknięte]


95

Joel wspomniał w podcastu StackOverflow # 24, że zgodnie z polityką firmy FogCreek nie wysyła się oprogramowania w piątki. Jednak nie wyjaśnił, dlaczego.

Zgadzam się. U mojego pracodawcy pracujemy w czwartkowe wieczory. Mamy więc piątek na usunięcie wszelkich błędów, które pominęły kontrolę jakości (QA).

Jednak mój menedżer zasugerował, że wdrażamy w piątkowe wieczory w przypadku, gdy kontrola jakości nie ma wystarczająco dużo czasu na przetestowanie oprogramowania przed wydaniem. Mówię, co z planami weekendowymi ludzi? A jeśli wdrożymy w piątek wieczorem, musielibyśmy pracować w sobotę, aby usunąć wszelkie pominięte błędy - co jest do bani.

Dlaczego więc nie wysłać oprogramowania w piątek?

* Możemy (nie jesteśmy pewni) przyjąć takie założenie: istnieje jeden podstawowy zespół programistów zlokalizowany w jednej strefie czasowej, który wdraża podstawową aplikację internetową swojej firmy.


11
Gdyby to był mój proces, wdrażanie odbywałoby się w środy, w połowie tygodnia mamy kilka dni na rozwiązanie problemów przed weekendem
CVertex

3
Apple zwykle wdraża się we wtorki.
mouviciel

2
Fajną rzeczą we wtorek jest to, że masz poniedziałek na sprawdzenie końcowe i może na praktykę, więc wszyscy są na tej samej stronie, a resztę tygodnia masz na zajęcie się wszystkim, co się pojawi. W piątek dowiesz się, czy będziesz musiał pracować w ten weekend.
Mike DeSimone

7
Nie widzę, dlaczego to nie jest związane z programowaniem. Czy nie jest końcowym wynikiem programowania wdrożenia kodu?
womp

1
@womp Jeśli podążę za twoim rozumowaniem, wdrożenie kodu będzie ostatecznie polegało na spełnieniu pewnych potrzeb biznesowych. A to powinno uzasadniać wszelkie pytania biznesowe?
Pascal Thivent

Odpowiedzi:


88

To nie tylko kwestia błędów. Mogą wystąpić inne powiązane obciążenia związane z pomocą techniczną - wyjaśnianie użytkownikom nowych funkcji, monitorowanie, czy nie ma problemów z wydajnością.

Nowa wersja będzie generalnie oznaczać krótki wzrost aktywności wspierającej - więc zaplanowanie tego, gdy będzie mniej osób (lub gdy zajmie więcej czasu), jest złym pomysłem.


6
Jon Skeet wypuszcza kod w dowolnym momencie… prawda ?!
Matt

16
@Matt - Jeśli dzień rozpoczął się w piątek, przestaje tak być, gdy Jon wypuszcza swoje oprogramowanie, Jon Skeet nie dostosowuje harmonogramu wydań do kalendarza ... kalendarz dostosowuje się do jego harmonogramu wydań.
Newtopian

2
@Newtopian: zmieszałeś to z Chuckiem Norrisem, Jon Skeet to tylko robot Google
Niteriter

5
@Matt, poprawka: Jon Skeet nigdy nie kompiluje kodu w konfiguracji debugowania, tylko Release. Gdy kompilator jest gotowy, nowa kompilacja jest natychmiast wysyłana do klientów na całym świecie. Lubi to w ten sposób.

2
Wydaje się, że moje studio ma okropny zwyczaj otwierania się w piątek. Mogę powiedzieć, że mój szef odbiera większość telefonów od swoich wściekłych klientów w sobotę / niedzielę, kiedy coś zostało pominięte. (NIGDY NIE
PREMIERA W

50

Nigdy nie wdrażaj w piątek, ponieważ:

  1. Jest koniec tygodnia, więc ludzie są mniej bystrzy
  2. Jest już koniec tygodnia, więc ludzie nie mogą naprawiać błędów
  3. Jest już koniec tygodnia, więc ludzie nie mogą odpowiadać na pytania
  4. Jest już koniec tygodnia, więc dlaczego miałbyś to wdrożyć?

1
KIIS - nie mogłeś tego lepiej wyrazić. ..
R Claven

46

Odpowiedziałeś właściwie na swoje pytanie. To krótki i słodki powód: jeśli wysyłasz w piątek i błąd trafia do produkcji, zazwyczaj nie ma nikogo, kto mógłby go naprawić lub porozmawiać z klientami do następnego poniedziałku. To potencjalnie kilka dni utraconych przychodów w najgorszym przypadku.


1
To samo tutaj. Tworzę oprogramowanie wewnętrzne dla firmy produkcyjnej, więc nie mam klientów zewnętrznych. Ale nasi użytkownicy pracują w weekendy i na nocnych zmianach, więc wdrożenie w piątek wieczorem byłoby najgorsze, co moglibyśmy zrobić :-)
Christian Specht

8

Unikamy publikowania kodu w czwartek lub piątek - nikt nie chce spędzić piątku na szukaniu błędów krytycznych dla misji, a są szanse, że nawet jeśli stworzymy poprawkę w 1 dzień, minie co najmniej kolejny dzień, zanim będzie można ją opublikować, co oznacza albo pracę w weekend, albo naprawę dopiero w przyszłym tygodniu.


6

To zależy od Twojej grupy docelowej. Obsługujemy głównie w piątki. Nasz produkt oparty na przeglądarce jest używany przez klientów na całym świecie, ale głównie w godzinach pracy. Oznacza to, że tak naprawdę nie mamy czasu innego niż niedzielne poranki, jeśli chcemy mieć pewność, że nie wpłyniemy na żadnych klientów (Indie i Bliski Wschód nie rezygnują z pracy w soboty), ale generalnie „idziemy na kompromis” i wysyłaj piątkowe popołudnia.

Jeśli wcześniej pracowaliśmy na stronie randkowej, na której idealnie chcieliśmy wdrożyć nowe rzeczy około wtorku, ponieważ aktywność osiągnęła szczyt w weekendy i, co dziwne, w poniedziałek w okolicach lunchu.

W każdym razie sprowadza się to do dwóch względów. 1. Kiedy będzie to najmniej uciążliwe dla twoich klientów (jeśli jest to aplikacja internetowa) i 2. Kiedy będzie najlepiej pasować do zespołu programistów do pilnego naprawiania krytycznych błędów.

Jeśli obawiasz się, że twoi programiści będą niechlujni pod koniec tygodnia, twój potok kontroli jakości może być zbyt krótki.


5

Wdrożenie należy przeprowadzić w piątek, aby mieć cały weekend na uporządkowanie i naprawienie błędów, zanim reszta zespołu zauważy Twoje przeoczenia w poniedziałek.


4

Zwykle wdrażamy we wtorki, a następnie mamy resztę tygodnia na rozwiązywanie wszelkich problemów. Zależy to również trochę od branży, jeśli nie ma pracy w weekendy, być może można wdrożyć w piątek wieczorem, ale jeśli działają, to nie jest to dobry pomysł.

Do tego ludzie są bardziej niechlujni w piątki (już myślę o tej gorącej dacie | zimne piwo | oba) i na kilka dni przed wyjazdem na wakacje ;-)


4

To naprawdę zależy od Twojej aplikacji i tego, jak zajęty / krytyczny jest w weekend.

Zwykle nie wdrażamy oprogramowania w piątek, ale często robimy to w sobotę lub niedzielę. Okazało się, że niedzielny poranek jest szczególnie dobry, jeśli chodzi o zminimalizowanie wpływu wydania.

To naprawdę zależy od tego, czy próbujesz zminimalizować wpływ jakichkolwiek przestojów potrzebnych do wydania, czy też złagodzić potencjalne błędy.

Nie zobaczysz żadnych błędów, dopóki klienci faktycznie nie będą korzystać z systemu (w większości przypadków), więc wdrożenie w piątek jest równoważne wdrożeniu w poniedziałek rano, jeśli masz niskie wykorzystanie w weekend.

Z drugiej strony zakupy online są zwykle używane częściej w weekendy, więc zdecydowanie odradzamy wdrażanie jednego z nich w piątek.

Zależy to również od polityki pomocy technicznej poza godzinami pracy. Jeśli masz kogoś na wezwanie, który może przywrócić oprogramowanie, jest to mniejsze ryzyko. Mimo wszystko wolałbym to robić w ciągu tygodnia pracy.

Zwykle wdrażamy rzeczy od wtorku do czwartku, wolimy unikać poniedziałku (nasz najbardziej pracowity dzień) i weekendu (kiedy błąd może pozostać niezauważony, powodując problemy)


3

Nigdy nie planowałbym wdrożenia w piątek, chyba że planowałbym być w biurze w sobotę, sprawdzając, czy działa poprawnie, jeśli skończysz wdrażanie w piątek z powodu poślizgu, grozi Ci duże niebezpieczeństwo pośpiechu, znacznie lepiej poczekaj , pozwól wszystkim uspokoić się w weekend, a następnie wyślij w poniedziałek po porannym przeglądzie.

Jeśli wdrożenie trwa w weekend, rozpoczęcie w piątek wieczorem może dać dobry początek, ponieważ biuro często opróżnia się nieco wcześniej, więc całkowite obciążenie systemu będzie mniejsze niż powiedzmy w poniedziałek rano.


2

Pracowałem z firmą, która miała politykę wdrażania w piątki; byli w Izraelu i sobota jest zwykle ostatnim dniem tygodnia pracy. Tak czy inaczej...

W mojej ostatniej firmie zasadą było dostarczanie Opsowi pakietu wdrożeniowego nie później niż w porze lunchu we wtorki i czwartki. Oznacza to, że mają pół dnia, aby to wydać i poprosić o drobne poprawki, jeśli coś pójdzie nie tak z ostatnią fazą kontroli jakości przed transmisją na żywo. (Każda inna kontrola jakości może mieć miejsce o dowolnej porze tygodnia, ponieważ nie jest na żywo).

Dopuszczenie do dowolnego środowiska z wyjątkiem transmisji na żywo jest w porządku w dowolnym momencie, jeśli operatorzy mają na to czas (oczywiście i tak należy to zarezerwować z wyprzedzeniem), ale nigdy nie zezwalaj na życie:

Poniedziałek - źle, właśnie wróciłeś z weekendu (miejmy nadzieję, że nie pracujesz) i nie będziesz mieć wszystkiego, co zrobiłeś w zeszłym tygodniu. Środa - zwykle najmniej produktywny dzień tygodnia, stanowiący środek dnia. Jeśli Twój automat był we wtorek i przegapiłeś go z powodu błędów, środa jest prawdopodobnie złym wyborem, ponieważ nie masz wystarczająco dużo czasu na naprawienie i przetestowanie tych błędów. Piątek - chodź. Poważnie? Jest piątek. Jeśli to naprawdę wymaga wyjaśnienia, oznacza to, że nie masz wystarczającego doświadczenia, aby zajmować takie stanowisko kierownicze, na jakim jesteś. Ale poważnie, dzieje się tak dlatego, że wdrażanie pracy w piątki oznacza wolontariat klientów, którzy przychodzą w weekendy, aby przetestować swoją pracę na żywo środowisko. Dla mnie to przebija każdy idiotyzm, do którego możesz się przygotować.


1
Zgadzam się, że wysyłka w piątki jest zła. Chciałem, aby społeczność StackOverflow podała mi solidne powody, abym mógł łatwo przekonać mojego menedżera, aby uniknął jakiejkolwiek możliwości piątkowych wdrożeń. I mam nadzieję, że ten wątek pomoże innym programistom, takim jak ja, uniknąć okropnych piątkowych wdrożeń :)
Bill Paetzke

0

Mamy szczęście, że możemy dobrze wykorzystać różnicę czasu, mamy biura rozrzucone po całym świecie. Dlatego dokonując aktualizacji dla klientów, organizujemy to tak, aby było to robione z dnia na dzień dla klienta, aby zminimalizować wpływ na nich.

działa to dobrze, gdy kontrolujesz wdrażanie i wdrażanie oprogramowania, ale wypuszczanie na stronę internetową to zupełnie inne zwierzę. Jak już zauważyli inni, upewnij się, że masz czas na:

  1. Wspieranie dziwactw i błędów, które mogą wystąpić
  2. Wspieranie użytkowników w przejściu
  3. Poprawki w ostatniej chwili
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.