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 zaby 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 najpopularniesze 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.
Jeżeli podczas testów stwierdzono nieprawidłowości, osoba z UK poinformuje o tym developera za pośrednictwem komentarza w tasku. Błedy 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ła 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.