Mój współpracownik popełnia i pcha bez testowania


113

Kiedy mój współpracownik myśli, że nie ma potrzeby przeprowadzania testu na swoim komputerze, wprowadza zmiany, zatwierdza, a następnie naciska. Następnie testuje na serwerze produkcyjnym i zdaje sobie sprawę, że popełnił błąd. Zdarza się to raz w tygodniu. Teraz widzę, że dokonał 3 zatwierdzeń i przepycha się z wdrożeniem na serwerze produkcyjnym w ciągu 5 minut.

Kilka razy powiedziałem mu, że nie w ten sposób wykonuje się dobrą pracę. Nie chcę znów być dla niego niegrzeczny, a on ma taki sam status jak ja w firmie i pracował tu więcej niż ja.

Chcę, aby to zachowanie zostało w jakiś sposób ukarane lub uczyniło je jak najbardziej nieprzyjemnym.

Zanim zacząłem, firma wdrażała przy użyciu antycznych metod, takich jak FTP, i nie było kontroli wersji.

Zmusiłem ich / nas do korzystania z Git, Bitbucket, Dploy.io i HipChat. Wdrożenie nie jest automatyczne, ktoś musi się zalogować do dply.io i nacisnąć przycisk wdrażania.

W jaki sposób mogę zmusić ich do nie testowania na serwerze produkcyjnym? Coś takiego jak bot HipChat może wykryć powtarzające się zmiany w tym samym wierszu i wysłać powiadomienie do programisty.


1
Komentarze nie są przeznaczone do rozszerzonej dyskusji; ta rozmowa została przeniesiona do czatu .
Inżynier świata

5
Ponieważ korzystasz z Git, użyj żądań ściągania, aby wymusić recenzje kodu przed połączeniem z serwerem głównym i wdrożeniem do produkcji. Usuń także jego poświadczenia, aby zalogować się do serwera wdrażania. Scentralizuj ten organ w programie innym niż programista. (Nawiasem mówiąc, wymaga tego zgodność PCI wymuszona przez przemysł kart kredytowych.)
Barett

3
Z punktu widzenia miejsca pracy, jeśli jesteś współpracownikiem tej osoby, a nie w jakikolwiek sposób jej przełożonym, prawdopodobnie nie zyskasz żadnej troski poprzez „ukaranie” jej. Skoncentruj się na zapewnieniu jakości kodu, a nie na odpłatności za luźne standardy współpracownika.
Zibbobz

2
Czy wypychanie do „centralnego” repozytorium zawsze wyzwala wdrożenie produkcyjne? Zdecydowanie nie powinno.
jpmc26

3
Przeczytałem pytanie i powiedziałem sobie, że facet musi być Turkiem i proszę bardzo :) sprawdź to, bracie: nvie.com/posts/a-successful-git-branching-model . Musisz mieć co najmniej dwie gałęzie: master i dev, gdzie programiści naciskają tylko na dev, a po przetestowaniu scalasz się, aby opanować i wdrożyć.
Cemre

Odpowiedzi:


92

Potrzebujesz odpowiedniego procesu zapewniania jakości (QA).

W profesjonalnym zespole programistów nie przechodzisz od prawa do programowania do produkcji. Masz co najmniej trzy oddzielne środowiska: programowanie, tworzenie scenariuszy i produkcję.

Kiedy wydaje ci się, że coś działa w twoim środowisku programistycznym, najpierw przechodzisz do testowania, w którym każde zatwierdzenie jest testowane przez zespół kontroli jakości i tylko wtedy, gdy test ten zakończy się powodzeniem, zostaje przeniesiony do produkcji. Idealnie, rozwój, testowanie i pchanie do produkcji są wykonywane przez oddzielne osoby. Można to zapewnić, konfigurując system automatyzacji kompilacji w taki sposób, że programiści mogą wdrażać tylko od etapu programowania do etapu przejściowego, a zespół ds. Kontroli jakości może wdrażać tylko od etapu przejściowego do wersji produkcyjnej.

