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.

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ę.

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.

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.

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.

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.

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.

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.

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.

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.

2. 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).

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.