Jak pracujemy z kodem

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.

Gałęzie w repozytorium
479b9b2 Initial commit - aveneo <aveneo@aveneo.pl> 12349fb Add TypeScript - aveneo <aveneo@aveneo.pl> cc7789e Make it work. - aveneo <aveneo@aveneo.pl> b0f3479 Make it right. - aveneo <aveneo@aveneo.pl> 5bc0361 Make it fast. - aveneo <aveneo@aveneo.pl> features/feature-579_add-typescript 95365bc Merge branch features/feature-579_add-typescript - aveneo <aveneo@aveneo.pl> f6c03da Fix it. - aveneo <aveneo@aveneo.pl> bugs/bug-127_loader e4cae17 Merge branch bugs/bug-127_loader - aveneo <aveneo@aveneo.pl> 09b85ea Prepare v1 - aveneo <aveneo@aveneo.pl> development 8e7fe48 Merge branch development - aveneo <aveneo@aveneo.pl> master v1.0.0

Programowanie

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 Logo
Visual Studio
VS Code Logo
VS Code
Visual Studio for mac Logo
Visual Studio for mac
JetBrains Rider Logo
JetBrains Rider
Vim Logo
Vim
Notepad Logo
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
Pull requesty i przegląd kodu

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
Testy

CI & CD

Dla każdego projektu tworzymy w pełni zautomatyzowane mechanizmy ciągłej integracji i ciągłego wdrożenia (wykorzystując między innymi Azure Pipelines and Azure Artifacts). Od 2019 roku wszystkie nasze rozwiązania wdrażamy z wykorzystaniem kontenerów zgodnych z Docker i Kubernetes.

Jesteś gotowy, żeby porozmawiać o swoim projekcie?