Jeśli nie możesz przekonać kierownictwa do zatrudnienia kogoś do wykonania kontroli jakości, być może jeden z was może odegrać tę rolę dla drugiego. Nigdy nie pracowałem z diploy.io, ale niektóre systemy automatyzacji kompilacji można skonfigurować w taki sposób, aby użytkownik mógł wdrożyć zarówno od fazy projektowania do wersji testowej, jak i od wersji etapowej do produkcji, ale nie dla obu wersji dla tej samej wersji, więc druga osoba jest zawsze wymagane (ale upewnij się, że masz osoby rezerwowe na wypadek nieobecności jednego z was).

Inną opcją jest zlecenie pracownikom obsługi technicznej wykonania kontroli jakości. Może to wydawać się dodatkową pracą, ale zapewnia również, że są świadomi wszelkich zmian w aplikacji, które mogą zapewnić im pewną pracę na dłuższą metę.


Pomysł Wsparcia w zakresie zapewniania jakości, gdy wiąże się to z wydaniem do Produkcji, wydaje się wygodny, ale nie poleci z powodu rozdzielenia funkcji. Wsparcie, które jest odpowiedzialne za wsparcie wykraczające poza „testowanie programistów”, powinno uświadomić im zmiany. To naprawdę trudne z czterema programistami i nikim innym :-) Jeśli zmienisz odpowiedź, aby bezpośrednio zastosować się do konfiguracji PO, to jest to nikomu się nie
przyda

1
@BillWoodger dlaczego? Dla nich jest to system „nadchodzących zmian i przywracania”. Nie tylko zyskują, widząc, co się wydarzy, zanim „stanie się rzeczywistością”, ale także sposób na łatwe cofnięcie do ostatniej wersji, jeśli coś pójdzie nie tak. Nie zapomnij, że env testowania to testowanie na końcu programisty.
gbjbaanb,

1
@gbjbaanb, ponieważ ustawia obsługę w tej samej pozycji i przywraca pierwotny problem. Wsparcie miałoby na ogół dostęp awaryjny do produkcji. Jeśli mają także inny dostęp, masz problemy z audytem (jeśli jest to ważne). Jeśli ktokolwiek może coś zmienić , to jest problem. Oczywiście wsparcie powinno wiedzieć wszystko, nie powinno być w stanie zrobić wszystkiego. Tak mówi każdy audytor, z jakim kiedykolwiek byłem zaangażowany, i przekonali mnie o tym dawno temu.
Bill Woodger,

@BillWoodger Nie jestem pewien, co mówisz. Zespoły produkcyjne, które znam, zwykle mają swoje własne procesy wdrażania, które obejmują środowisko testowe (aby najpierw sprawdzić głupie błędy). W małym zespole nie ma powodu, dla którego ten system testowy nie może być udostępniany przez programistów i wsparcie. I tak nie są dozwolone żadne zmiany - jest zapełniane przez programistę za pośrednictwem automatyzacji i pochłaniane przez wsparcie. Nie inaczej, jak dać im kod pocztowy o tym samym kodzie. Audytorzy zajmują się procesami, a nie ich wdrażaniem (oczywiście oprócz tego, że są przestrzegane)
gbjbaanb

1
Audytorzy @gbjbaanb zajmują się dostępem do wszystkiego. Jeśli pracownik pomocy technicznej może zmienić program w dziale rozwoju i wprowadzić go do produkcji bez interwencji innych osób, system jest narażony. Jasne, z czterema osobami OP nie ma oddzielnego „wsparcia”, a zadowalający podział funkcji będzie trudny.
Bill Woodger,

54

Prawdopodobnie będziesz chciał zdobyć serwer deweloperów, a najlepiej środowisko testowe. Nikt nigdy nie powinien przesuwać się z lokalnego na produkcyjny, z wyjątkiem własnej strony internetowej. Twój proces wdrażania powinien obsługiwać tylko dev-> staging-> prod. Prawdopodobnie potrzebujesz kogoś odpowiedzialnego za podpisywanie nowych wersji - w zależności od organizacji może to być kierownik projektu, dedykowana kontrola jakości lub obowiązek, który zmienia się co tydzień (z namacalnym przypomnieniem, np. Tylko osoba z puszystą zabawką, którą dostanie ten tydzień Pchać). Przedyskutuj to jednak ze swoim zespołem, aby uzyskać wpisowe (patrz poniżej).

