{"id":30743,"date":"2024-05-24T07:28:58","date_gmt":"2024-05-24T05:28:58","guid":{"rendered":"https:\/\/nearshore-it.eu\/artykuly\/automatyzacja-ci-cd\/"},"modified":"2024-09-30T07:02:39","modified_gmt":"2024-09-30T05:02:39","slug":"automatyzacja-ci-cd","status":"publish","type":"post","link":"https:\/\/nearshore-it.eu\/pl\/artykuly\/automatyzacja-ci-cd\/","title":{"rendered":"Dostarczanie wydajnego oprogramowania: automatyzacja CI\/CD\u00a0"},"content":{"rendered":"\n
\n

Przejd\u017a do: <\/p>\n

    \n
  1. 1. Definicja Continuous Integration (CI) oraz Continuous Delivery (CD)<\/a><\/li>\n
  2. 2. Wyzwania CI\/ CD<\/a><\/li>\n
  3. 3. Czym jest ci\u0105g\u0142e dostarczanie i automatyzacja CI\/CD?<\/a><\/li>\n
  4. 4. Continuous Delivery (CD)\u00a0<\/a><\/li>\n
  5. 5. Korzy\u015bci ci\u0105g\u0142ego dostarczania (CD)<\/a><\/li>\n
  6. 6. Automatyzacja vs. manualne wdra\u017canie<\/a><\/li>\n
  7. 7. Podsumowanie<\/a><\/li>\n <\/ol>\n<\/div>\n\n\n

    Continuous Integration, Delivery and Deployment<\/em> to praktyki rozwoju oprogramowania, kt\u00f3re w ostatnich latach zdoby\u0142y du\u017c\u0105 popularno\u015b\u0107. Gdyby\u015bmy mieli je podsumowa\u0107 jednym s\u0142owem, brzmia\u0142oby to: automatyzacja. Wszystkie te trzy praktyki sprowadzaj\u0105 si\u0119 do automatyzacji procesu testowania i wdra\u017cania, minimalizacji (lub ca\u0142kowitego eliminowania) potrzeby ingerencji cz\u0142owieka, redukcji ryzyka wyst\u0105pienia b\u0142\u0119d\u00f3w oraz u\u0142atwienia tworzenia i wdra\u017cania oprogramowania do tego stopnia, \u017ce mo\u017ce to zrobi\u0107 ka\u017cdy programista w zespole. Poznaj kluczowe praktyki i korzy\u015bci w zakresie automatyzacji CI\/CD. \u00a0<\/p>\n\n\n\n

    Definicja Continuous Integration (CI) oraz Continuous Delivery (CD)<\/h2>\n\n\n\n

    Ci\u0105g\u0142a integracja<\/h3>\n\n\n\n

    Continuous Integration, CI jest praktyk\u0105 stosowan\u0105 w procesie wytwarzania oprogramowania polegaj\u0105c\u0105 na cz\u0119stym, regularnym integrowaniu bie\u017c\u0105cych zmian w kodzie do g\u0142\u00f3wnego repozytorium aplikacji. Zwykle programi\u015bci w\u0142\u0105czaj\u0105 swoje zmiany co najmniej raz dziennie, co przy zespole sk\u0142adaj\u0105cym si\u0119 z kilku lub kilkunastu os\u00f3b skutkuje wieloma integracjami wykonywanymi ka\u017cdego dnia. Ka\u017cda integracja jest weryfikowana przez zastosowanie automatyzacji w projekcie (w\u0142\u0105czaj\u0105c r\u00f3wnie\u017c testy automatyczne) w celu jak najszybszego wykrycia ewentualnych b\u0142\u0119d\u00f3w integrowanego kodu. Stosowanie tego podej\u015bcia prowadzi do znacznego zmniejszenia liczby problem\u00f3w zwi\u0105zanych z integracj\u0105 i umo\u017cliwia szybsze tworzenie sp\u00f3jnego oprogramowania.<\/p>\n\n\n\n

    Ci\u0105g\u0142e dostarczanie<\/h3>\n\n\n\n

    Continuous Delivery, CD \u2013 jest praktyk\u0105 in\u017cynierii oprogramowania polegaj\u0105c\u0105 na regularnym wydawaniu kolejnych wersji oprogramowania w kr\u00f3tkich cyklach. Oznacza to, \u017ce z ka\u017cd\u0105 kompilacj\u0105 budowana jest nowa wersja ca\u0142ego tworzonego oprogramowania. Nie znaczy to jednak, \u017ce oprogramowanie jest od razu wypuszczane na \u015brodowisko produkcyjne. Nic jednak nie stoi na przeszkodzie, aby to zrobi\u0107, gdyby zasz\u0142a taka potrzeba. Ta nieznaczna r\u00f3\u017cnica dotycz\u0105ca automatycznego wdra\u017cania zmian bezpo\u015brednio na \u015brodowisku produkcyjnym odr\u00f3\u017cnia ci\u0105g\u0142e dostarczanie od ci\u0105g\u0142ego wdra\u017cania (Continuous Deployment) \u2013 w kt\u00f3rym to ka\u017cda kompilacja ca\u0142ego oprogramowania ko\u0144czy si\u0119 wydaniem kolejnej wersji na \u015brodowisku produkcyjnym. Zespo\u0142y developerskie dbaj\u0105 o to, aby nowe funkcje by\u0142y dodawane w ma\u0142ych pakietach, dzi\u0119ki czemu ewentualne wydanie nowej wersji oprogramowania mo\u017ce nast\u0105pi\u0107 szybko i w dowolnym momencie. W praktyce maksymalizuje to mo\u017cliwo\u015b\u0107 uzyskania szybkiej informacji zwrotnej na temat oprogramowania zar\u00f3wno z perspektywy biznesu, jak i technicznej.<\/p>\n\n\n\n

    Wyzwania CI\/CD<\/h2>\n\n\n\n

    O ci\u0105g\u0142ej integracji po raz pierwszy napisa\u0142 Kent Beck w swojej ksi\u0105\u017cce pod tytu\u0142em \u201eExtreme Programming Explained”, wydanej po raz pierwszy w 1999 roku. Ide\u0105 CI by\u0142o: je\u017celi regularna integracja kodu jest dobra \u2013 dlaczego nie wykonywa\u0107 jej przez ca\u0142y czas? \u201eCa\u0142y czas” oznacza: za ka\u017cdym razem, gdy kto\u015b wprowadza zmian\u0119 w systemie kontroli wersji.<\/p>\n\n\n\n

    Problem z ci\u0105g\u0142\u0105 integracj\u0105, dostarczaniem i wdra\u017caniem polega jednak na tym, \u017ce konfiguracja nie nale\u017cy do najprostszych czynno\u015bci i zajmuje du\u017co czasu, zw\u0142aszcza je\u015bli zesp\u00f3\u0142 ma z ni\u0105 do czynienia po raz pierwszy lub postanowiono wdro\u017cy\u0107 proces do istniej\u0105cego ju\u017c projektu.<\/p>\n\n\n\n

    Jednak korzy\u015bci p\u0142yn\u0105ce z wprowadzenia tych praktyk s\u0105 warte po\u015bwi\u0119conego czasu. Przejawi si\u0119 to w mniejszej liczbie b\u0142\u0119d\u00f3w, u\u0142atwieniu ich identyfikacji i naprawy, a ostatecznie w stworzeniu oprogramowania lepszej jako\u015bci.<\/p>\n\n\n\n

    Czym jest ci\u0105g\u0142e dostarczanie i automatyzacja CI\/CD?<\/h2>\n\n\n\n

    Ci\u0105g\u0142a integracja (CI).<\/h3>\n\n\n\n

    Kluczowe aspekty skutecznej ci\u0105g\u0142ej integracji<\/h3>\n\n\n\n

    Przyjrzyjmy si\u0119 CI jeszcze bli\u017cej. Ci\u0105g\u0142a integracja na przestrzeni ostatnich kilku lat sta\u0142a si\u0119 w zasadzie standardem w zwinnych metodykach wytwarzania oprogramowania. Pocz\u0105tkowo, w po\u0142\u0105czeniu z uruchamianiem automatycznych test\u00f3w jednostkowych na lokalnym \u015brodowisku programisty, mia\u0142a na celu zapewnienie, \u017ce programista nie w\u0142\u0105czy kodu, kt\u00f3ry m\u00f3g\u0142by powodowa\u0107 b\u0142\u0119dy w aplikacji. Z biegiem czasu metoda ta ewoluowa\u0142a.<\/p>\n\n\n\n

    Obecnie kompilacje uruchamiane s\u0105 na serwerach ci\u0105g\u0142ej integracji, kt\u00f3re buduj\u0105 projekt oraz uruchamiaj\u0105 zautomatyzowane testy \u2013 automatycznie, przy ka\u017cdej zmianie dodanej przez programist\u00f3w, lub okresowo. Wynik (w postaci raport\u00f3w, log\u00f3w) generowany jest po zako\u0144czeniu procesu budowania. Obecnie podej\u015bcie ci\u0105g\u0142ej integracji jest wykorzystywane nie tylko w metodykach zwinnych, ale r\u00f3wnie\u017c w innych metodykach wytwarzania oprogramowania.<\/p>\n\n\n\n

    Opr\u00f3cz przeprowadzania test\u00f3w jednostkowych i integracyjnych mo\u017cna te\u017c uruchamia\u0107 testy statyczne i dynamiczne, mierzy\u0107 i profilowa\u0107 wydajno\u015b\u0107, tworzy\u0107 dokumentacj\u0119 bazuj\u0105c\u0105 na kodzie \u017ar\u00f3d\u0142owym oraz upraszcza\u0107 manualne procesy zapewnienia jako\u015bci. W ten spos\u00f3b ci\u0105g\u0142a integracja zapewnia r\u00f3wnie\u017c ci\u0105g\u0142\u0105 kontrol\u0119 jako\u015bci oprogramowania.<\/p>\n\n\n\n

    Dobrze funkcjonuj\u0105ca ci\u0105g\u0142a integracja opiera si\u0119 na spe\u0142nieniu pewnych warunk\u00f3w wst\u0119pnych, a tak\u017ce przestrzeganiu kilku podstawowych praktyk. Przy jej wdra\u017caniu nale\u017cy zadba\u0107 przede wszystkim o trzy rzeczy:<\/p>\n\n\n\n\n\n

      \n
    1. Narz\u0119dzie kontroli wersji<\/strong>
      Wszystko w projekcie musi by\u0107 ewidencjonowane w jednym narz\u0119dziu kontroli wersji: kod, skrypty, bazy danych, skrypty kompilacji i wdra\u017cania oraz wszystko inne, co jest niezb\u0119dne do tworzenia, instalowania, uruchamiania i testowania aplikacji.<\/li>\n\n\n\n
    2. Narz\u0119dzie do zautomatyzowanej kompilacji<\/strong>
      Nale\u017cy mie\u0107 mo\u017cliwo\u015b\u0107 uruchomienia kompilacji za pomoc\u0105 wiersza polece\u0144. Podstawowym narz\u0119dziem mo\u017ce by\u0107 prosty program wiersza polece\u0144, kt\u00f3ry skompiluje tworzony program, a nast\u0119pnie uruchomi testy. Mo\u017ce to by\u0107 te\u017c z\u0142o\u017cona kolekcja skrypt\u00f3w kompilacji, kt\u00f3re wywo\u0142uj\u0105 si\u0119 nawzajem w odpowiedniej kolejno\u015bci. Niezale\u017cnie od mechanizmu, osoba lub komputer musi mie\u0107 mo\u017cliwo\u015b\u0107 uruchomienia kompilacji, budowania, uruchamiania test\u00f3w i wdra\u017cania w spos\u00f3b zautomatyzowany za pomoc\u0105 wiersza polece\u0144. Skrypty powinny by\u0107 traktowane jak kod \u2013 musz\u0105 by\u0107 testowane i stale refaktoryzowane, aby by\u0142y stabilne, uporz\u0105dkowane i \u0142atwe do zrozumienia.<\/li>\n\n\n\n
    3. Zgoda ca\u0142ego zespo\u0142u<\/strong>
      Ci\u0105g\u0142a integracja jest praktyk\u0105, a nie narz\u0119dziem. Wymaga od zespo\u0142u programistycznego dyscypliny i zaanga\u017cowania. Ka\u017cdy w zespole musi cz\u0119sto wprowadza\u0107 swoje zmiany do repozytorium i przyj\u0105\u0107 za\u0142o\u017cenie, \u017ce najwa\u017cniejszym zadaniem w trakcie pracy nad projektem jest naprawa wszelkich zmian, kt\u00f3re psuj\u0105 aplikacj\u0119. Je\u015bli zesp\u00f3\u0142 nie b\u0119dzie przestrzega\u0142 tych zasad, poprawne wdro\u017cenie ci\u0105g\u0142ej integracji mo\u017ce nie by\u0107 efektywne i nie doprowadzi do satysfakcjonuj\u0105cej poprawy jako\u015bci wytwarzania oprogramowania.<\/li>\n<\/ol>\n\n\n\n

      Zalety ci\u0105g\u0142ej integracji w por\u00f3wnaniu z podej\u015bciem tradycyjnym<\/h3>\n\n\n\n

      W por\u00f3wnaniu do tradycyjnego podej\u015bcia, gdzie zmiany wprowadzane w kodzie \u017ar\u00f3d\u0142owym s\u0105 kompilowane, testowane i integrowane raz na jaki\u015b czas (raz w tygodniu lub rzadziej), wykorzystanie podej\u015bcia ci\u0105g\u0142ej integracji zapewnia wiele korzy\u015bci:<\/p>\n\n\n\n

        \n
      • wcze\u015bniejsze wykrywanie problem\u00f3w kompilacji\/integracji, dzi\u0119ki czemu s\u0105 naprawiane w spos\u00f3b ci\u0105g\u0142y, a nie w ostatniej chwili, tu\u017c zanim g\u0142\u00f3wna wersja oprogramowania zostanie przygotowana do wydania,\u00a0<\/li>\n\n\n\n
      • zesp\u00f3\u0142 otrzymuje natychmiastow\u0105 informacj\u0119 zwrotn\u0105 na temat jako\u015bci, funkcjonalno\u015bci oraz wp\u0142ywu pisanego kodu na ca\u0142y system,\u00a0<\/li>\n\n\n\n
      • w ramach tego procesu wykonywane s\u0105 zautomatyzowane testy. Dzi\u0119ki nim mo\u017cliwa jest natychmiastowa kontrola poprawno\u015bci architektury projektu i jako\u015bci kodu \u2013 s\u0105 one wykonywane w ramach proces\u00f3w kompilacji, budowania i wdra\u017cania zmian (deployment) na r\u00f3\u017cne \u015brodowiska,\u00a0<\/li>\n\n\n\n
      • wczesny dost\u0119p do aktualnej wersji oprogramowania (przed oficjalnym wydaniem) do cel\u00f3w testowych lub demonstracyjnych.\u00a0<\/li>\n<\/ul>\n\n\n\n

        Kluczowe praktyki w procesie ci\u0105g\u0142ej integracji<\/h3>\n\n\n\n

        Optymalne korzy\u015bci z procesu ci\u0105g\u0142ej integracji mo\u017cna uzyska\u0107, gdy przestrzega si\u0119 ustalonych w zespole procedur, co wymaga dyscypliny, jak wspomnia\u0142em wcze\u015bniej. Istniej\u0105 te\u017c sprawdzone, dobre praktyki, kt\u00f3rych przestrzeganie znacz\u0105co zwi\u0119kszy sukces we wdro\u017ceniu tego procesu. Sk\u0142adaj\u0105 si\u0119 na nie poni\u017csze aspekty:\u00a0<\/p>\n\n\n\n\n\n

          \n
        1. Cz\u0119sta integracja kodu<\/strong> \u2013 najwa\u017cniejsza praktyka w ci\u0105g\u0142ej integracji. Kod powinno si\u0119 integrowa\u0107 przynajmniej kilka razy dziennie. Regularne wysy\u0142anie zmian niesie ze sob\u0105 inne korzy\u015bci \u2013 zmiany s\u0105 przesy\u0142ane w mniejszych pakietach, co zmniejsza prawdopodobie\u0144stwo b\u0142\u0119du w kompilacji, a tak\u017ce u\u0142atwia poszukiwanie ewentualnych zmian (mniejsza liczba plik\u00f3w do przeszukiwania). To minimalizuje te\u017c prawdopodobie\u0144stwo wyst\u0105pienia konflikt\u00f3w z kodem innych programist\u00f3w w przypadku pracy wymagaj\u0105cej zmiany w wielu plikach. W przypadku awarii lokalnej stacji roboczej, kt\u00f3ra spowodowa\u0142yby utrat\u0119 lokalnych zmian w kodzie \u2013 programista nie musi pisa\u0107 wszystkiego od pocz\u0105tku, lecz mo\u017ce zacz\u0105\u0107 od etapu zmian wprowadzonych w ostatniej integracji.<\/li>\n\n\n\n
        2. Zarz\u0105dzanie obszarem roboczym<\/strong> \u2013 wa\u017cne jest, aby \u015brodowisko programistyczne by\u0142o starannie zarz\u0105dzane \u2013 przede wszystkim zwi\u0119ksza to produktywno\u015b\u0107. Deweloperzy powinni zawsze rozpoczyna\u0107 now\u0105 prac\u0119 od aktualnej, dzia\u0142aj\u0105cej wersji kodu z g\u0142\u00f3wnej ga\u0142\u0119zi repozytorium. Powinni m\u00f3c uruchomi\u0107 kompilacj\u0119, testy i by\u0107 w stanie wdro\u017cy\u0107 aplikacj\u0119 w swoim lokalnym \u015brodowisku. Uruchamianie aplikacji w \u015brodowisku lokalnym powinno wykorzystywa\u0107 te same zautomatyzowane procesy, co w serwerach ci\u0105g\u0142ej integracji.<\/li>\n\n\n\n
        3. Kompleksowy zestaw test\u00f3w automatycznych<\/strong> \u2013 konieczne jest posiadanie zestawu test\u00f3w automatycznych, aby mie\u0107 pewno\u015b\u0107, \u017ce aplikacja dzia\u0142a poprawnie. Najwa\u017cniejsze z punktu widzenia ci\u0105g\u0142ej integracji s\u0105 testy: jednostkowe, integracyjne oraz akceptacyjne. Ich kombinacja powinna zapewni\u0107 bardzo wysoki poziom pewno\u015bci co do tego, \u017ce \u017cadna z wprowadzonych zmian nie naruszy\u0142a stabilno\u015bci aplikacji.\u00a0\u00a0\u00a0<\/li>\n\n\n\n
        4. Kr\u00f3tki proces budowania i testowania projektu <\/strong>\u2013 kompilacja, budowanie i wykonanie test\u00f3w nie powinny trwa\u0107 d\u0142u\u017cej ni\u017c 5-10 minut. Je\u015bli z jakiego\u015b powodu proces ten zajmuje zbyt du\u017co czasu, mog\u0105 wyst\u0105pi\u0107 problemy takie jak:\u00a0\n
            \n
          • niecierpliwo\u015b\u0107 programist\u00f3w \u2013 mog\u0105 oni przesta\u0107 wykonywa\u0107 pe\u0142n\u0105 procedur\u0119 (na przyk\u0142ad pomija\u0107 etap test\u00f3w), co b\u0119dzie powodowa\u0107 wi\u0119cej b\u0142\u0119d\u00f3w kompilacji na serwerze ci\u0105g\u0142ej integracji.\u00a0<\/li>\n\n\n\n
          • proces ci\u0105g\u0142ej integracji mo\u017ce trwa\u0107 tak d\u0142ugo, \u017ce do czasu ponownego uruchomienia kompilacji mo\u017ce zosta\u0107 zintegrowanych wiele zmian \u2013 znalezienie tej, kt\u00f3ra powoduje b\u0142\u0119dy, mo\u017ce by\u0107 bardzo czasoch\u0142onne.\u00a0<\/li>\n\n\n\n
          • rzadsza integracja zmian przez programist\u00f3w z powodu czasoch\u0142onno\u015bci procesu \u2013 czekanie kilku godzin na zako\u0144czenie kompilacji i test\u00f3w jest strat\u0105 czasu i zasob\u00f3w.\u00a0<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n

            Continuous Delivery (CD)\u00a0<\/h2>\n\n\n\n

            Ci\u0105g\u0142a integracja stanowi podstaw\u0119 solidnego, nowoczesnego wytwarzania oprogramowania. Jest to czynnik umo\u017cliwiaj\u0105cy wdro\u017cenie jeszcze bardziej zaawansowanych technik. W ci\u0105g\u0142ej integracji, gdy wszystkie testy zako\u0144cz\u0105 si\u0119 pomy\u015blnie, zyskujemy pewno\u015b\u0107, \u017ce oprogramowanie dzia\u0142a. Jednak\u017ce \u2013 w jaki spos\u00f3b upewni\u0107 si\u0119, \u017ce oprogramowanie b\u0119dzie dzia\u0142a\u0142o w \u015brodowisku docelowym? Czy b\u0119dzie wsp\u00f3\u0142pracowa\u0142o z innymi aplikacjami? Wreszcie \u2013 jak dostarczy\u0107 je do u\u017cytkownik\u00f3w ko\u0144cowych? Z pomoc\u0105 przychodzi podej\u015bcie ci\u0105g\u0142ego dostarczania (Continuous Delivery, CD). <\/p>\n\n\n\n

            W swej istocie ci\u0105g\u0142e dostarczanie polega na minimalizowaniu czasu potrzebnego do wprowadzenia zmian w aplikacji oraz minimalizowaniu ryzyka wyst\u0105pienia problem\u00f3w, kt\u00f3re tak\u017ce mog\u0105 pojawi\u0107 si\u0119 w trakcie tego procesu. Mo\u017ce sk\u0142ada\u0107 si\u0119 z kilku faz, takich jak:\u00a0<\/p>\n\n\n\n

              \n
            • Odkrywanie<\/strong> \u2013 w kt\u00f3rej analizuje si\u0119 pomys\u0142y, og\u00f3lne dzia\u0142anie, funkcjonalno\u015bci \u2013 aby uzyska\u0107 szersze zrozumienie przestrzeni problemu i zastanowi\u0107 si\u0119 nad potencjalnymi rozwi\u0105zaniami.\u00a0<\/li>\n\n\n\n
            • Definiowanie<\/strong> \u2013 gdzie formalne kryteria akceptacji i prace projektowe stanowi\u0105 baz\u0119 do dalszych prac rozwojowych.\u00a0<\/li>\n\n\n\n
            • Rozw\u00f3j<\/strong> \u2013 w kt\u00f3rej produkt jest budowany i testowany funkcjonalnie.\u00a0<\/li>\n\n\n\n
            • Akceptacja<\/strong> \u2013 w tej fazie przeprowadzane s\u0105 testy akceptacyjne wysokiego poziomu i uzyskuje si\u0119 potwierdzenia od akcjonariuszy.\u00a0<\/li>\n\n\n\n
            • Wdro\u017cenie<\/strong> \u2013 zmiana jest wprowadzana na produkcj\u0119.\u00a0<\/li>\n\n\n\n
            • Weryfikacja<\/strong> \u2013 w ramach kt\u00f3rej, na podstawie wszelkich danych, analizuje si\u0119 zmiany, aby upewni\u0107 si\u0119, \u017ce osi\u0105gn\u0119\u0142y one zamierzony wp\u0142yw.\u00a0<\/li>\n<\/ul>\n\n\n\n

              Ka\u017cda faza stanowi swego rodzaju list\u0119 kontroln\u0105 okre\u015blaj\u0105c\u0105, co jest potrzebne, aby zmiany sz\u0142y naprz\u00f3d. Czasem przywo\u0142ane fazy wysokiego poziomu s\u0105 podzielone na bardziej szczeg\u00f3\u0142owe. Na przyk\u0142ad, faza rozwoju mo\u017ce mie\u0107 wyszczeg\u00f3lnione podfazy:\u00a0\u00a0<\/p>\n\n\n\n

                \n
              • architektury technicznej,\u00a0\u00a0<\/li>\n\n\n\n
              • budowania lub kompilacji,\u00a0\u00a0<\/li>\n\n\n\n
              • i przegl\u0105du kodu.\u00a0\u00a0<\/li>\n<\/ul>\n\n\n\n

                Niezale\u017cnie od z\u0142o\u017cono\u015bci poszczeg\u00f3lnych faz, zadania zwi\u0105zane z prac\u0105 nad nimi mog\u0105 by\u0107 podejmowane przez wiele os\u00f3b o r\u00f3\u017cnych umiej\u0119tno\u015bciach. Zadania mog\u0105 by\u0107 wi\u0119c wykonywane r\u00f3wnolegle, lecz powinny zachowa\u0107 niezale\u017cno\u015b\u0107. <\/p>\n\n\n\n

                Continuous Delivery automatyzuje proces wdra\u017cania oprogramowania na r\u00f3\u017cne \u015brodowiska w projekcie. Niekt\u00f3re z nich mo\u017cna wykorzysta\u0107 do przeprowadzania r\u00f3\u017cnych test\u00f3w automatycznych, takich jak:\u00a0\u00a0<\/p>\n\n\n\n

                  \n
                • testy integracyjne,\u00a0\u00a0<\/li>\n\n\n\n
                • testy akceptacyjne,\u00a0\u00a0<\/li>\n\n\n\n
                • czy te\u017c testy niefunkcjonalne, jak na przyk\u0142ad testy wydajno\u015bciowe lub penetracyjne.\u00a0\u00a0<\/li>\n<\/ul>\n\n\n\n

                  Nie nale\u017cy r\u00f3wnie\u017c zapomina\u0107 o przeprowadzeniu test\u00f3w manualnych, kt\u00f3re mog\u0105 wykry\u0107 nowe klasy defekt\u00f3w, kt\u00f3rych automatyczne testy zwykle nie s\u0105 w stanie wychwyci\u0107.\u00a0<\/p>\n\n\n\n

                  Korzy\u015bci ci\u0105g\u0142ego dostarczania (CD)\u00a0<\/h2>\n\n\n\n

                  Wdro\u017cenie podej\u015bcia ci\u0105g\u0142ego dostarczania niesie wiele korzy\u015bci, do kt\u00f3rych nale\u017c\u0105:<\/p>\n\n\n\n

                  #1. Oszcz\u0119dno\u015b\u0107 czasu<\/h3>\n\n\n\n

                  W \u015brednich i du\u017cych firmach programy oraz ich infrastruktura s\u0105 zwykle tworzone i obs\u0142ugiwane przez wiele oddzielnych zespo\u0142\u00f3w. Ka\u017cde wdro\u017cenie nowej wersji aplikacji musi by\u0107 skoordynowane mi\u0119dzy nimi. Nale\u017cy ustali\u0107 mi\u0119dzy zespo\u0142ami dat\u0119 wprowadzenia nowej zmiany, takiej, kt\u00f3ra obu zespo\u0142om b\u0119dzie odpowiada\u0142a.<\/p>\n\n\n\n

                  Ponadto nale\u017cy rozpowszechni\u0107 informacj\u0119 na temat nowej wersji (na przyk\u0142ad: jakie obszary aplikacji zostan\u0105 poddane zmianom, czy jest wymagana nowa konfiguracja, zmiany w integracji itp.). Dodatkowo zespo\u0142y musz\u0105 udost\u0119pni\u0107 niezb\u0119dne pliki, i tak dalej \u2013 procedury mog\u0105 si\u0119 r\u00f3\u017cni\u0107 w zale\u017cno\u015bci od stopnia formalno\u015bci i dojrza\u0142o\u015bci proces\u00f3w w organizacji.<\/p>\n\n\n\n

                  Generalnie wszystkie niezb\u0119dne dzia\u0142ania z pewno\u015bci\u0105 b\u0119d\u0105 trwa\u0142y kilka godzin, czasem nawet kilka dni. Cz\u0119sto procesowi temu towarzysz\u0105 r\u00f3wnie\u017c przestoje spowodowane r\u00f3\u017cnymi czynnikami. A poniewa\u017c przestoj\u00f3w nale\u017cy unika\u0107 w godzinach pracy, zdarza si\u0119, \u017ce wdro\u017cenia odbywaj\u0105 si\u0119 w nocy lub w weekend. Mo\u017ce to dzia\u0142a\u0107 demotywuj\u0105co na zespo\u0142y operacyjne odpowiedzialne za wdro\u017cenie, a st\u0105d ju\u017c tylko krok do pope\u0142niania b\u0142\u0119d\u00f3w. Wprowadzenie ci\u0105g\u0142ego wdra\u017cania poprzez automatyzacj\u0119 zada\u0144 mo\u017ce zaoszcz\u0119dzi\u0107 wiele czasu i skr\u00f3ci\u0107 proces z kilku dni do nawet kilku minut oraz oszcz\u0119dzi\u0107 nerw\u00f3w ludziom z zespo\u0142\u00f3w operacyjnych. Dobrze skonfigurowane narz\u0119dzie pozwoli na praktycznie bezobs\u0142ugowe wdro\u017cenie, koordynowane przez jedn\u0105 lub kilka os\u00f3b bez potrzeby anga\u017cowania ca\u0142ych zespo\u0142\u00f3w.<\/p>\n\n\n\n

                  #2. Kr\u00f3tsze cykle wdro\u017ce\u0144<\/h3>\n\n\n\n

                  Firmy wykonuj\u0105ce wydania i wdro\u017cenia manualnie robi\u0105 to zwykle raz w tygodniu lub nawet rzadziej. Rzadkie wydania doprowadzaj\u0105 do przed\u0142u\u017caj\u0105cych si\u0119 proces\u00f3w rozwoju, a w ostateczno\u015bci spowolnienia czasu wprowadzenia produktu na rynek. Je\u017celi na przyk\u0142ad oprogramowanie jest aktualizowane raz na kwarta\u0142, wprowadzenie nowej, ma\u0142ej funkcji lub istotnej poprawki mo\u017ce niepotrzebnie rozci\u0105gn\u0105\u0107 si\u0119 w czasie i spowodowa\u0107 odp\u0142yw klient\u00f3w. Na przyk\u0142ad w\u0142a\u015bciciel sklepu internetowego, w kt\u00f3rym pewien etap procesu zakupowego zosta\u0142 \u017ale zaprojektowany (co powoduje trudno\u015bci w zakupach) b\u0119dzie musia\u0142 czeka\u0107 3 miesi\u0105ce, zanim poprawka zostanie wdro\u017cona. W tym czasie sklep mo\u017ce straci\u0107 ogromn\u0105 liczb\u0119 klient\u00f3w, a co za tym idzie \u2013 realne pieni\u0105dze. Automatyczne wdra\u017canie mo\u017ce ca\u0142kowicie wyeliminowa\u0107 ten rodzaj problem\u00f3w.<\/p>\n\n\n\n

                  #3. Kr\u00f3tszy czas otrzymania informacji zwrotnej (feedback)<\/h3>\n\n\n\n

                  Najlepszym sposobem na uzyskanie warto\u015bciowych opinii na temat produktu jest wdro\u017cenie go na \u015brodowisko produkcyjne, gdzie b\u0119dzie ono u\u017cywane przez prawdziwych u\u017cytkownik\u00f3w. Dzi\u0119ki temu mo\u017cna mierzy\u0107 ich zaanga\u017cowanie w r\u00f3\u017cnych cz\u0119\u015bciach systemu. U\u017cytkownicy cz\u0119sto wyra\u017caj\u0105 r\u00f3wnie\u017c opinie na temat aplikacji i sugeruj\u0105 zmiany.<\/p>\n\n\n\n

                  Niestety, zadanie to nie jest takie proste, gdy tworzy si\u0119 na przyk\u0142ad narz\u0119dzia do u\u017cytku wewn\u0119trznego w firmie. Mo\u017cna wtedy poprosi\u0107 kilka os\u00f3b, aby przetestowa\u0142y je na jednym ze \u015brodowisk testowych, lecz to rodzi wyzwania. Potrzeba na to wykorzystania ich roboczogodzin, \u015brodowisko testowe musi by\u0107 w pe\u0142ni przygotowane i skonfigurowane z wszystkimi niezb\u0119dnymi danymi, kt\u00f3re na ko\u0144cu i tak zostan\u0105 usuni\u0119te. Jest to proces czasoch\u0142onny i skomplikowany.<\/p>\n\n\n\n

                  Przy r\u0119cznych wydaniach, co cz\u0119sto idzie w parze z niecz\u0119stym okresem wdra\u017cania, cykl otrzymania feedbacku jest bardzo powolny, co jest sprzeczne z ca\u0142\u0105 ide\u0105 zwinnego procesu wytwarzania oprogramowania. Komunikacja mi\u0119dzy lud\u017ami r\u00f3wnie\u017c nie zawsze jest idealna \u2013 praca w grupie to zawsze ryzyko nieporozumie\u0144. Zdarza si\u0119, \u017ce pierwsza implementacja funkcjonalno\u015bci nie spe\u0142nia pierwotnych oczekiwa\u0144. W takiej sytuacji dyskusje (a wi\u0119c informacja zwrotna) s\u0105 nieuniknione. Powolne cykle wdro\u017ceniowe prowadz\u0105 zatem do spowolnienia rozwoju aplikacji, frustruj\u0105c nie tylko zesp\u00f3\u0142, ale tak\u017ce interesariuszy. U\u017cytkownicy docelowi, zdaj\u0105c sobie spraw\u0119 z czasu trwania wdra\u017cania kolejnych aktualizacji, mog\u0105 nawet nie prosi\u0107 o poprawki lub nie sugerowa\u0107 r\u00f3\u017cnych udogodnie\u0144 \u2013 pr\u0119dzej przenios\u0105 si\u0119 do aplikacji konkurencyjnej, kt\u00f3rej autorzy lepiej dbaj\u0105 o ten aspekt. Na d\u0142u\u017csz\u0105 met\u0119 powolne cykle wdro\u017ceniowe przek\u0142adaj\u0105 si\u0119 na utrat\u0119 jako\u015bci aplikacji i odp\u0142yw u\u017cytkownik\u00f3w.<\/p>\n\n\n\n

                  #4. Niezawodno\u015b\u0107 wyda\u0144<\/h3>\n\n\n\n

                  Manualne wdra\u017canie zazwyczaj nie odbywa si\u0119 cz\u0119sto. To oznacza, \u017ce ka\u017cde wydanie zawiera du\u017co zmian, co z kolei zwi\u0119ksza ryzyko niepowodzenia. Gdy du\u017ce aktualizacje s\u0105 \u017ar\u00f3d\u0142em zbyt wielu problem\u00f3w, in\u017cynierowie i managerowie szukaj\u0105 sposob\u00f3w na popraw\u0119 stabilno\u015bci kolejnego wydania, niejednokrotnie poprzez tworzenie kolejnych procedur i list kontrolnych.<\/p>\n\n\n\n

                  Tworzy to b\u0142\u0119dne ko\u0142o, poniewa\u017c wi\u0119cej proces\u00f3w wymaga w\u0142o\u017cenia jeszcze wi\u0119kszego wysi\u0142ku w kolejne wydania, a co za tym idzie \u2013 wi\u0119cej czasu. Sprawia to, \u017ce cykle wydawania oprogramowania s\u0105 jeszcze d\u0142u\u017csze, co z kolei rodzi potrzeb\u0119 zmiany procedur, aby\u2026 ten czas skr\u00f3ci\u0107. Sposobem na wyj\u015bcie z tego b\u0142\u0119dnego ko\u0142a jest automatyzacja etap\u00f3w lub nawet ca\u0142ego procesu wydawania. Gdy wi\u0119c proces ten stanie si\u0119 niezawodny i szybszy, nic nie b\u0119dzie sta\u0142o na przeszkodzie, aby zwi\u0119kszy\u0107 liczb\u0119 wyda\u0144, kt\u00f3re jednorazowo b\u0119d\u0105 zawiera\u0142y mniejsze zmiany. Czas zaoszcz\u0119dzony dzi\u0119ki automatyzacji uwalnia zasoby, kt\u00f3re mo\u017cna wykorzysta\u0107, aby jeszcze bardziej usprawni\u0107 zautomatyzowany proces wydawania.<\/p>\n\n\n\n

                  #5. Mniejsze pakiety u\u0142atwiaj\u0105 znalezienie \u017ar\u00f3d\u0142a problemu<\/h3>\n\n\n\n

                  Kiedy wdro\u017cenie spowoduje b\u0142\u0105d w oprogramowaniu (a zawiera\u0142o ono tylko jedn\u0105 lub dwie nowe funkcje lub same poprawki b\u0142\u0119d\u00f3w), do\u015b\u0107 \u0142atwo mo\u017cna ustali\u0107, kt\u00f3ra ze zmian stanowi \u017ar\u00f3d\u0142o b\u0142\u0119du. Du\u017ce pakiety, gdzie na jedno wydanie przypada wiele zmian w r\u00f3\u017cnych cz\u0119\u015bciach aplikacji, utrudniaj\u0105 znalezienie \u017ar\u00f3d\u0142a problem\u00f3w i wyd\u0142u\u017caj\u0105 czas poszukiwa\u0144 oraz naprawy. Ta, ze wzgl\u0119du na wiele zmian zawartych w wydaniu (poziom skomplikowania pakietu przez r\u00f3\u017cne zale\u017cno\u015bci) trwa d\u0142u\u017cej.<\/p>\n\n\n\n

                  #6. Swoboda architektoniczna<\/h3>\n\n\n\n

                  Obecne trendy w in\u017cynierii oprogramowania odchodz\u0105 od monolitycznych aplikacji na rzecz system\u00f3w rozproszonych, sk\u0142adaj\u0105cych si\u0119 z ma\u0142ych komponent\u00f3w (mikroserwis\u00f3w). Mniejsze aplikacje lub us\u0142ugi s\u0105 \u0142atwiejsze w utrzymaniu, a wymagania dotycz\u0105ce skalowalno\u015bci wymuszaj\u0105, aby dzia\u0142a\u0142y na r\u00f3\u017cnych urz\u0105dzeniach, cz\u0119sto na wielu jednocze\u015bnie. R\u0119czne wydawanie poszczeg\u00f3lnych mikroserwis\u00f3w, w przypadku gdy s\u0105 ich setki, wydaje si\u0119 by\u0107 niemo\u017cliwe do przeprowadzenia w spos\u00f3b bezawaryjny w satysfakcjonuj\u0105cym czasie. Automatyzacja wdro\u017ce\u0144 pozwala konfigurowa\u0107 wydawanie aplikacji w spos\u00f3b optymalny, tak, aby zapewni\u0107 niezawodno\u015b\u0107 dzia\u0142ania oprogramowania.<\/p>\n\n\n\n

                  #7. Zaawansowane techniki zapewnienia jako\u015bci<\/h3>\n\n\n\n

                  Wyobra\u017amy sobie wyszukiwark\u0119 wycieczek, kt\u00f3rej w\u0142a\u015bciciel chce ulepszy\u0107 algorytm wyszukiwania. Mo\u017cna wdro\u017cy\u0107 zar\u00f3wno star\u0105, jak i now\u0105 wersj\u0119 silnika jednocze\u015bnie i uruchamia\u0107 zapytania na obu. Definiuj\u0105c przy tym odpowiednie metryki, mo\u017cna w prosty spos\u00f3b ocenia\u0107 dzia\u0142anie nowego algorytmu. Dzi\u0119ki nim, w przypadku, gdy stary silnik b\u0119dzie zwraca\u0142 na przyk\u0142ad lepsze wyniki na niekt\u00f3re zapytania \u2013 mo\u017cna wykorzysta\u0107 te dane w celu ulepszenia nowego. Automatyczne wdra\u017canie nie jest samo w sobie gwarantem zapewnienia jako\u015bci, ale stanowi baz\u0119 do zastosowania zaawansowanych technik w celu jego osi\u0105gni\u0119cia.<\/p>\n\n\n\n

                  Automatyzacja vs. manualne wdra\u017canie<\/h2>\n\n\n\n

                  G\u0142\u00f3wne praktyki stosowane w obu podej\u015bciach (Continuous Integration i Continuous Deployment) s\u0105 jednakowe. R\u00f3\u017cnic\u0119 stanowi etap zastosowania automatyzacji wdro\u017cenia do \u015brodowiska produkcyjnego, co obrazuje poni\u017cszy rysunek. \u00a0<\/p>\n\n\n

                  \n
                  \"CI\/CD<\/figure>\n<\/div>\n\n\n

                  Jak ju\u017c wspomnia\u0142em, celem podej\u015bcia Continuous Delivery jest automatyzacja ka\u017cdego etapu cyklu wdra\u017cania do ostatniego \u015brodowiska przedprodukcyjnego, dzi\u0119ki czemu zmiany mo\u017cna wprowadzi\u0107 na docelowe \u015brodowisko w dowolnym momencie. W Continuous Deployment zmiany s\u0105 dostarczane bezpo\u015brednio na \u015brodowisko produkcyjne. R\u00f3\u017cnica to spos\u00f3b wdra\u017cania \u2013 automatyczny lub manualny.<\/p>\n\n\n\n

                  Praktyka ci\u0105g\u0142ego wdra\u017cania jest skomplikowana, procesy wykorzystywane w ci\u0105g\u0142ej integracji nie s\u0105 w stanie pokry\u0107 wszystkich niezb\u0119dnych etap\u00f3w koniecznych do jej poprawnego zaimplementowania w projekcie. Niezb\u0119dne jest u\u017cycie dodatkowych narz\u0119dzi, pozwalaj\u0105cych na testowanie i kontrolowanie r\u00f3\u017cnych cz\u0119\u015bci systemu (na przyk\u0142ad wydajno\u015bci, gotowo\u015bci do dzia\u0142ania, weryfikacja poprawno\u015bci integracji itp.).<\/p>\n\n\n\n

                  Podsumowanie<\/h2>\n\n\n\n

                  Dzi\u015b bez praktyk CI\/CD trudno wyobrazi\u0107 sobie jakikolwiek nowoczesny projekt IT. Automatyzacja proces\u00f3w ci\u0105g\u0142ej integracji i ci\u0105g\u0142ego dostarczania pozwala nam skr\u00f3ci\u0107 czas wdra\u017cania zmian, wydawa\u0107 oprogramowanie cz\u0119\u015bciej i w spos\u00f3b niezawodny. Dodatkowo szybciej uzyskujemy feedback od u\u017cytkownik\u00f3w. Ju\u017c teraz zach\u0119cam was do lektury drugiej cz\u0119\u015bci artyku\u0142u. Przyjrz\u0119 si\u0119 w nim bli\u017cej procesowi dostarczania oprogramowania z wykorzystaniem CI\/CD i om\u00f3wi\u0119 konkretne praktyki testerskie wraz z przegl\u0105dem najlepszych narz\u0119dzi CI\/CD.<\/p>\n","protected":false},"excerpt":{"rendered":"

                  Continuous Integration, Delivery and Deployment sprowadzaj\u0105 si\u0119 do automatyzacji procesu testowania i wdra\u017cania, minimalizacji (lub ca\u0142kowitego eliminowania) potrzeby ingerencji cz\u0142owieka, redukcji ryzyka wyst\u0105pienia b\u0142\u0119d\u00f3w oraz u\u0142atwienia tworzenia i wdra\u017cania oprogramowania.<\/p>\n","protected":false},"author":143,"featured_media":27620,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"iawp_total_views":68,"footnotes":""},"categories":[1,582],"tags":[566],"offering":[522],"class_list":["post-30743","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-artykuly","category-technologie","tag-devops","offering-tech-blog"],"acf":[],"_links":{"self":[{"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/posts\/30743","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=30743"}],"version-history":[{"count":1,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/posts\/30743\/revisions"}],"predecessor-version":[{"id":30747,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/posts\/30743\/revisions\/30747"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/media\/27620"}],"wp:attachment":[{"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/media?parent=30743"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/categories?post=30743"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/tags?post=30743"},{"taxonomy":"offering","embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/offering?post=30743"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}