{"id":9752,"date":"2020-09-24T16:17:43","date_gmt":"2020-09-24T14:17:43","guid":{"rendered":"https:\/\/sii.pl\/blog\/?p=9752"},"modified":"2023-10-24T09:58:46","modified_gmt":"2023-10-24T07:58:46","slug":"zalety-podejscia-infrastruktura-jako-kod-w-testowaniu-funkcjonalnym","status":"publish","type":"post","link":"https:\/\/sii.pl\/blog\/zalety-podejscia-infrastruktura-jako-kod-w-testowaniu-funkcjonalnym\/","title":{"rendered":"Zalety podej\u015bcia „infrastruktura jako kod” w testowaniu funkcjonalnym"},"content":{"rendered":"\n

Zanim przejdziemy do g\u0142\u0119bszego om\u00f3wienia tematu, musimy ustali\u0107 sobie pewne fakty i definicje. Zatem, czym\u017ce jest \u201einfrastruktura jak kod\u201d (infrastructure as code – IAC<\/em>)? <\/p>\n\n\n\n

Jest to koncepcja, w my\u015bl, kt\u00f3rej ca\u0142a infrastruktura i procesy jej przygotowania i konfiguracji powinny by\u0107 w mo\u017cliwie jak najwi\u0119kszym stopniu traktowane i zarz\u0105dzane w ten sam spos\u00f3b, co kod tego\u017c programu, kt\u00f3ry jest testowany b\u0105d\u017a dewelopowany. Oznacza to, \u017ce najlepsze praktyki stosowane w procesach wytwarzania kodu zaczynaj\u0105 by\u0107 aplikowane do proces\u00f3w przygotowania i konfigurowania infrastruktury. Powy\u017csza zasada jest przede wszystkim omawiana i chwalona w kontek\u015bcie \u015brodowiska chmurowego. W przypadku tego artyku\u0142u chcia\u0142bym pokaza\u0107 t\u0105 zasad\u0119 z punktu widzenia walidacji, a zw\u0142aszcza proces\u00f3w zarz\u0105dzania \u015brodowiskiem testowym.<\/p>\n\n\n\n

Je\u015bli chcesz by\u0107 zadowolony z \u017cycia, u\u017cywaj IAC<\/h2>\n\n\n\n

Pomy\u015blmy zatem, co w kontek\u015bcie walidacji, a zw\u0142aszcza test\u00f3w funkcjonalnych i \u2018hardware-in-the-loop\u2019 po\u017cera bardzo du\u017co czasu, jest \u017ar\u00f3d\u0142em ci\u0105g\u0142ej frustracji i wraca niezmiennie jak bumerang? Z mojego do\u015bwiadczenia, jest to oczywi\u015bcie temat przygotowania \u015brodowiska testowego. Fizycznych komputer\u00f3w, serwer\u00f3w (\u201ebare metal DUT\u201d) zawsze jest za ma\u0142o. Bardzo cz\u0119sto w wyniku uruchamianych na nich test\u00f3w psuj\u0105 si\u0119 i potrzebuj\u0105 jakich\u015b mniejszych czy wi\u0119kszych napraw. Na jednej maszynie cz\u0119sto trzeba uruchamia\u0107 kilka r\u00f3\u017cnych zestaw\u00f3w test\u00f3w, co wymaga zmian w konfiguracji albo totalnej zmiany systemu operacyjnego. A na sam koniec tego wszystkiego, w zespole jest tylko jeden specjalista, kt\u00f3ry tak naprawd\u0119 wie, jak przygotowa\u0107 maszyn\u0119 pod dany zestaw testowy i akurat jest na urlopie.
Na wszystkie powy\u017csze bol\u0105czki, lekarstwem jest \u201eInfrastruktura jak kod\u201d. Poszczeg\u00f3lne zalety u\u017cywania narz\u0119dzi do wdra\u017cania i zarz\u0105dzania konfiguracj\u0105 (przyk\u0142adowo: Ansible, Salt Stack, Chef, Puppet) opisz\u0119 jeszcze w dalszej cz\u0119\u015bci artyku\u0142u. Przede wszystkim jednak najwi\u0119kszy zysk jest w \u201ejako\u015bci \u017cycia\u201d in\u017cynier\u00f3w w codziennej pracy. W moim w\u0142asnym zespole utrzymujemy oko\u0142o pi\u0119\u0107dziesi\u0119ciu serwer\u00f3w. W naszym konkretnym przypadku do zarz\u0105dzania tym parkiem maszynowym wykorzystujemy Ansible i jego webowy dashboard \u2013 AWX. Nasza zaimplementowana automatyzacja pozwala nam w pe\u0142ni zarz\u0105dza\u0107 tym co si\u0119 dzieje ze wszystkimi serwerami. Codziennie sprawdzany jest stan ka\u017cdego serwera. Na \u017cyczenie jeste\u015bmy w stanie wgra\u0107 dowolny potrzebny nam system operacyjny. Raz w tygodniu automatycznie uruchamia si\u0119 update do najnowszych wersji oprogramowania. No i wiele wi\u0119cej.<\/p>\n\n\n\n

Poni\u017cszy obraz zawiera zdefiniowane przyk\u0142adowe inventory z u\u017cyciem Ansible oraz minimalistyczny playbook, kt\u00f3ry tworzy kontener dockera i dodaje go do istniej\u0105cego inventory. Maszyny w inventory mo\u017cna dzieli\u0107 na grupy wed\u0142ug naszych potrzeb. Wszystko pisane jest w j\u0119zyku YAML.<\/p>\n\n\n\n

\"fragment<\/a><\/figure>\n\n\n\n
<\/div>\n\n\n\n

IAC to nie tylko automatyzacja<\/h2>\n\n\n\n

Aktualnie w \u015bwiecie IT bardzo popularne sta\u0142y si\u0119 praktyki Continous Integration i Continous Delivery, a tak\u017ce metodologia DevOps. W szerszym spojrzeniu wszystkie te skr\u00f3ty i zasady odnosz\u0105 si\u0119 raczej do \u015brodowisk osadzonych w chmurze i zak\u0142adaj\u0105ce maksymaln\u0105 automatyzacj\u0119. Niestety, kiedy stajemy w obliczu testowania sprz\u0119tu lub oprogramowania ni\u017cszego poziomu, dochodzimy do miejsca, gdzie nie wszystko zautomatyzowa\u0107 si\u0119 da. Czasami testy manualne s\u0105 wymagane i stanowi\u0105 niema\u0142y zgrzyt w \u015bwietnie naoliwionej maszynie walidacji ? Mimo to, w \u017cadnym razie nie powinni\u015bmy rezygnowa\u0107 z tego co nam daj\u0105 te narz\u0119dzia. A w\u0142a\u015bnie podstaw\u0105 dla nich jest zasada \u201einfrastruktura jak kod\u201d. Tam, gdzie nie docieraj\u0105 narz\u0119dzia do automatyzacji, je\u015bli b\u0119dziemy trzyma\u0107 si\u0119 wyznaczonych zasad, to nadal poczynimy milowe kroki. A o to w tym wszystkim chodzi, aby ci\u0105gle stara\u0107 si\u0119 i\u015b\u0107 ku lepszemu.<\/p>\n\n\n\n

Ujednolicony proces przygotowania \u015brodowiska testowego \u2013 bez tego ani rusz<\/h2>\n\n\n\n

Jak ka\u017cdy tester wie, procesy, kt\u00f3re dziej\u0105 si\u0119 przed i po zestawach testowych, spo\u017cywaj\u0105 du\u017cy u\u0142amek czasu i zasob\u00f3w przeznaczanych na przetestowanie produktu. Nie raz i nie dwa widuje si\u0119 przypadki, gdzie proces przygotowania \u015brodowiska testowego sp\u0119dza sen z powiek in\u017cynier\u00f3w. Opanowanie kapry\u015bnego sprz\u0119tu i oprogramowania pod presj\u0105 czasu to nie lada wyzwanie. Ka\u017cdy tester spotka\u0142 si\u0119 z sytuacj\u0105, gdzie testy dzia\u0142aj\u0105 poprawnie na jednej maszynie, a na drugiej nie. Albo jeszcze bardziej ekstremalny tego przypadek \u2013 kiedy dany zestaw test\u00f3w dzia\u0142a tylko na jednej wybranej \u201emagicznej\u201d maszynie i nikt nie wie do ko\u0144ca, dlaczego. Kompletna i czytelna dokumentacja to \u015bwi\u0119ty graal, o kt\u00f3ry bardzo ci\u0119\u017cko w realnym \u015bwiecie. W momencie, gdy nie ma ujednoliconej, a co wa\u017cniejsze, powtarzalnej i jasnej metody na przygotowanie \u015brodowiska, nie ma mowy o jakichkolwiek pr\u00f3bach automatyzacji tych proces\u00f3w, a ka\u017cda kolejna paczka, ka\u017cdy kolejny release to, niemal\u017ce, droga przez m\u0119k\u0119 dla zespo\u0142u testowego.<\/p>\n\n\n\n

Dlatego w\u0142a\u015bnie \u201einfrastruktura jak kod\u201d<\/h2>\n\n\n\n

Przechodz\u0105c wi\u0119c do clue \u2013 co w\u0142a\u015bciwie zyskujemy stosuj\u0105c si\u0119 do zasad \u201einfrastruktura jako kod\u201d?<\/p>\n\n\n\n

    \n
  1. Przede wszystkim, jest to pierwszy krok do automatyzacji tych proces\u00f3w. Ten spos\u00f3b my\u015blenia jest fundamentem, na kt\u00f3rym oparte s\u0105 CI\/CD oraz DevOps.<\/li>\n\n\n\n
  2. Automatyzuj\u0105c te procesy w oczywisty spos\u00f3b zyskamy na czasie. Zyskamy r\u00f3wnie\u017c mo\u017cliwo\u015b\u0107 konfigurowania ca\u0142ej infrastruktury na raz.<\/li>\n\n\n\n
  3. W momencie, kiedy ca\u0142\u0105 nasz\u0105 infrastruktur\u0119 traktujemy jak kod, tak jak ten\u017ce kod w\u0142a\u015bnie, jeste\u015bmy w stanie w prosty spos\u00f3b odtworzy\u0107 ca\u0142\u0105 nasz\u0105 struktur\u0119. W moim projekcie w formie kodu przechowujemy nie tylko konfiguracj\u0119 serwer\u00f3w testowych. Jenkins z u\u017cyciem wtyczki JenkinsConfigAsCode jest budowany i uruchamiany wprost z kodu przechowywanego na repozytorium. Odtworzenie konfiguracji, job\u00f3w, historia build\u00f3w, dashboardy \u2013 wszystko to jest zapisane w skryptach i odtwarzalne w przypadku katastrofalnych b\u0142\u0119d\u00f3w. Podobnie Ansible AWX \u2013 konfiguracja jego przechowywana jest jako zestaw polece\u0144 Helm\u2019a Kubernetesa oraz skrypt\u00f3w Tower CLI. Wszystko co tylko si\u0119 da przerobi\u0107 na kod, l\u0105duje na repozytorium.<\/li>\n\n\n\n
  4. Bardzo, ale to bardzo wa\u017cna rzecz! W momencie, kiedy ca\u0142a konfiguracja jest przechowywana na repozytorium w formie kodu, automatycznie jest ona wersjonowana. A ka\u017cdy wie jakie s\u0105 zalety wersjonowania ? Wszelkie zmiany s\u0105 w pe\u0142ni widoczne \u2013 tak\u017ce nie mo\u017ce doj\u015b\u0107 do sytuacji, gdzie kto\u015b gdzie\u015b co\u015b zmienia i nikt nic nie wie. Wszystkie zmiany s\u0105 \u0142atwe do odkr\u0119cenia \u2013 wystarczy cofn\u0105\u0107 dany commit na repozytorium. Dodatkowo jest to sp\u00f3jne, wszyscy korzystaj\u0105 z tego samego kodu.<\/li>\n\n\n\n
  5. Kolejny zysk jest nieco innej natury. Traktuj\u0105c infrastruktur\u0119 jako kod, ten\u017ce kod zaczyna podlega\u0107 takim samym standardom, jakie obowi\u0105zuj\u0105 w cz\u0119\u015bci deweloperskiej zespo\u0142u. Dodatkowo przechodzi review, co pozwala wy\u0142apa\u0107 potencjalnie niebezpieczne pomy\u0142ki ju\u017c na wczesnym etapie.<\/li>\n\n\n\n
  6. Dodatkowo, kompletnie za darmo stymulujemy wymian\u0119 wiedzy i do\u015bwiadcze\u0144 mi\u0119dzy deweloperami a testerami czy DevOps\u2019ami. Deweloperzy mog\u0105 uczestniczy\u0107 w procesie tworzenia i konfiguracji infrastruktury. In\u017cynierowie operacyjni w wyniku interakcji z deweloperami zyskuj\u0105 lepsze zrozumienie produktu. Zesp\u00f3\u0142 si\u0119 integruje i nast\u0119puje naturalny przep\u0142yw informacji.<\/li>\n\n\n\n
  7. Poza tym, w momencie kiedy ca\u0142a infrastruktura jest spisana w formie kodu, automatycznie staje si\u0119 dla siebie najlepsz\u0105 dokumentacj\u0105.<\/li>\n\n\n\n
  8. Ostatecznie, gdy ju\u017c wszystko jest zaimplementowane, ca\u0142y zesp\u00f3\u0142 i produkt wiele zyskuje na jako\u015bci. Z czasem natomiast, jako\u015b\u0107 ta przek\u0142ada si\u0119 na oszcz\u0119dno\u015bci dla firmy i na ca\u0142kiem inn\u0105 jako\u015b\u0107 pracy in\u017cynier\u00f3w.<\/li>\n<\/ol>\n\n\n\n

    \u00a0Skoro ja mam IAC, to Ty te\u017c mo\u017cesz mie\u0107<\/h2>\n\n\n\n

    Jak mam nadziej\u0119 uda\u0142o mi si\u0119 to przytoczy\u0107 w powy\u017cszym artykule, traktowanie infrastruktury jak kodu niesie za sob\u0105 wiele korzy\u015bci, w pe\u0142ni wymiernych oraz nieco bardziej subtelnych. Maj\u0105c na uwadze wszystkie tego zalety i potencjalny egzystencjalny b\u00f3l wywo\u0142any niekorzystaniem z nich \u2013 wzywam was wszystkich do akcji! Korzystajcie z \u201einfrastruktura jako kod\u201d, to \u0142atwe i naprawd\u0119 bezbolesne ?<\/p>\n\n\n

    \n \n
    \n \n
    \n
    \n \n\n
    <\/div>\n <\/div>\n
    \n \n\n
    <\/div>\n <\/div>\n
    \n \n\n
    <\/div>\n <\/div>\n
    \n \n\n
    <\/div>\n <\/div>\n
    \n \n\n
    <\/div>\n <\/div>\n <\/div>\n \n
    \n
    \n \n\n
    <\/div>\n <\/div>\n
    \n \n\n
    <\/div>\n <\/div>\n
    \n \n\n
    <\/div>\n <\/div>\n
    \n \n\n
    <\/div>\n <\/div>\n
    \n \n\n
    <\/div>\n <\/div>\n <\/div>\n<\/div>\n \n\n
    \n 5\/5 ( votes: 6) <\/div>\n <\/div>\n","protected":false},"excerpt":{"rendered":"

    Zanim przejdziemy do g\u0142\u0119bszego om\u00f3wienia tematu, musimy ustali\u0107 sobie pewne fakty i definicje. Zatem, czym\u017ce jest \u201einfrastruktura jak kod\u201d (infrastructure … Continued<\/a><\/p>\n","protected":false},"author":259,"featured_media":9755,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_editorskit_title_hidden":false,"_editorskit_reading_time":0,"_editorskit_is_block_options_detached":false,"_editorskit_block_options_position":"{}","inline_featured_image":false,"footnotes":""},"categories":[1317],"tags":[970,972,971,973],"class_list":["post-9752","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-testowanie","tag-iac","tag-infrastructure-as-code","tag-infrastuktura-jako-kod","tag-testowanie-funkcjonalne"],"acf":[],"aioseo_notices":[],"republish_history":[],"featured_media_url":"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2020\/09\/24-09-2020.png","category_names":["Testowanie"],"_links":{"self":[{"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/posts\/9752"}],"collection":[{"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/users\/259"}],"replies":[{"embeddable":true,"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/comments?post=9752"}],"version-history":[{"count":2,"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/posts\/9752\/revisions"}],"predecessor-version":[{"id":25189,"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/posts\/9752\/revisions\/25189"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/media\/9755"}],"wp:attachment":[{"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/media?parent=9752"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/categories?post=9752"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sii.pl\/blog\/wp-json\/wp\/v2\/tags?post=9752"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}