Chcę, aby to zachowanie zostało w jakiś sposób ukarane lub uczyniło je jak najbardziej nieprzyjemnym.

Możesz mieć swój zestaw testowy (masz jeden z nich, prawda?) Obejmujący sprawdzenie, które określa, czy jesteś na serwerze produkcyjnym, a jeśli tak, wysyła do wszystkich wiadomości e-mail z informacją Looks like $username is testing on prod, watch out. Być może publiczne zawstydzanie twojego kolegi byłoby nieprzyjemne. Lub możesz wprowadzić ograniczenia techniczne, takie jak zakaz IP dla twojego zespołu patrzenia na prod (co możesz znieść, ale musisz to uzasadnić).

Nie polecam tego, ale wyglądałbyś na problem, a nie na osobę, która testuje prod i możesz stać się bardzo niepopularny wśród ludzi w zespole, którzy nie dbają o to.

Z pewnością tak naprawdę nie chcesz, aby to zachowanie było karane, ale by się skończyło ?

Zmusiłem ich / nas do korzystania [...]

Wspaniale jest, że opowiadasz się za usprawnieniem przepływu pracy, ale brzmi to tak, jakbyś nie myślał zbyt wiele o swoich współpracownikach i / lub że nie masz ich pełnego wsparcia. Prawdopodobnie spowoduje to, że koledzy na pół rozpalą interakcję z przepływem pracy, wykonując minimum niezbędne do wprowadzenia kodu do produkcji, i tak naprawdę nie będą postępować zgodnie z duchem przepływu pracy, co będzie oznaczało więcej czasu poświęcanego na czyszczenie. A kiedy spędzasz coraz więcej czasu na usuwaniu skutków nieodpowiedniej interakcji z przepływem pracy (ponieważ nikogo to nie obchodzi, prawda?) Wszyscy inni będą kwestionować sam przepływ pracy.

Zacznij więc od rozmowy.

Dowiedz się, dlaczego tak się dzieje (czy maszyna twojego kolegi nie jest tak dobra do testowania? Czy twój kolega jest niepewny z gałęziami funkcji lub utknął w myśleniu svn, w którym zatwierdzanie i wypychanie są takie same?), Wyjaśnij, dlaczego problemem jest to, że testuje się kod na dev / staging / prod i zobacz, czy możesz zrobić coś, aby zmienić przyczynę tego (Twój kolega chętniej zrobi to, co chcesz, jeśli tylko sprawiłeś, że fajniej jest testować lokalnie, niż gdybyś go skrytykował).

Jeśli nie możesz tego rozwiązać, a to naprawdę sprowadza się do różnicy zdań, zaplanuj dyskusję w zespole na następnym spotkaniu retrospektywnym, zobacz, co robią i myślą twoi koledzy. Zrób uzasadnienie, ale posłuchaj konsensusu. Być może twój zespół twierdzi, że nie można testować poprawek tekstowych lokalnie, a ty masz po prostu zasadę, że żadne duże funkcje nie są testowane przez programistów. Zapisz na spotkaniu i przeczytaj, co wspólnie decydujesz o tym, co jest dozwolone w każdym środowisku. Ustaw datę za kilka miesięcy, aby ją przejrzeć, być może z perspektywy czasu.


10
+1 za rozmowę. Musi być wspólne zrozumienie, że jest to problem i dlaczego. Tylko wtedy rozwiązanie techniczne może odnieść sukces.
Patrick,

9
+1 za uzyskanie środowiska deweloperskiego / środowiska testowego. Dopóki nie będzie prawdziwego miejsca poza własną maszyną do popychania rzeczy, takie zachowanie nie jest całkowicie winą współpracownika. Tylko tyle można zrobić na własnej maszynie, a jeśli nic więcej, dodatkowe środowisko często pomaga w zmianie procesu myślowego / podejścia do testowania.
Joel Coehoorn,

20

