Faza statycznej analizy<\/strong> jest wykonywana przez odpowiednie narz\u0119dzia. Kod mo\u017ce zosta\u0107 wtedy zweryfikowany przez pewne regu\u0142y, na przyk\u0142ad sprawdzaj\u0105ce z\u0142o\u017cono\u015b\u0107 metod. <\/li>\n<\/ol>\n\n\n\n<\/p>\n\n\n\n
Automatyzacja i shift-left testing <\/h2>\n\n\n\n
Ci\u0105g\u0142e testowanie wykorzystuje podej\u015bcia automatyzacji do przyspieszenia testowania poprzez przyj\u0119cie podej\u015bcia shift-left testing, kt\u00f3re \u0142\u0105czy etapy wytwarzania oprogramowania i zapewniania jako\u015bci. Takie podej\u015bcie mo\u017ce obejmowa\u0107 zestaw przep\u0142yw\u00f3w pracy test\u00f3w automatycznych, kt\u00f3re mo\u017cna \u0142\u0105czy\u0107 z narz\u0119dziami raportuj\u0105cymi i metrykami w celu otrzymania jasnego obrazu jako\u015bci oprogramowania. <\/p>\n\n\n\n
Zapewnia to zespo\u0142om projektowym otrzymanie szybkiej informacji zwrotnej na temat jako\u015bci oprogramowania. Pozwala r\u00f3wnie\u017c testowa\u0107 na wcze\u015bniejszych etapach wytwarzania oprogramowania oraz zwi\u0119kszy\u0107 pokrycie testami, eliminuj\u0105c w\u0105skie gard\u0142a testowe, takie jak: dost\u0119p do wsp\u00f3\u0142dzielonych \u015brodowisk testowych czy oczekiwanie na stabilny interfejs u\u017cytkownika. <\/p>\n\n\n\n
Ci\u0105g\u0142e testowanie niesie ze sob\u0105 szereg korzy\u015bci, takich jak:<\/strong> <\/p>\n\n\n\n<\/p>\n\n\n\n
\n- Integrowanie zespo\u0142\u00f3w testowych, deweloperskich i operacyjnych na ka\u017cdym etapie cyklu \u017cycia oprogramowania. <\/li>\n\n\n\n
- Pozwala na wdro\u017cenie test\u00f3w automatycznych w takim zakresie, jak to tylko mo\u017cliwe, aby stale testowa\u0107 kluczowe funkcje. <\/li>\n\n\n\n
- Szybkie i ci\u0105g\u0142e informacje zwrotne, kt\u00f3re s\u0105 istotne r\u00f3wnie\u017c dla biznesu. <\/li>\n\n\n\n
- Usuni\u0119cie w\u0105skich garde\u0142 w kwestii dost\u0119pno\u015bci \u015brodowisk testowych, kt\u00f3re mog\u0105 by\u0107 stale dost\u0119pne. <\/li>\n\n\n\n
- Pozwala na sta\u0142e i aktywne zarz\u0105dzanie jako\u015bci\u0105 w ca\u0142ym etapie dostarczania oprogramowania.\u202f <\/li>\n<\/ul>\n\n\n\n
Fundamenty ci\u0105g\u0142ego testowania <\/h3>\n\n\n\n
Ci\u0105g\u0142e testowanie opiera si\u0119 na kombinacji okre\u015blonych narz\u0119dzi i technik. Odpowiednie ich wdro\u017cenie tworzy system, dzi\u0119ki kt\u00f3remu znacz\u0105co mo\u017cna ograniczy\u0107 liczb\u0119 b\u0142\u0119d\u00f3w przedostaj\u0105cych si\u0119 na \u015brodowiska rozwojowe lub produkcyjne. Wi\u0119kszo\u015b\u0107 b\u0142\u0119d\u00f3w ma bardzo kr\u00f3tk\u0105 \u017cywotno\u015b\u0107, poniewa\u017c s\u0105 one wy\u0142apywane przez testy. Odpowiednie zaimplementowanie tego podej\u015bcia powinno rozpoczyna\u0107 si\u0119 na jak najwcze\u015bniejszym etapie cyklu \u017cycia oprogramowania, aby m\u00f3c je odpowiednio budowa\u0107, aktualizowa\u0107 i (w razie potrzeby) refaktoryzowa\u0107. Sama budowa i dzia\u0142anie zale\u017c\u0105 w g\u0142\u00f3wnej mierze od potrzeb projektowych \u2013 inne testy i techniki b\u0119d\u0105 wykorzystywane do testowania sklepu internetowego, inne do testowania system\u00f3w w bran\u017cy automotive. Lecz niezale\u017cnie od przypadku, cel pozostanie ten sam \u2013 uzyskanie jak najszybciej informacji zwrotnej w przypadku wyst\u0105pienia b\u0142\u0119du. <\/p>\n\n\n\n
Projektowanie ma\u0142ych komponent\u00f3w i us\u0142ug <\/h2>\n\n\n\n
Idea ci\u0105g\u0142ego testowania polega na maksymalnym zautomatyzowaniu proces\u00f3w testowania i wdra\u017cania oraz zapewnieniu, \u017ce ka\u017cdy komponent aplikacji mo\u017ce zosta\u0107 poddany testom, gdy tylko zostanie opracowany. Przyk\u0142ady, kt\u00f3re mog\u0105 u\u0142atwi\u0107 implementacj\u0119 tego podej\u015bcia to: projektowanie ma\u0142ych komponent\u00f3w i us\u0142ug oraz projektowanie danych testowych wykorzystywanych w ci\u0105g\u0142ym testowaniu. <\/p>\n\n\n\n
Projektowanie ma\u0142ych komponent\u00f3w i us\u0142ug \u2013 nowe komponenty powinny nie tylko spe\u0142nia\u0107 okre\u015blone funkcje w trakcie dzia\u0142ania programu, ale r\u00f3wnie\u017c by\u0107 w pe\u0142ni testowalne niezale\u017cnie od innych komponent\u00f3w. Celem jest zapewnienie, \u017ce ka\u017cda w pe\u0142ni przetestowana us\u0142uga b\u0119dzie spe\u0142nia\u0142a swoje zadania zgodnie z za\u0142o\u017ceniami, aby w trakcie ich \u0142\u0105czenia i przej\u015bcia do etapu test\u00f3w integracyjnych komponenty bezproblemowo wsp\u00f3\u0142pracowa\u0142y ze sob\u0105.. Nale\u017cy wi\u0119c ju\u017c na etapie projektowania odpowiednio przygotowa\u0107 architektur\u0119 i ograniczy\u0107 sprz\u0119\u017cenie komponent\u00f3w tak bardzo, jak to mo\u017cliwe. W efekcie zyskamy komponenty bardziej stabilne, kt\u00f3re zmniejsza ryzyko, \u017ce jakakolwiek zmiana dokonana w komponencie \u201eA” spowoduje nieoczekiwan\u0105 zmian\u0119 zachowania w innych komponentach. Ograniczenie po\u0142\u0105cze\u0144 mi\u0119dzy nimi upraszcza proces testowania, rozwi\u0105zywania problem\u00f3w oraz konserwacji. Dodatkowo w \u0142atwiejszy spos\u00f3b mo\u017cna izolowa\u0107 ewentualne problemy \u2013 analizie zostanie poddany konkretny komponent, bez potrzeby przeszukiwania ich grup i zale\u017cno\u015bci mi\u0119dzy nimi. <\/p>\n\n\n\n
Projektowanie danych testowych wykorzystywanych w ci\u0105g\u0142ym testowaniu <\/h2>\n\n\n\n
Posiadanie w pe\u0142ni zautomatyzowanego rozwi\u0105zania do zarz\u0105dzania danymi testowymi jest niezb\u0119dne do solidnego wdro\u017cenia ci\u0105g\u0142ego testowania. Z\u0142ym podej\u015bciem by\u0142oby na przyk\u0142ad kopiowanie produkcyjnej bazy danych w celu utworzenia danych testowych, nie anonimizuj\u0105c uprzednio wra\u017cliwych danych. Tworzenie nowych zestaw\u00f3w danych testowych od zera dla ka\u017cdej serii test\u00f3w r\u00f3wnie\u017c nie jest dobrym pomys\u0142em ze wzgl\u0119du na bardzo s\u0142ab\u0105 efektywno\u015b\u0107, zw\u0142aszcza gdy nie s\u0105 generowane automatycznie. <\/p>\n\n\n\n
Jak zatem stworzy\u0107 skuteczne rozwi\u0105zania do generowania i zarz\u0105dzania danymi testowymi? Z pomoc\u0105 przychodz\u0105 pewne charakterystyki, do kt\u00f3rych mo\u017cna zaliczy\u0107 na przyk\u0142ad: <\/p>\n\n\n\n
\n- Tworzenie i generowanie danych testowych <\/strong>
Daje mo\u017cliwo\u015b\u0107 tworzenia nowych, zbiorczych zestaw\u00f3w danych uwzgl\u0119dniaj\u0105cych zale\u017cno\u015bci, tak jakby pochodzi\u0142y ze \u015brodowiska produkcyjnego. <\/li>\n\n\n\n- Mo\u017cliwo\u015b\u0107 pobrania pewnego podzbioru danych produkcyjnych <\/strong>
Na podstawie okre\u015blonych kryteri\u00f3w, maskowania wra\u017cliwych p\u00f3l i umieszczania ich w \u015brodowisku testowym, zachowuj\u0105c ich integralno\u015b\u0107 referencyjn\u0105. Najtrudniejsza w realizacji jest ostatnia cz\u0119\u015b\u0107: wra\u017cliwe pola musz\u0105 by\u0107 zamaskowane w taki spos\u00f3b, aby zachowa\u0107 oryginalne powi\u0105zania mi\u0119dzy danymi. Przyk\u0142adowo, je\u015bli warto\u015b\u0107 numeru PESEL musi zosta\u0107 zamaskowana i zast\u0105piona niepowi\u0105zan\u0105 warto\u015bci\u0105, ka\u017cde odwo\u0142anie do tego numeru PESEL w bazie danych musi zosta\u0107 zamaskowane t\u0105 sam\u0105 warto\u015bci\u0105. <\/li>\n\n\n\n- Mo\u017cliwo\u015b\u0107 maskowania i transformacji danych <\/strong>
Rozwi\u0105zanie powinno te\u017c zapewni\u0107 mo\u017cliwo\u015b\u0107 automatycznego por\u00f3wnania danych wst\u0119pnie zamaskowanych, aby upewni\u0107 si\u0119, \u017ce nie dosz\u0142o do ich utraty i \u017ce proces maskowania nie spowodowa\u0142 b\u0142\u0119d\u00f3w w ich integralno\u015bci. <\/li>\n\n\n\n- Mo\u017cliwo\u015b\u0107 przesy\u0142ania danych <\/strong>
Proces polegaj\u0105cy na przesy\u0142aniu wyodr\u0119bnionych, zamaskowanych danych na \u015brodowiska testowe, z zachowaniem integralno\u015bci. Proces ten powinien obejmowa\u0107 funkcje dodawania, edytowania, aktualizacji i usuwania. <\/li>\n\n\n\n- Mo\u017cliwo\u015b\u0107 od\u015bwie\u017cania danych <\/strong>
Polega na okresowym przegl\u0105dzie i usuwaniu starych pakiet\u00f3w danych testowych oraz zamienianiu ich na nowy zestaw. <\/li>\n\n\n\n- Ekstrakcja danych i tworzenie ich podzbior\u00f3w <\/strong>
Pozwala na tworzenie mniejszych kopii danych produkcyjnych zdefiniowanych za pomoc\u0105 okre\u015blonych kryteri\u00f3w. <\/li>\n\n\n\n- \u201ePostarzanie” danych <\/strong>
Technika, w kt\u00f3rej dane s\u0105 zmieniane w celu dopasowania ich do okre\u015blonych, specyficznych warunk\u00f3w i wykorzystania ich w pewnych procesach (na przyk\u0142ad symulacji okre\u015blonej godziny lub daty). <\/li>\n\n\n\n- Mo\u017cliwo\u015b\u0107 tworzenia i wyodr\u0119bniania danych testowych <\/strong><\/li>\n\n\n\n
- Zarz\u0105dzanie zbiorami danych <\/strong><\/li>\n\n\n\n
- Wykorzystanie narz\u0119dzi, kt\u00f3re umo\u017cliwiaj\u0105 nie tylko zarz\u0105dzanie wieloma zbiorami danych, ale tak\u017ce ich archiwizacj\u0119 i wersjonowanie.\u202f <\/li>\n<\/ul>\n\n\n\n
Rola test\u00f3w jednostkowych w ci\u0105g\u0142ym testowaniu <\/h2>\n\n\n\n
Podstaw\u0119 test\u00f3w w podej\u015bciu ci\u0105g\u0142ego testowania, zgodnie z piramid\u0105 test\u00f3w, stanowi\u0105 testy jednostkowe. S\u0105 one najszybsze w wykonaniu i sprawdzaj\u0105 dzia\u0142anie oprogramowania we wczesnej fazie jego wytwarzania. Powinno ich wi\u0119c by\u0107 jak najwi\u0119cej (przy zachowaniu odpowiedniego stosunku liczby do jako\u015bci \u2013 nie jest prawd\u0105, \u017ce wi\u0119ksza liczba test\u00f3w stanowi o jako\u015bci). <\/p>\n\n\n\n
Projektowanie test\u00f3w jednostkowych <\/h3>\n\n\n\n
Zdarza si\u0119, \u017ce testy jednostkowe s\u0105 \u017ale zaprojektowane i zamiast jednostek testuj\u0105 kompletne przypadki u\u017cycia (wywo\u0142anie metod, asercje, wywo\u0142anie wi\u0119kszej liczby metod i tworzenie wi\u0119kszej liczby asercji). Takie testy s\u0105 zwykle niestabilne, a b\u0142\u0119dy wykryte w jednej cz\u0119\u015bci kodu mog\u0105 maskowa\u0107 inne b\u0142\u0119dy i utrudnia\u0107 ich wykrycie. Aby temu zapobiec, nale\u017cy przeanalizowa\u0107 takie testy, wyodr\u0119bni\u0107 z nich poszczeg\u00f3lne, testowane funkcjonalno\u015bci i asercje i rozbi\u0107 je na mniejsze testy sprawdzaj\u0105ce ka\u017cd\u0105 funkcjonalno\u015b\u0107 z osobna. <\/p>\n\n\n\n
Implementacja test\u00f3w na r\u00f3\u017cnych poziomach <\/h3>\n\n\n\n
Testowanie bardziej z\u0142o\u017conych \u015bcie\u017cek, dajmy na to przypadk\u00f3w u\u017cycia, powinno zosta\u0107 zaimplementowane na przyk\u0142ad w testach akceptacyjnych. W ci\u0105g\u0142ym testowaniu mo\u017cna wykonywa\u0107 wszystkie rodzaje test\u00f3w, lecz im wy\u017cszy poziom test\u00f3w, tym liczba przypadk\u00f3w testowych powinna by\u0107 mniejsza (s\u0105 one mniej stabilne, czas ich wykonywania jest d\u0142u\u017cszy, wykrywaj\u0105 b\u0142\u0119dy w p\u00f3\u017aniejszych etapach, przez co wyd\u0142u\u017ca si\u0119 czas naprawy, a koszt ro\u015bnie). <\/p>\n\n\n\n
Dotyczy to zw\u0142aszcza test\u00f3w UI (User Interface), gdy testowana jest logika biznesowa i zachowanie interfejsu u\u017cytkownika. Mo\u017ce tu doj\u015b\u0107 do wielu wsp\u00f3\u0142zale\u017cnych awarii. Oddzielenie warstwy interfejsu od systemu bazowego, aby logika biznesowa mog\u0142a zosta\u0107 opatrzona za\u015blepkami (mock) jest istotn\u0105 zmian\u0105 zbli\u017caj\u0105c\u0105 nas do wi\u0119kszej stabilno\u015bci test\u00f3w. <\/p>\n\n\n\n
Jednym z podej\u015b\u0107 jest uruchamianie test\u00f3w jednostkowych w spos\u00f3b ci\u0105g\u0142y, a test\u00f3w wy\u017cszych poziom\u00f3w \u2013 na \u017c\u0105danie (nie musz\u0105 one by\u0107 uruchamiane automatycznie w trakcie budowy projektu w narz\u0119dziu ci\u0105g\u0142ej integracji \u2013 zamiast tego, istnieje mo\u017cliwo\u015b\u0107 uruchomienia ich w spos\u00f3b manualny, gdy potrzeba). <\/p>\n\n\n\n
Rola podej\u015bcia TDD <\/h3>\n\n\n\n
Praktykowanie podej\u015bcia TDD (Test-Driven Development) w wytwarzaniu oprogramowania u\u0142atwia zrozumienie i wdro\u017cenie ci\u0105g\u0142ego testowania. W TDD testy tworzone s\u0105 przed implementacj\u0105 funkcjonalno\u015bci. Najpierw tworzony jest ma\u0142y test, po kt\u00f3rym nast\u0119puje implementowanie powi\u0105zanego fragmentu ca\u0142ej funkcjonalno\u015bci. Nast\u0119pnie dokonuje si\u0119 refaktoryzacji w celu ulepszenia kodu i wyeliminowania ewentualnych powiele\u0144. Dzi\u0119ki ci\u0105g\u0142emu testowaniu otrzymujemy natychmiastow\u0105 informacj\u0119 zwrotn\u0105 na ka\u017cdym z tych krok\u00f3w. Nie tylko z tego jednego testu, kt\u00f3ry jest w danym momencie pisany, lecz ze wszystkich powi\u0105zanych test\u00f3w, bez dodatkowego wysi\u0142ku i zaanga\u017cowania ze strony programisty. Dzi\u0119ki temu mo\u017ce on skupi\u0107 si\u0119 w pe\u0142ni na projektowaniu i pisaniu kodu, zamiast rozprasza\u0107 si\u0119 konieczno\u015bci\u0105 uruchamiania test\u00f3w. <\/p>\n\n\n\n
Cel ci\u0105g\u0142ego testowania <\/h3>\n\n\n\n
Zar\u00f3wno w podej\u015bciu TDD, jak i w ci\u0105g\u0142ym testowaniu, celem jest jak najszybsze uzyskanie informacji zwrotnej. Pod wieloma wzgl\u0119dami naturalnym rezultatem skutecznego stosowania TDD jest dobrej jako\u015bci zestaw test\u00f3w. R\u00f3\u017cnica polega na tym, \u017ce stosuj\u0105c ci\u0105g\u0142e testowanie, zyskuje si\u0119 dodatkowe \u017ar\u00f3d\u0142a informacji zwrotnych. Stary aksjomat podej\u015bcia TDD m\u00f3wi, \u017ce testy sprawdzaj\u0105 poprawno\u015b\u0107 kodu, z kolei kod weryfikuje poprawno\u015b\u0107 test\u00f3w. Testy sprawdzaj\u0105 r\u00f3wnie\u017c projekt kodu \u2013 \u017ale zaprojektowany kod jest trudny do przetestowania.\u202f <\/p>\n\n\n\n
Jakie narz\u0119dzia wykorzystywane s\u0105 w procesie dostarczania oprogramowania z CI\/CD? <\/h2>\n\n\n\nJenkins <\/h3>\n\n\n\n
Jenkins to serwer ci\u0105g\u0142ej integracji (CI) typu open source. Kontroluje kilka etap\u00f3w procesu dostarczania oprogramowania, takie jak testowanie, kompilacja i wdra\u017canie. Popularno\u015b\u0107 tego narz\u0119dzia wynika mi\u0119dzy innymi z jego mo\u017cliwo\u015bci \u015bledzenia i monitorowania powtarzalnych dzia\u0142a\u0144 pojawiaj\u0105cych si\u0119 w trakcie prac nad projektem. Ka\u017cda zmiana w aplikacji jest kompilowana i testowana, a w razie wykrycia b\u0142\u0119du Jenkins ostrze\u017ce zesp\u00f3\u0142 o problemach. <\/p>\n\n\n\n
Wdro\u017cenie kodu na produkcj\u0119<\/strong> <\/p>\n\n\n\nJednym z podstawowych zastosowa\u0144 Jenkinsa jest mo\u017cliwo\u015b\u0107 wdra\u017cania kodu na produkcj\u0119. Je\u015bli wszystkie testy opracowane dla danej funkcji lub releasu zako\u0144cz\u0105 si\u0119 powodzeniem, Jenkins mo\u017ce automatycznie opublikowa\u0107 kod na \u015brodowisku staging lub produkcyjnym (jest to w\u0142a\u015bnie przyk\u0142ad Continuous Deployment opisanego w poprzednim artykule). <\/p>\n\n\n\n
A<\/strong>ut<\/strong>o<\/strong>matyzacja <\/strong>w<\/strong>orkflow<\/strong> i r\u00f3\u017cnych zada\u0144<\/strong><\/strong> <\/p>\n\n\n\nInnym przypadkiem, w kt\u00f3rym mo\u017cna u\u017cy\u0107 Jenkinsa, jest m.in. automatyzacja workflow. Na przyk\u0142ad, gdy programista pracuje na kilku \u015brodowiskach, w pewnym momencie zajdzie konieczno\u015b\u0107 instalacji lub aktualizacji pewnych komponent\u00f3w na ka\u017cdym z nich. Je\u015bli instalacja lub aktualizacja wymaga wykonania wielu krok\u00f3w, przeprowadzenie jej r\u0119cznie mo\u017ce skutkowa\u0107 pojawieniem si\u0119 b\u0142\u0119d\u00f3w, a dodatkowo b\u0119dzie czasoch\u0142onne. Zamiast tego wszystkie kroki potrzebne do finalizacji mo\u017cna odpowiednio skonfigurowa\u0107 w Jenkinsie. Dzi\u0119ki temu ca\u0142y proces b\u0119dzie stabilny i szybki, bo te\u017c zawsze b\u0119dzie wykonywany identycznie. <\/p>\n\n\n\n
Konfiguracja zada\u0144<\/strong> <\/p>\n\n\n\nJenkins umo\u017cliwia tworzenie zada\u0144 (Jenkins Jobs) na r\u00f3\u017cne sposoby. Konfiguracj\u0119 mo\u017cna stworzy\u0107 ca\u0142kowicie przez UI, przeklikuj\u0105c odpowiednie opcje, lecz lepszym wyborem jest utworzenie pliku konfiguracyjnego i zdefiniowanie w nim wszystkich niezb\u0119dnych krok\u00f3w. W Jenkinsie wykorzystuje si\u0119 w tym celu skrypty pisane w j\u0119zyku Groovy. Zalet\u0105 w stosowaniu tej opcji jest dodatkowo to, \u017ce plik konfiguracyjny mo\u017cna przechowywa\u0107 wraz z kodem dotycz\u0105cej go aplikacji. Dzi\u0119ki temu mamy zapewnione wersjonowanie zmian i powstaje kopia zapasowa, przydatna w przypadku wyst\u0105pienia awarii. <\/p>\n\n\n\n
Rozszerzalno\u015b\u0107 poprzez pluginy<\/strong> <\/p>\n\n\n\nMo\u017cliwo\u015bci Jenkinsa mo\u017cna rozszerza\u0107 dzi\u0119ki wielu pluginom dost\u0119pnym na stronie https:\/\/plugins.jenkins.io\/. Ich liczba pozwala na dowolne skonfigurowanie serwera pod konkretne potrzeby, pocz\u0105wszy od zmiany wygl\u0105du element\u00f3w interfejsu u\u017cytkownika po mo\u017cliwo\u015b\u0107 integracji z zewn\u0119trznymi serwisami lub aplikacjami czy modyfikuj\u0105ce kroki w tworzonych jobach.\u202f<\/strong> <\/p>\n\n\n\nGitLab <\/h3>\n\n\n\n
Innym narz\u0119dziem, o kt\u00f3rym warto wspomnie\u0107, jest GitLab. Serwis ten nie tylko pozwala na tworzenie i przechowywanie repozytori\u00f3w kodu, ale tak\u017ce udost\u0119pnia narz\u0119dzia do wersjonowania oprogramowania, zarz\u0105dzania zadaniami oraz procesami CI\/CD. Pozwala on wszystkim cz\u0142onkom zespo\u0142u wsp\u00f3\u0142pracowa\u0107 na wszystkich etapach projektu, upraszczaj\u0105c tworzenie oprogramowania. <\/p>\n\n\n\n
Funkcjonalno\u015bci GitLaba<\/strong> <\/p>\n\n\n\nGitLab to internetowe repozytorium Git, kt\u00f3re umo\u017cliwia zespo\u0142om programist\u00f3w planowanie, kodowanie, testowanie, wdra\u017canie i monitorowanie zmian tworzonego oprogramowania w jednym miejscu. Natomiast Git to dobrze wszystkim znany system kontroli wersji. <\/p>\n\n\n\n
Jedn\u0105 z istotnych mo\u017cliwo\u015bci jest \u015bledzenie b\u0142\u0119d\u00f3w: GitLab posiada wbudowany system umo\u017cliwiaj\u0105cy zespo\u0142om tworzenie, przypisywanie i \u015bledzenie b\u0142\u0119d\u00f3w. Zapewnia tak\u017ce tablic\u0119 zarz\u0105dzania projektami z konfigurowalnymi przep\u0142ywami pracy (workflow) w celu wizualizacji zada\u0144 i post\u0119p\u00f3w. <\/p>\n\n\n\n
Inn\u0105 kluczow\u0105 funkcjonalno\u015bci\u0105 GitLaba s\u0105 zintegrowane potoki CI\/CD (pipelines). Dzi\u0119ki temu mo\u017cna \u0142atwo zautomatyzowa\u0107 procesy testowania, budowania i wdra\u017cania, zapewniaj\u0105c dok\u0142adne testowanie zmian w kodzie przed po\u0142\u0105czeniem z g\u0142\u00f3wn\u0105 baz\u0105 kodu i wdro\u017ceniem w \u015brodowisku produkcyjnym. <\/p>\n\n\n\n
GitLab posiada tak\u017ce wewn\u0119trzny system wiki, umo\u017cliwiaj\u0105cy zespo\u0142om tworzenie i utrzymywanie dokumentacji projektowej. <\/p>\n\n\n\n
Podsumowanie <\/h2>\n\n\n\n
Podej\u015bcie Continuous Integration wraz z Continuous Development i Continuous Testing stanowi\u0105 komplementarne praktyki. Continuous Development umo\u017cliwia obserwowanie wdra\u017canych zmian w czasie rzeczywistym i jednocze\u015bnie eliminuje proces r\u0119cznego \u015bledzenia zmian. B\u0142\u0119dy znalezione na jak najwcze\u015bniejszym etapie s\u0105 najszybsze i najta\u0144sze w naprawie. <\/p>\n\n\n\n
Budowanie aplikacji wraz z przeprowadzeniem test\u00f3w na lokalnym \u015brodowisku mo\u017ce zaj\u0105\u0107 kilka minut, a ich przeprowadzenie daje pewno\u015b\u0107, \u017ce wprowadzone zmiany b\u0119d\u0105 przygotowane do integracji z g\u0142\u00f3wn\u0105 ga\u0142\u0119zi\u0105 repozytorium. Czasem zmiany mog\u0105 budzi\u0107 szczeg\u00f3lne w\u0105tpliwo\u015bci \u2013 na przyk\u0142ad, gdy modyfikacji wymagaj\u0105 pliki konfiguracyjne. W takim przypadku mo\u017cna wykona\u0107 pe\u0142n\u0105 kompilacj\u0119 i uruchomi\u0107 wszystkie testy, aby mie\u0107 pewno\u015b\u0107, \u017ce zmiana nie spowodowa\u0142a b\u0142\u0119d\u00f3w w innych obszarach aplikacji, a kod jest bezpieczny i mo\u017ce zosta\u0107 dodany do g\u0142\u00f3wnego repozytorium. <\/p>\n\n\n\n
Ci\u0105g\u0142a integracja ma na celu identyfikowanie problem\u00f3w, ale mo\u017ce r\u00f3wnie\u017c pos\u0142u\u017cy\u0107 jako narz\u0119dzie do zmniejszania koszt\u00f3w uruchamiania test\u00f3w wy\u017cszego poziomu \u2013 wykrycie b\u0142\u0119d\u00f3w na etapie test\u00f3w jednostkowych sprawi, \u017ce testy z pozosta\u0142ych poziom\u00f3w b\u0119d\u0105 bardziej stabilne, co daje dodatkow\u0105 pewno\u015b\u0107 co do jako\u015bci. at the capabilities are within the connectivity management framework. At Inetum, we are a partner of Cumulocity IoT, which has a network of partners providing platform-compatible devices with substantial connectivity capabilities.<\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
G\u0142\u00f3wna korzy\u015b\u0107 z\u00a0CI\u00a0to\u00a0wczesne wykrywanie b\u0142\u0119d\u00f3w, co\u00a0prowadzi do\u00a0szybszego wdra\u017cania nowych funkcji, wi\u0119kszej stabilno\u015bci oprogramowania i\u00a0lepszej wsp\u00f3\u0142pracy mi\u0119dzy programistami.<\/p>\n","protected":false},"author":143,"featured_media":28720,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"iawp_total_views":62,"footnotes":""},"categories":[1,402,582],"tags":[576,566],"offering":[513],"class_list":["post-28712","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-artykuly","category-articles","category-technologie","tag-cloud-engineering","tag-devops","offering-application-development"],"acf":[],"_links":{"self":[{"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/posts\/28712","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/users\/143"}],"replies":[{"embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/comments?post=28712"}],"version-history":[{"count":4,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/posts\/28712\/revisions"}],"predecessor-version":[{"id":32950,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/posts\/28712\/revisions\/32950"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/media\/28720"}],"wp:attachment":[{"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/media?parent=28712"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/categories?post=28712"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/tags?post=28712"},{"taxonomy":"offering","embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/offering?post=28712"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"chemat](\"https:\/\/nearshore-it.eu\/wp-content\/uploads\/2024\/08\/blog_2024.05.16_graphic_2.png\" "\\"\\"")
<\/figure>\n<\/div>\n\n\n![\"Poziomy](\"https:\/\/nearshore-it.eu\/wp-content\/uploads\/2024\/08\/blog_2024.05.16_graphic_3.png\" "\\"\\"")
<\/figure>\n<\/div>\n\n\n