- Każde zadanie do wykonania powinno mieć swoje odzwierciedlenie jako task w naszym systemie zarządzania taskami (Clickup). Po przeczytaniu treści zadania i w razie rozpoczęcia pracy nad nim, zadanie powinno zostać przesunięte do kolumny In Progress, aby zakomunikować pozostałej części zespołu o pracy nad nim.
- Rozpoczynając pracę nad danym taskiem, pamiętaj o stworzeniu Gitowego brancha z odpowiednią nazwą (proces został opisany na stronie Proces pracy z Gitem). Używamy wcięcia w kodzie jako 4 spacje (1 tab = 4 spacje), chyba że w danym projekcie jest ustalone od początku o używaniu 2 spacji.
Developer powinien pilnować wcięć, dodawać stosowane komentarze (jeśli są potrzebne, choć wyznajemy zasadę, że dobry kod jest self-explanatory od samego początku) oraz pisać kod stosując najpopularniejsze koncepty programowania jak KISS, DRY, SOLID oraz YAGNI. - Po zakończeniu pracy nad danym zadaniem, obowiązkiem developera jest je przetestować, sprawdzając dokładnie założenia. Jest to najważniejszy punkt z opisanego procesu. Oddając zadanie do dalszych testów, developer powinien być absolutnie pewny swojej pracy i że wszystko działa jak należy. Dalszy proces QA powinien być jedynie formalnością, potwierdzeniem, że wszystko funkcjonuje prawidłowo.
- Każde zadanie powinno zostać umieszczone na naszym stagingowym serwerze bigpic.dev w odpowiednim folderze odpowiadającym danemu projektowi, aby team w UK mógł również przetestować projekt przed wysłaniem do klienta. Za testy odpowiada zazwyczaj Georgina z UK teamu, ale może to być każda inna osoba z angielskiego zespołu. Przez umieszczenie zadania na stagingu mamy na myśli przełączenie brancha na stagingu (należy połączyć się przez SSH do serwera i w odpowiednim folderze wykonać git checkout i [jeśli jest taka potrzeba] wykonać inne polecenia, jak np. uruchomienie migracji].). Developer powinien upewnić się, że projekt na stagingu, po uruchomieniu z nowego brancha, również działa w porządku.
- Jak tylko projekt i dane zadanie jest już widoczne na stagingu, w systemie zarządzania taskami należy przesunąć ticket do kolumny QA Ready. Developer powinien poinformować w komentarzu o zakończeniu pracy, umieszczając link do strony na stagingu i oznaczając osobę, która ten task dodała, prosząc o przetestowanie. Dobrze jest dodać krótki komentarz na temat wykonanej pracy oraz co i jak testować.
- Jeżeli podczas testów stwierdzono nieprawidłowości, osoba z UK poinformuje o tym developera za pośrednictwem komentarza w tasku. Błędy należy bezzwłocznie poprawić.
Jeśli wszystko jest w porządku i developer otrzymał zielone światło, o “pójściu live”, ticket powinien będzie przesunięty do kolumny To deploy albo Code Review. Code Reviews są w naszym zespole nieobowiązkowe! Niemniej jednak, jeżeli jako twórca jakiejś funkcjonalności, za którą jesteś odpowiedzialny, uważasz, że dobrze byłoby skonsultować kod z kimś innym – poproś innego członka zespołu z tego samego działu, tworząc Pull Request, zgodnie z procesem opisanym tutaj.
Developer powinien również poinformować w komentarzu o ewentualnym czasie, kiedy aplikacja może nie działać prawidłowo podczas wykonywania deployu (tzw. downtime – być może pójście live z projektem może wiązać się z dodatkowymi operacjami, które muszą zostać wykonane manualnie podczas pójścia live). Wtedy UK team w porozumieniu z klientem ustali stosowną datę i godzinę deployu (np. wczesne godziny poranne, kiedy ruch na stronie/aplikacji jest mały). - Jeśli w wyniku Code Review pojawiły się dodatkowe requesty związane z kodem, prawidłowym działaniem – osoba dokonująca CR poinformuje o tym developera za pośrednictwem komentarzy w PR. Developer powinien ustosunkować się do komentarzy i/lub nanieść stosowne poprawki.
- Jeśli PR zostanie zatwierdzony, developer samodzielnie dokonuje merge’owania. Jeśli np. developer pracował nad jakąś funkcjonalnością na branchu develop_menu-bug-fix, ów branch powinien zostać zmerge’owany do brancha develop (tak jak wskazuje oryginalny PR), a następnie branch develop powinien zostać zmerge’owany do brancha master (zaleca się, aby po prostu stworzyć kolejny PR przez BitBucketa – merge brancha develop do master).
- Deploy na produkcję odbywa się automatycznie za pośrednictwem naszego CI/CD tool o nazwie Jenkins. Jeżeli dokona się merge’u brancha develop do master, Bitbucket za pośrednictwem Post-Hooków uruchomi odpowiedni job na Jenkinsie, który wykona szereg operacji, aby dokonać deploymentu. O postępach deploy Jenkins wysyła powiadomienia na specjalny kanał na Slacku o nazwie #jenkins-builds, którego każdy developer powinien obserwować.
- Jeśli “pójście live” zakończyło się porażką (co nie powinno się zdarzyć na tym etapie), należy bezzwłocznie poinformować lidera zespołu lub innego członka zespołu. Należy wtedy podjąć szybkie działania, aby strona/aplikacja produkcyjna powróciła do prawidłowego działania.
Jeśli wszystko jest OK, developer informuje o zakończonym procesie wszystkie dodane w tasku osoby. W ten sposób UK team poinformuje klienta o zakończonej pracy.