W pracy unikamy tego, używając Gerrit . Gerrit to system przeglądania kodu, który działa jak brama do głównej / produkcyjnej gałęzi Git, która jest tradycyjnie nazywana „master”. Masz recenzje kodu, prawda? Wygląda na to, że robisz to wyjątkowo. Dzięki Gerrit przechodzisz do pewnego rodzaju gałęzi pośredniej, która po tym, jak ty i twój współpracownik wykonacie proces sprawdzania kodu w zadowalający sposób, następnie łączy się z gałęzią główną. Możesz nawet podłączyć Gerrit do serwera CI, aby wykonać testy jednostkowe, zanim ktokolwiek otrzyma wiadomość e-mail z prośbą o sprawdzenie zmiany. Jeśli nie masz serwera, na którym możesz skonfigurować narzędzie CI, Codeship ma fajny darmowy plan do wykorzystania jako dowód koncepcji.

Ostatnim oczywiście jest zautomatyzowanie wdrożeń produkcyjnych tylko w oparciu o zatwierdzone produkty kompilacyjne, które przetrwały przegląd kodu i testy jednostkowe. Pojawiają się pewne fajne technologie, o których nie wspomnę ze strachu, że będzie to przynęta na płomienie.

Idź do swojego szefa z rozwiązaniem. Ten dotyczy nawet ciebie i jest sposobem na poprawę jakości kodu każdego, a nie tylko na ukaranie współpracownika.


17

Uważam to za problem w dużej mierze ludzki - proces istnieje i narzędzia, ale proces nie jest przestrzegany.

Zgadzam się z tym, co mówili inni tutaj o możliwość, że jest to całkiem możliwe, deweloper w pytaniu jest tylko tkwi w SVN myślenia i może pomyśleć, że jest następujący proces.

Uważam, że najlepszym sposobem rozwiązania tego rodzaju problemów, szczególnie tam, gdzie może nie być wyraźnego przełożonego, nie jest kręcenie się nad karami lub usunięciem dostępu - prowadzi to tylko do urazy i wydaje się, że jesteś głośnym zwolennikiem śledzenia proces (zawsze jest jeden, a ja byłam „tym facetem” wcześniej), to ty prawdopodobnie poradzisz sobie jak najwięcej ciepła. Chodzi przede wszystkim o doprowadzenie ludzi do porozumienia w sprawie tego procesu.

W tym przypadku bardzo przydatne mogą być zorganizowane spotkania, takie jak spotkania typu „wyciągnięte wnioski” po poważnym incydencie w produkcji. Postaraj się, aby wszyscy się zgodzili, w tym programiści, że przegląd kodu, testy jednostkowe, kompleksowe testowanie itp. Muszą odbywać się za każdym razem (możesz tu również wprowadzić ideę środowiska przejściowego). To nie powinno być trudne i jest bardzo rozsądne. Następnie poproś zespół, aby wspólnie opracował solidne zasady dotyczące tego, jak należy to zrobić. Im więcej programista, który powoduje problem, tym bardziej będą chcieli przestrzegać zasad i zaczną rozumieć, dlaczego ich zachowanie stanowi problem.

Ostatnim punktem jest to, aby nigdy nie wpaść w „no cóż, jest lepiej niż kiedyś!” pułapka. Zawsze jest miejsce na ulepszenia. Z mojego doświadczenia wynika, że ​​ludzie z branży IT zaczynają zadowalać się tym, co mają, po wprowadzeniu kilku ulepszeń. Osiedlenie trwa następnie, aż znów znajdziesz się w punkcie kryzysowym.


1
Naprawdę nie jestem pewien, w jaki sposób „zatwierdzanie / wypychanie, natychmiastowe wdrażanie do produkcji i testowanie zmian tam i nigdzie indziej” to sposób myślenia SVN ... Jedyną częścią tego procesu, która dotyczy SVN, jest zatwierdzanie. Nawet w przypadku pojedynczego modelu gałęzi lub kontroli źródła zatwierdzenie niekoniecznie oznacza wdrożenie produkcyjne. A przynajmniej nie powinno.
jpmc26,

