Dowiedz się więcej
Poznaj i zrozum jak wygląda
Technologia
Elastyczne zespoły
Sztuczna inteligencja
Cloud / chmura
Rozwój oprogramowania
Projektowanie produktów cyfrowych
Wybrane technologie
Usługi serwisowe IT
Fintech
Przemysł i produkcja
Rozwiązania dedykowane
Oprogramowanie produkcyjne
Rozszerzona rzeczywistość
Oprogramowanie dla branży HoReCa
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.
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.
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.
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.
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.