Gałęzie w repozytorium

Od samego początku organizujemy nasze repozytoria tak, aby odpowiadały potrzebom naszej metody pracy z kodem. Używamy dwóch głownych gałęzi (master i development) oraz wielu dodatkowych gałęzi odpowiadających funkcjonalnościom i poprawkom. Gałąź master odzwierciedla kod środowiska produkcyjnego, natomiast development jest odniesieniem wewnętrznego środowiska programistycznego. Dla każdej nowej funkcjonalności tworzymy odrębną gałąź łącząc ją z elementem backlogu. To podejście pozwala lepiej monitorować postępy. Używamy również ustandaryzowanego nazewnictwa, co pozwala lepiej rozróżniać gałęzie i ich cele. Istotne kroki milowe zamrażamy w formie tagów.

Programowanie

Dajemy pełną wolność wyboru naszym programistom co do używanego IDE i edytora tekstowego ponieważ mamy dobrze ustandaryzowane wymagania dotyczące kodu. Przestrzegamy wewnętrznych standardów dotyczących nazewnictwa, formatowania, ponownego użytkowania kodu, struktury kodu, architektury, organizacji plików w projekcie. To wszystko pozwala nam tworzyć jednolity, czysty i wydajny kod. Używamy głównie dwóch podejść do projektowania rozwiązań w zależności od potrzeb projektowych - FDD (feature driven development) lub TDD (test driven development). Stawiamy również mocno na wzorce projektowe. Na koniec kod refaktoryzujemy i używamy linterów, żeby pozostał optymalny, spełniał nasze standardy i zaspokajał wszystkie potrzeby projektowanego rozwiązania.

Visual Studio

VS Code

Visual Studio for mac

JetBrains Rider

Vim

Notepad

Pull requesty i przegląd kodu

Każda linia kodu, którą dodajemy do naszych głównych gałęzi jest podwójnie sprawdzana. Wykorzystujemy metodę krzyżowych weryfikacji przez programistów. Sprawdzamy kod z wielu perspektyw - od kwestii architektonicznych, przez strukturę, złe wzorce, problemy z nazewnictwem i formatowaniem po literówki. Dzięki temu możemy wyłapać potencjalne zagrożenia na etapie projektowym, zoptymalizować kod i uczynić bezpieczniejszym jeszcze przed etapem testów. Zdarza się, że musimy czasem wycofać zmiany i przemyśleć sposób rozwiązania usuwając pull request. Ale lepiej jest zrobić to na etapie przeglądania kodu, niż stwarzać problemy na produkcji.

Wielopoziomowa weryfikacja

Weryfikacja krzyżowa

Wszystkie komentarze rozwiązane

Minimalnie dwóch recenzentów

Testy

Ostatnim krokiem, a zarazem najważniejszym krokiem jest testowanie. Podczas developmentu kod przechodzi testy jednostkowe i integracyjne. Następnie używamy testów automatycznych z przygotowanych wcześniej scenariuszy i testów manualnych. Jeżeli wszystko pójdzie bezbłędnie jesteśmy gotowi złączyć kod z gałęzią developerską i przygotować drugi pull request do środowiska produkcyjnego, gdzie kod z wielu gałęzi zostanie poddany ponownie procesowi testowania.

Jednostkowe

Manualne

Integracyjne

Automatyczne

Jak pracujemy z kodem