@ jpmc26: Ryzyko wojny płomieniowej Git / SVN: odziedziczyliśmy system SVN dla większości naszego „starszego” kodu, ale używaliśmy Git do naszej nowej pracy. Mogę prawie zagwarantować, że nie mieliśmy właściwej konfiguracji SVN i / lub nie używaliśmy jej właściwie, ale obsługa gałęzi przez Git jest znacznie łatwiejsza w obsłudze. Jestem w 100% pewien, że SVN jest więcej niż w stanie obsłużyć prawidłowe wdrożenie, ale widzę również (z mojego niedoskonałego doświadczenia), w jaki sposób SVN może „odwieść cię mniej” od robienia właściwych rzeczy. W każdym razie byłby to tylko czynnik dodatkowy, a edukacja użytkownika jest ważniejsza.
TripeHound

1
@TripeHound Brak argumentów na temat tego, że system git jest ogólnie lepszy do zarządzania zmianami w kodzie. (Moje zastrzeżenia do git zwykle dotyczą wysokiej krzywej uczenia się). Chodzi mi o to, że chociaż git może mieć więcej możliwości pomocy w zarządzaniu procesem wydania, sposób konfiguracji infrastruktury kompilacji jest nadal głównym czynnikiem wybór kontroli źródła. Miałem dość udaną automatyzację kompilacji i wydawania działającą w SVN od dłuższego czasu, więc nie jestem do końca jasne, co to jest „sposób myślenia SVN” lub jak negatywnie wpływa na twoje wydanie.
jpmc26

2
To, że zobowiązujesz się do opanowania, nie oznacza, że ​​powinieneś wdrożyć do produkcji. Nawet jeśli twoje oryginalne repozytorium / repozytorium svn znajduje się na serwerze prod, nie oznacza to takiej rzeczy.
vonPetrushev

12

Nie jest to rzadkie , szczególnie w małych zespołach. Nie rób z tego wielkiej sprawy, ale nieformalną zasadę:

Przerwij kompilację, przynieś pączki.

Albo 1) Dostaniesz pączki dwa razy w tygodniu lub 2) będą przestrzegać standardu.

Przywołaj to na spotkaniu. Nie oskarżajcie, nie wspominajcie nikogo po imieniu, ale coś podobnego do: „Od czasu wprowadzenia standardów kontroli wersji i wdrażania, sprawy stały się znacznie łatwiejsze, a serwer działa dłużej niż kiedyś. To świetnie! Jednak nadal kusi, aby skorzystać ze skrótu i ​​przesłać bez odpowiedniego testowania. To jednak hazard, a nasz serwer jest na linii. Sugeruję, że odtąd jeśli którykolwiek z nas prześle kod, który łamie serwer, osoba odpowiedzialna wprowadza pączki dla zespołu następnego dnia. ”

W razie potrzeby zamień pączki na coś innego i nie rób tego drogim - lunch dla całego zespołu byłby zbyt duży, ale pudełko pączków o wartości 5 USD lub taca z owocami / warzywami, frytki i dip itp. Prawdopodobnie byłyby irytujące wystarczająco, aby faktycznie zważyć ryzyko z wygodą pomijania testów bez obciążania, które odciągałoby ich od zespołu lub firmy.


2
Działa to tylko z biurem. Jaka jest równoważna koncepcja, gdy masz rozproszony zespół zdalnych programistów pracujących w domu?
aroth

2
@aroth W przypadku niektórych zespołów wystarczy prosty e-mail od osoby, która złamała kompilację. Zaplanuj go jako „cel ciągłego doskonalenia procesu” i poproś, aby wiadomość e-mail zawierała wystarczającą ilość informacji, aby inni mogli zobaczyć, co poszło źle, dlaczego poszło nie tak i co ta osoba zmieni w swoim procesie lub o czym sugeruje zespół proces, aby zapobiec ponownemu wystąpieniu. Większość ludzi nienawidzi raportów i raportów, a to znowu jest irytujące, że mogą być bardziej ostrożni, aby nie złamać kompilacji w przyszłości.
Adam Davis

8

Jak mogę je zmusić ...

Zamiast zmuszać współpracowników, staraj się, aby widzieli rzeczy z Twojej perspektywy. To znacznie ułatwi wszystkim. Co prowadzi mnie do ...

Chcę, aby to zachowanie zostało w jakiś sposób ukarane lub uczyniło je jak najbardziej nieprzyjemnym.

Dlaczego masz problemy z serwerem na żywo, ale nie dla tego faceta? Wiesz coś, czego on nie wie? Co możesz zrobić, aby zobaczył rzeczy tak, jak Ty?

Jeśli ci się to uda, wydobędziesz z niego to, co najlepsze, a on znajdzie rozwiązania problemu, o którym nigdy nie myślałeś.

Ogólnie staraj się współpracować z ludźmi, aby rozwiązywać problemy, zamiast zmuszać ich do procesów, których nie rozumiesz.


6

Co może się stać najgorsze? Czy masz wystarczająco dobre kopie zapasowe, aby naprawić błąd modyfikujący losowe rekordy w bazie danych, przywracając starą wersję?

Załóżmy, że masz błąd, w którym używasz identyfikatora rekordu, i przez pomyłkę kwota rachunku w centach jest przechowywana w zmiennej używanej dla identyfikatora rekordu. Więc jeśli zapłacę 12,34 USD, wówczas rekord o identyfikatorze 1234 zostanie zmodyfikowany. Czy uda ci się to naprawić, jeśli oprogramowanie będzie działać przez kilka godzin, aż do wykrycia błędu? (Jeśli zarówno poprawny rekord, jak i rekord 1234 zostaną zaktualizowane, można to wykryć tylko wtedy, gdy użyty zostanie rekord 1234, więc może to pozostać niewykryte przez dłuższy czas).

Teraz zapytaj wysoce zmotywowanego programistę, co o tym myśli. Oczywiście nie może twierdzić, że nigdy nie popełnia błędów, ponieważ robił to w przeszłości.


„Czy masz wystarczająco dobre kopie zapasowe” - a nawet jeśli tak, to czy twój kolega chce być mugolami, którzy muszą przywrócić kopię zapasową, ponieważ zepsuł serwer? Być może, że on lubi w zasadzie do testowania przed wdrożeniem, ale ponieważ nie ma środowisko testowe zabiera najprostszy aktualnie dostępną opcję. W takim razie uzasadnienie serwera testowego powinno być łatwe. Btw, błędy, które pozostają niezauważone „przez dłuższy czas”, przejdą od testu do wdrożenia, ponieważ problemem dla takich błędów jest jakość testowania, a nie miejsce, w którym testy są wykonywane.
Steve Jessop,

Nie tylko masz kopie zapasowe, ale także czy Twoja firma może sobie pozwolić na przestoje podczas przywracania? Czy może sobie pozwolić na utratę minut, godzin, a nawet dni informacji, ponieważ konieczne było wycofanie bazy danych? Powiedziałbym, że w prawie wszystkich nietrywialnych przypadkach odpowiedź brzmi „nie”. Nawet w trywialnych przypadkach nie chcesz, aby „przywracanie kopii zapasowej” zachowywało się podczas sprawdzania niepoddanego testowi kodu. Musi istnieć coś, co zapewnia, że ​​testowanie odbywa się między momentem wpisania kodu a osiągnięciem produkcji.
aroth

W pełni się zgadzam, dlatego powiedziałem „zapytaj programistę, co on o tym myśli”. Albo jest całkowicie złudzony i wierzy, że jego kod nie zawiera błędów, albo nie zdaje sobie sprawy ze szkód, które może wyrządzić. Lub trzecia możliwość, on wie i go to nie obchodzi.
gnasher729

3

Wyraźnie rozumiesz różne możliwe rozwiązania procesowe i techniczne. Problem polega na tym, jak zarządzać współpracownikiem.

Jest to w zasadzie ćwiczenie zarządzania zmianami.

Po pierwsze, chciałbym porozmawiać z założycielem, aby upewnić się, że on / ona jest na pokładzie z twoim punktem widzenia. Jeśli nastąpi przerwa produkcyjna, spodziewam się, że założyciel byłby bardzo zaniepokojony tym i pragnąłby zmiany.

Po drugie, pracujesz w małym zespole i prawdopodobnie warto spróbować zaangażować cały zespół w doskonalenie procesu.

Ustaw regularne (na przykład cotygodniowe) retrospekcje procesowe. Niech cały zespół:

  • Zidentyfikuj problemy
  • Wolontariuszowe pomysły na poprawę praktyk pracy
  • Zaangażuj się we wdrażanie tych praktyk

Naturalnie powinno wynikać z tego, że cały zespół pomaga również zapewnić zgodność z ulepszonymi praktykami.


Retrospektywa to świetny sposób na zajęcie się i miejmy nadzieję zmienić takie zachowanie w konstruktywny sposób!
greenSocksRock

1

Myślę, że zidentyfikowałeś kilka problemów:

  1. Wygląda na to, że każdy sprawdzany kod może zostać w trywialny sposób przekazany do produkcji każdemu, kto ma uprawnienia do sprawdzania kodu.

Szczerze mówiąc, myślę, że konfiguracja jest po prostu szalona. Osoby, które mogą ręcznie uruchomić wypychanie do produkcji, powinny być co najmniej ograniczone do zbioru osób, którym można całkowicie zaufać, aby dokładnie przejrzeć i przetestować wszystkie zmiany wychodzące (niezależnie od tego, kto był autorem zmian) przed uruchomieniem wypychania. Umożliwienie każdemu, kto ma pozwolenie na wpisanie kodu, uprawnienia do samowolnego uruchomienia produkcji, to po prostu prośba o kłopoty. Nie tylko od nieostrożnych i / lub niekompetentnych programistów, ale także od niezadowolonych lub złośliwych stron trzecich, które zdarzają się złamać jedno z twoich kont.

A jeśli zamierzasz użyć procesu przycisku do wdrożenia każdej wprowadzanej zmiany, musisz mieć kompleksowy zestaw automatycznych testów, a naciśnięcie przycisku musi je uruchomić (i przerwać wdrażanie, jeśli jakiekolwiek testy kończą się niepowodzeniem!). Twój proces nie powinien pozwolić, aby kod, który nawet nie został powierzchownie przetestowany, osiągnął punkt, w którym został wdrożony w systemie produkcyjnym.

Twój współpracownik popełnił duży błąd w zakresie sprawdzania kodu bez testowania go najpierw. Twoja organizacja popełniła znacznie większy błąd , przyjmując proces wdrażania, który pozwala testowanemu kodowi dotrzeć do produkcji w każdych okolicznościach.

Tak więc pierwszym porządkiem biznesu jest naprawa procesu wdrażania. Ogranicz, kto może wywołać wypychanie do produkcji, albo włącz rozsądną liczbę testów do automatycznego procesu wdrażania, albo jedno i drugie.

  1. Wygląda na to, że nie ustaliłeś żadnych jasno określonych standardów / zasad rozwoju.

W szczególności wygląda na to, że brakuje jasnej „ definicji ukończenia ” i / lub użycia takiej, która nie zawiera „kodu został przetestowany”, jako czynnika decydującego o sprawdzeniu kodu w / wdrożeniu kodu do produkcji. Jeśli tak, zamiast wskazywać, że „dobry kod nie jest tworzony w ten sposób”, można powiedzieć „ten kod nie spełnia minimalnych standardów, które wszyscy uzgodniliśmy, i powinien być lepszy w przyszłość".

Powinieneś spróbować stworzyć kulturę, która jasno komunikuje, czego oczekuje się od programistów, a także standardy i poziom jakości, który mają podtrzymywać. Pomoże w tym zdefiniowanie definicji czynności obejmującej co najmniej ręczne testowanie (lub najlepiej zautomatyzowane przypadki testowe, które można uruchomić w ramach procesu kompilacji / wdrażania). Może to mieć konsekwencje dla złamania kompilacji. Lub poważniejsze konsekwencje dla zepsucia systemu produkcyjnego. Zauważ, że te dwie rzeczy powinny być naprawdę niezależne, a jednoczesne zerwanie zarówno kompilacji, jak i systemu produkcyjnego powinno być całkowicie niemożliwe (ponieważ uszkodzone kompilacje nigdy nie powinny być możliwe do wdrożenia).


0

Należy zintegrować w firmie proces Continuous Integration + Peer Review. Bitbucket ułatwia.

I +1 do serwera deweloperów sugerowanego przez innych użytkowników.

Nie bądź z nim niegrzeczny, to tylko zaszkodzi twojemu stosunkowi pracy.

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.