1-ci hissə: Veb/Android
Qeyd: bu məqalə orijinal məqalənin rus dilinə tərcüməsidir Bununla belə, bütün illüstrasiyalar, keçidlər, sitatlar və terminlər rus dilinə tərcümə edilərkən mənanın təhrif olunmasının qarşısını almaq üçün orijinal dildə saxlanılır. Sizə xoşbəxt təhsil arzulayıram!
Hazırda DevOps ixtisası İT sənayesində ən çox tələb olunan ixtisaslardan biridir. Populyar iş axtarış saytlarını açsanız və maaşa görə süzgəcdən keçirsəniz, DevOps ilə əlaqəli işlərin siyahının başında olduğunu görəcəksiniz. Bununla belə, başa düşmək vacibdir ki, bu, əsasən, namizədin yüksək səviyyəli bacarıqlara, texnologiya və alətlərə dair biliyə malik olmasını nəzərdə tutan “Böyük” vəzifəyə aiddir. Bu, həm də istehsalın fasiləsiz işləməsi ilə bağlı yüksək məsuliyyətlə gəlir. Bununla belə, biz DevOps-un nə olduğunu unutmağa başladıq. Əvvəlcə bu, konkret şəxs və ya şöbə deyildi. Bu terminin təriflərini axtarsaq, metodologiya, təcrübələr, mədəniyyət fəlsəfəsi, anlayışlar qrupu və s. kimi çoxlu gözəl və düzgün isimlər tapacağıq.
Mənim ixtisasım test avtomatlaşdırma mühəndisidir (QA avtomatlaşdırma mühəndisi), lakin mən hesab edirəm ki, bu, yalnız avtomatik testlərin yazılması və ya test çərçivəsi arxitekturasının inkişafı ilə əlaqələndirilməməlidir. 2020-ci ildə avtomatlaşdırma infrastrukturu haqqında biliklər də vacibdir. Bu, testlərin həyata keçirilməsindən tutmuş məqsədlərinizə uyğun olaraq bütün maraqlı tərəflərə nəticələrin təqdim edilməsinə qədər avtomatlaşdırma prosesini özünüz təşkil etməyə imkan verir. Nəticə etibarilə, DevOps bacarıqları işi yerinə yetirmək üçün mütləqdir. Və bütün bunlar yaxşıdır, amma təəssüf ki, bir problem var (spoyler: bu məqalə bu problemi sadələşdirməyə çalışır). Məsələ ondadır ki, DevOps çətindir. Bu da göz qabağındadır, çünki şirkətlər etmək asan olan bir şey üçün çox pul ödəməyəcəklər... DevOps dünyasında mənimsənilməsi lazım olan çoxlu sayda alətlər, terminlər və təcrübələr var. Bu, karyeranın başlanğıcında xüsusilə çətindir və yığılmış texniki təcrübədən asılıdır.
Mənbə:
Burada, yəqin ki, giriş hissəsi ilə yekunlaşacaq və diqqətimizi bu məqalənin məqsədinə yönəldəcəyik.
Bu məqalə nədən bəhs edir?
Bu yazıda mən sınaq avtomatlaşdırma infrastrukturunun qurulması təcrübəmi bölüşəcəyəm. İnternetdə müxtəlif alətlər və onlardan istifadə qaydaları haqqında çoxlu məlumat mənbələri var, lakin mən onlara sırf avtomatlaşdırma kontekstində baxmaq istərdim. İnanıram ki, bir çox avtomatlaşdırma mühəndisləri, sizdən başqa heç kimin hazırlanmış testləri keçirmədiyi və ya onların saxlanmasına əhəmiyyət vermədiyi vəziyyətlə tanışdır. Nəticədə testlər köhnəlir və siz onları yeniləməyə vaxt sərf etməli olursunuz. Yenə karyeranın başlanğıcında bu, olduqca çətin bir iş ola bilər: hansı alətlərin müəyyən bir problemi aradan qaldırmağa kömək edəcəyinə, onların necə seçiləcəyinə, konfiqurasiyasına və saxlanmasına ağıllı şəkildə qərar vermək. Bəzi testçilər kömək üçün DevOps-a (insanlara) müraciət edirlər və düzünü desək, bu yanaşma işləyir. Bir çox hallarda bu, yeganə seçim ola bilər, çünki bütün asılılıqları görmə qabiliyyətimiz yoxdur. Ancaq bildiyimiz kimi, DevOps çox məşğul uşaqlardır, çünki onlar təşkilatdan/komandadan asılı olaraq bütün şirkətin infrastrukturu, yerləşdirilməsi, monitorinqi, mikroservisləri və digər oxşar vəzifələr barədə düşünməlidirlər. Adətən olduğu kimi, avtomatlaşdırma prioritet deyil. Belə olan halda başdan sona öz üzərimizə düşən hər şeyi etməyə çalışmalıyıq. Bu, asılılıqları azaldacaq, iş axınını sürətləndirəcək, bacarıqlarımızı təkmilləşdirəcək və baş verənlərin daha böyük mənzərəsini görməyə imkan verəcək.
Məqalədə ən populyar və populyar alətlər təqdim olunur və onlardan addım-addım avtomatlaşdırma infrastrukturunun qurulması üçün necə istifadə olunacağı göstərilir. Hər bir qrup şəxsi təcrübə vasitəsilə sınaqdan keçirilmiş alətlərlə təmsil olunur. Ancaq bu, eyni şeyi istifadə etməli olduğunuz anlamına gəlmir. Alətlərin özləri vacib deyil, görünür və köhnəlir. Bizim mühəndislik vəzifəmiz əsas prinsipləri başa düşməkdir: bu alətlər qrupuna niyə ehtiyacımız var və onların köməyi ilə hansı iş problemlərini həll edə bilərik. Buna görə də hər bölmənin sonunda təşkilatınızda istifadə oluna biləcək oxşar alətlərə keçidlər buraxıram.
Bu yazıda nə yoxdur
Bir daha təkrar edirəm ki, məqalə xüsusi alətlər haqqında deyil, ona görə də sənədlərdən və xüsusi əmrlərin təsvirindən kod əlavələri olmayacaq. Ancaq hər bölmənin sonunda ətraflı araşdırma üçün linklər buraxıram.
Bu, ona görə edilir:
- bu materialı müxtəlif mənbələrdə (sənədlər, kitablar, video kurslar) tapmaq çox asandır;
- daha dərinə getməyə başlasaq, bu məqalənin 10, 20, 30 hissəsini (planlar 2-3 olduğu halda) yazmalı olacağıq;
- Mən sadəcə vaxtınızı itirmək istəmirəm, çünki siz eyni məqsədlərə çatmaq üçün başqa vasitələrdən istifadə etmək istəyə bilərsiniz.
Praktika
Mən çox istərdim ki, bu material hər bir oxucu üçün faydalı olsun, sadəcə oxuyub unudulmuş deyil. Hər hansı bir araşdırmada təcrübə çox vacib bir komponentdir. Bunun üçün hazırlamışam. İcra etdiyiniz əmrlərin sətirlərini ağılsızcasına köçürmədiyinizə əmin olmaq üçün sizi ev tapşırığı da gözləyir.
Planı
Addım
Texnologiya
Tools
1
Yerli qaçış (veb / android demo testləri hazırlayın və onu yerli olaraq işə salın)
Node.js, Selenium, Appium
2
Versiya nəzarət sistemləri
get
3
Konteynerləşmə
Docker, Selenium grid, Selenoid (Veb, Android)
4
CI/CD
Gitlab CI
5
Bulud platformaları
Google Cloud Platform
6
Orkestr
Kubernetes
7
Kod kimi infrastruktur (IaC)
Terraform, Ansible
Hər bölmənin strukturu
Hekayəni aydın saxlamaq üçün hər bölmə aşağıdakı kontur əsasında təsvir edilmişdir:
- texnologiyanın qısa təsviri,
- avtomatlaşdırma infrastrukturunun dəyəri,
- infrastrukturun mövcud vəziyyətinin təsviri,
- təhsil üçün bağlantılar,
- oxşar alətlər.
1. Testləri yerli olaraq həyata keçirin
Texnologiyanın qısa təsviri
Bu, demo testlərini yerli olaraq həyata keçirmək və onların keçdiyini yoxlamaq üçün sadəcə bir hazırlıq addımıdır. Praktiki hissədə Node.js istifadə olunur, lakin proqramlaşdırma dili və platforması da vacib deyil və siz şirkətinizdə istifadə olunanlardan istifadə edə bilərsiniz.
Bununla belə, avtomatlaşdırma alətləri kimi mən veb platformalar üçün Selenium WebDriver və Android platforması üçün müvafiq olaraq Appium istifadə etməyi məsləhət görürəm, çünki növbəti addımlarda bu alətlərlə işləmək üçün xüsusi olaraq hazırlanmış Docker şəkillərindən istifadə edəcəyik. Üstəlik, iş tələblərinə istinad edərək, bu alətlər bazarda ən çox tələb olunur.
Diqqət etdiyiniz kimi, biz yalnız veb və Android testlərini nəzərdən keçiririk. Təəssüf ki, iOS tamamilə fərqli bir hekayədir (təşəkkürlər Apple). Gələcək hissələrdə IOS ilə əlaqəli həllər və təcrübələri nümayiş etdirməyi planlaşdırıram.
Avtomatlaşdırma infrastrukturu üçün dəyər
İnfrastruktur baxımından yerli olaraq işləmək heç bir dəyər vermir. Siz yalnız testlərin yerli brauzerlərdə və simulyatorlarda yerli maşında işlədiyini yoxlayırsınız. Amma hər halda bu, zəruri başlanğıc nöqtəsidir.
İnfrastrukturun cari vəziyyətinin təsviri
Kəşf etmək üçün bağlantılar
Oxşar alətlər
- Selenium/Appium testləri ilə birlikdə bəyəndiyiniz hər hansı proqramlaşdırma dili;
- hər hansı bir test;
- hər hansı bir sınaqçı.
2. Versiyaya nəzarət sistemləri (Git)
Texnologiyanın qısa təsviri
Versiyaya nəzarətin həm komandada, həm də fərdi olaraq inkişafın son dərəcə vacib hissəsi olduğunu desəm, heç kimə böyük bir vəhy olmayacaq. Müxtəlif mənbələrə əsaslanaraq əminliklə demək olar ki, Git ən populyar nümayəndədir. Versiyaya nəzarət sistemi kod paylaşma, versiyaları saxlamaq, əvvəlki filiallara bərpa etmək, layihə tarixçəsini izləmək və ehtiyat nüsxələri çıxarmaq kimi bir çox üstünlükləri təmin edir. Hər bir məqamı ətraflı müzakirə etməyəcəyik, çünki əminəm ki, siz onunla çox tanışsınız və gündəlik işinizdə istifadə edirsiniz. Ancaq birdən yoxsa, bu məqaləni oxumağı dayandırmağı və mümkün qədər tez bu boşluğu doldurmağı məsləhət görürəm.
Avtomatlaşdırma infrastrukturu üçün dəyər
Və burada ağlabatan bir sual verə bilərsiniz: “Niyə bizə Git haqqında danışır? Hər kəs bunu bilir və ondan həm inkişaf kodu, həm də avtomatik sınaq kodu üçün istifadə edir.” Siz tamamilə haqlı olacaqsınız, lakin bu məqalədə biz infrastrukturdan danışırıq və bu bölmə 7-ci bölmə üçün önizləmə rolunu oynayır: “İnfrastruktur Kodeks (IaC)”. Bizim üçün bu o deməkdir ki, bütün infrastruktur, o cümlədən sınaqlar kod şəklində təsvir olunub, ona görə də biz ona versiya sistemlərini tətbiq edə və inkişaf və avtomatlaşdırma kodu kimi oxşar faydalar əldə edə bilərik.
Biz 7-ci addımda IaC-ni daha ətraflı nəzərdən keçirəcəyik, lakin indi də siz yerli repozitoriya yaradaraq Git-dən yerli olaraq istifadə etməyə başlaya bilərsiniz. İnfrastruktura uzaqdan depo əlavə etdikdə böyük mənzərə genişlənəcək.
İnfrastrukturun cari vəziyyətinin təsviri
Kəşf etmək üçün bağlantılar
Oxşar alətlər
3. Konteynerləşdirmə (Docker)
Texnologiyanın qısa təsviri
Konteynerləşdirmənin oyun qaydalarını necə dəyişdiyini nümayiş etdirmək üçün gəlin bir neçə onilliklərə keçmişə qayıdaq. O vaxtlar insanlar proqramları işə salmaq üçün server maşınları alıb istifadə edirdilər. Lakin əksər hallarda tələb olunan başlanğıc resursları əvvəlcədən məlum deyildi. Nəticədə şirkətlər bahalı, güclü serverlərin alınmasına pul xərcləsələr də, bu imkanların bir qismi tam istifadə olunmayıb.
Təkamülün növbəti mərhələsi istifadə olunmayan resurslara pul sərf etmək problemini həll edən virtual maşınlar (VM) idi. Bu texnologiya tamamilə təcrid olunmuş yer ayıraraq eyni server daxilində proqramları bir-birindən asılı olmayaraq idarə etməyə imkan verdi. Ancaq təəssüf ki, hər hansı bir texnologiyanın çatışmazlıqları var. VM-ni işə salmaq üçün CPU, RAM, yaddaş istehlak edən tam əməliyyat sistemi tələb olunur və OS-dən asılı olaraq lisenziya xərcləri nəzərə alınmalıdır. Bu amillər yükləmə sürətinə təsir edir və daşınmanı çətinləşdirir.
İndi konteynerləşdirməyə gəlirik. Bir daha qeyd edək ki, bu texnologiya əvvəlki problemi həll edir, çünki konteynerlər tam OS-dən istifadə etmir, bu da böyük miqdarda resursları boşaldır və daşınma üçün sürətli və çevik həll təqdim edir.
Əlbəttə ki, konteynerləşdirmə texnologiyası yeni bir şey deyil və ilk dəfə 70-ci illərin sonlarında təqdim edilmişdir. O günlərdə çoxlu araşdırmalar, inkişaflar, cəhdlər həyata keçirilirdi. Ancaq bu texnologiyanı uyğunlaşdıran və kütlələr üçün asanlıqla əlçatan edən Docker idi. İndi konteynerlər dedikdə, əksər hallarda Docker nəzərdə tutulur. Docker konteynerləri haqqında danışarkən biz Linux konteynerlərini nəzərdə tuturuq. Konteynerləri işə salmaq üçün Windows və macOS sistemlərindən istifadə edə bilərik, lakin bu halda əlavə təbəqənin göründüyünü başa düşmək vacibdir. Məsələn, Mac-da Docker, yüngül Linux VM-nin içərisində konteynerləri səssizcə işlədir. Konteynerlər içərisində Android emulyatorlarının işlədilməsini müzakirə etdiyimiz zaman bu mövzuya qayıdacağıq, buna görə də burada daha ətraflı müzakirə edilməli olan çox vacib bir nüans var.
Avtomatlaşdırma infrastrukturu üçün dəyər
Konteynerləşdirmə və Docker-in əla olduğunu öyrəndik. Gəlin buna avtomatlaşdırma kontekstində baxaq, çünki hər bir alət və ya texnologiya problemi həll etməlidir. UI testləri kontekstində test avtomatlaşdırılmasının aşkar problemlərini təsvir edək:
- Selenium və xüsusilə Appium quraşdırarkən çox sayda asılılıq;
- brauzerlərin, simulyatorların və sürücülərin versiyaları arasında uyğunluq problemləri;
- paralel işləmə üçün xüsusilə vacib olan brauzerlər/simulyatorlar üçün təcrid olunmuş yerin olmaması;
- eyni anda 10, 50, 100 və ya hətta 1000 brauzer işlətmək lazımdırsa, idarə etmək və saxlamaq çətindir.
Lakin Selenium ən populyar avtomatlaşdırma vasitəsi və Docker ən populyar konteynerləşdirmə vasitəsi olduğundan, kiminsə yuxarıda qeyd olunan problemləri həll etmək üçün güclü bir alət yaratmaq üçün onları birləşdirməyə çalışması təəccüblü olmamalıdır. Bu cür həlləri daha ətraflı nəzərdən keçirək.
Dokerdə selenium şəbəkəsi
Bu alət birdən çox maşında birdən çox brauzer işlətmək və onları mərkəzi mərkəzdən idarə etmək üçün Selenium dünyasında ən populyardır. Başlamaq üçün ən azı 2 hissəni qeydiyyatdan keçirməlisiniz: Hub və Node(lər). Hub, testlərdən gələn bütün sorğuları qəbul edən və onları müvafiq Qovşaqlara paylayan mərkəzi qovşaqdır. Hər Node üçün, məsələn, istədiyiniz brauzeri və onun versiyasını göstərərək, müəyyən bir konfiqurasiyanı konfiqurasiya edə bilərik. Bununla belə, biz hələ də uyğun brauzer sürücülərinin qayğısına qalmalıyıq və onları istədiyiniz Nodlara quraşdırmalıyıq. Bu səbəbdən, Linux OS-də quraşdırıla bilməyən brauzerlərlə işləmək lazım olduğu hallar istisna olmaqla, Selenium şəbəkəsi təmiz formada istifadə edilmir. Bütün digər hallar üçün Selenium şəbəkə Hub və Qovşaqlarını idarə etmək üçün Docker şəkillərindən istifadə etmək əhəmiyyətli dərəcədə çevik və düzgün həll yolu olardı. Bu yanaşma qovşaqların idarə edilməsini xeyli asanlaşdırır, çünki artıq quraşdırılmış brauzerlərin və sürücülərin uyğun versiyaları ilə bizə lazım olan şəkli seçə bilirik.
Sabitlik haqqında mənfi rəylərə baxmayaraq, xüsusən də paralel olaraq çox sayda qovşaq işləyərkən, Selenium şəbəkəsi hələ də Selenium testlərini paralel aparmaq üçün ən populyar vasitədir. Qeyd etmək vacibdir ki, bu alətin müxtəlif təkmilləşdirmələri və modifikasiyaları müxtəlif darboğazlarla mübarizə aparan açıq mənbədə daim görünür.
Veb üçün selenoid
Bu alət Selenium dünyasında bir sıçrayışdır, çünki o, qutudan çıxarılır və bir çox avtomatlaşdırma mühəndislərinin həyatını xeyli asanlaşdırır. Əvvəla, bu Selenium şəbəkəsinin başqa bir modifikasiyası deyil. Bunun əvəzinə tərtibatçılar Golanqda Selenium Hub-ın tamamilə yeni versiyasını yaratdılar ki, bu da müxtəlif brauzerlər üçün yüngül çəkili Docker təsvirləri ilə birləşərək sınaq avtomatlaşdırmasının inkişafına təkan verdi. Üstəlik, Selenium Grid vəziyyətində, bütün lazımi brauzerləri və onların versiyalarını əvvəlcədən müəyyən etməliyik, bu, yalnız bir brauzerlə işləyərkən problem yaratmır. Ancaq bir çox dəstəklənən brauzerlərə gəldikdə, Selenoid "tələb olunan brauzer" xüsusiyyəti sayəsində bir nömrəli həlldir. Bizdən tələb olunan tək şey əvvəlcədən brauzerlərlə lazımi şəkilləri yükləmək və Selenoidin qarşılıqlı əlaqədə olduğu konfiqurasiya faylını yeniləməkdir. Selenoid testlərdən sorğu aldıqdan sonra o, avtomatik olaraq istədiyiniz konteyneri istədiyiniz brauzerlə işə salacaq. Test başa çatdıqda, Selenoid konteyneri tərk edəcək və bununla da gələcək sorğular üçün resursları boşaltacaq. Bu yanaşma Selenium şəbəkəsində tez-tez rastlaşdığımız məşhur "qovşağın deqradasiyası" problemini tamamilə aradan qaldırır.
Ancaq təəssüf ki, Selenoid hələ də gümüş güllə deyil. "Tələb üzrə brauzer" funksiyasını əldə etdik, lakin "Tələb üzrə resurslar" funksiyası hələ də mövcud deyil. Selenoiddən istifadə etmək üçün biz onu fiziki avadanlıqda və ya VM-də yerləşdirməliyik, yəni nə qədər resursun ayrılması lazım olduğunu əvvəlcədən bilməliyik. Güman edirəm ki, bu, paralel olaraq 10, 20 və hətta 30 brauzer işlədən kiçik layihələr üçün problem deyil. Bəs bizə 100, 500, 1000 və daha çox lazım olsa nə etməli? Həmişə bu qədər resurs saxlamaq və ödəmək mənasızdır. Bu məqalənin 5 və 6-cı bölmələrində biz sizə miqyas verməyə imkan verən və bununla da şirkət xərclərini əhəmiyyətli dərəcədə azaldan həlləri müzakirə edəcəyik.
Selenoid android üçün
Selenoidin veb avtomatlaşdırma vasitəsi kimi uğurundan sonra insanlar Android üçün oxşar bir şey istədilər. Və belə oldu - Selenoid Android dəstəyi ilə buraxıldı. Yüksək səviyyəli istifadəçi nöqteyi-nəzərindən iş prinsipi veb avtomatlaşdırılmasına bənzəyir. Yeganə fərq ondadır ki, brauzer konteynerləri əvəzinə Selenoid Android emulyator konteynerlərini işlədir. Fikrimcə, bu, hazırda Android testlərini paralel aparmaq üçün ən güclü pulsuz vasitədir.
Bu alətin mənfi tərəfləri haqqında danışmaq istəməzdim, çünki onu çox sevirəm. Ancaq yenə də veb avtomatlaşdırılmasına aid olan və miqyasla əlaqəli eyni çatışmazlıqlar var. Bundan əlavə, aləti ilk dəfə quraşdırırıqsa, sürpriz ola biləcək daha bir məhdudiyyət haqqında danışmalıyıq. Android şəkillərini işə salmaq üçün bizə daxili virtualizasiya dəstəyi ilə fiziki maşın və ya VM lazımdır. Necə etməli təlimatında mən bunu Linux VM-də necə aktivləşdirməyi nümayiş etdirirəm. Bununla belə, əgər siz macOS istifadəçisisinizsə və Selenoid-i yerli olaraq yerləşdirmək istəyirsinizsə, o zaman Android testlərini həyata keçirmək mümkün olmayacaq. Lakin siz həmişə yerli olaraq 'iç-içə virtuallaşdırma' konfiqurasiya edilmiş Linux VM-ni işlədə və Selenoidi içəridə yerləşdirə bilərsiniz.
İnfrastrukturun cari vəziyyətinin təsviri
Bu məqalənin kontekstində biz infrastrukturu göstərmək üçün 2 alət əlavə edəcəyik. Bunlar veb testləri üçün Selenium şəbəkəsi və Android testləri üçün Selenoiddir. GitHub təlimatında mən də sizə veb testlərini həyata keçirmək üçün Selenoiddən necə istifadə edəcəyinizi göstərəcəyəm.
Kəşf etmək üçün bağlantılar
Oxşar alətlər
- Digər konteynerləşdirmə vasitələri var, lakin Docker ən populyardır. Başqa bir şey sınamaq istəyirsinizsə, Selenium testlərini paralel olaraq həyata keçirmək üçün əhatə etdiyimiz alətlərin qutudan çıxmayacağını unutmayın.
- Artıq deyildiyi kimi, Selenium şəbəkəsinin bir çox modifikasiyası var, məsələn,.
4.CI/CD
Texnologiyanın qısa təsviri
Davamlı inteqrasiya təcrübəsi inkişafda olduqca populyardır və versiyaya nəzarət sistemləri ilə bərabərdir. Buna baxmayaraq, hiss edirəm ki, terminologiyada çaşqınlıq var. Bu paraqrafda bu texnologiyanın 3 modifikasiyasını öz baxışımdan təsvir etmək istərdim. İnternetdə müxtəlif şərhləri olan çoxlu məqalələr tapa bilərsiniz və fikirləriniz fərqlidirsə, bu tamamilə normaldır. Ən əsası, həmkarlarınızla eyni səhifədə olmanızdır.
Beləliklə, 3 termin var: CI - Continuous Integration, CD - Continuous Delivery və yenidən CD - Continuous Deployment. (Aşağıda bu terminləri ingilis dilində istifadə edəcəyəm). Hər bir modifikasiya inkişaf boru kəmərinizə bir neçə əlavə addım əlavə edir. Amma söz fasiləsiz (davamlı) ən vacib şeydir. Bu kontekstdə biz başdan sona, fasiləsiz və ya əl müdaxiləsi olmadan baş verən bir şeyi nəzərdə tuturuq. Bu kontekstdə CI & CD və CD-yə baxaq.
- Davamlı İnteqrasiya bu təkamülün ilkin addımıdır. Serverə yeni kodu təqdim etdikdən sonra dəyişikliklərimizin qaydasında olduğuna dair tez rəy alacağımızı gözləyirik. Tipik olaraq, CI-yə çalışan statik kod analizi alətləri və vahid/daxili API testləri daxildir.Bu, bir neçə saniyə/dəqiqə ərzində kodumuz haqqında məlumat əldə etməyə imkan verir.
- Davamlı Çatdırılma inteqrasiya/UI testləri apardığımız daha təkmil addımdır. Ancaq bu mərhələdə biz CI ilə olduğu kimi tez nəticə əldə etmirik. Birincisi, bu tip testlərin tamamlanması daha uzun çəkir. İkincisi, işə başlamazdan əvvəl dəyişikliklərimizi test/stend mühitinə yerləşdirməliyik. Üstəlik, əgər biz mobil inkişafdan danışırıqsa, o zaman tətbiqimizin quruluşunu yaratmaq üçün əlavə bir addım görünür.
- Davamlı yerləşdirmə Əvvəlki mərhələlərdə bütün qəbul testlərindən keçdiyimiz halda, dəyişikliklərimizi avtomatik olaraq istehsala buraxacağımızı güman edir. Bundan əlavə, buraxılış mərhələsindən sonra, istehsalda tüstü testlərinin aparılması və maraq göstəricilərinin toplanması kimi müxtəlif mərhələləri konfiqurasiya edə bilərsiniz. Davamlı Yerləşdirmə yalnız avtomatlaşdırılmış testlərlə yaxşı əhatə olunmaqla mümkündür. Sınaq da daxil olmaqla hər hansı əl müdaxiləsi tələb olunursa, bu, artıq deyil Fasiləsiz (davamlı). Onda deyə bilərik ki, bizim boru kəmərimiz yalnız Davamlı Çatdırılma praktikasına uyğundur.
Avtomatlaşdırma infrastrukturu üçün dəyər
Bu bölmədə aydınlaşdırmalıyam ki, biz end-to-end UI testləri haqqında danışarkən, bu o deməkdir ki, biz dəyişikliklərimizi və əlaqəli xidmətlərimizi test mühitlərinə yerləşdirməliyik. Davamlı İnteqrasiya - proses bu tapşırıq üçün tətbiq edilmir və biz ən azı Davamlı Çatdırılma təcrübələrinin həyata keçirilməsinin qayğısına qalmalıyıq. Davamlı Yerləşdirmə də UI testləri kontekstində məna kəsb edir, əgər biz onları istehsalda işə salacağıq.
Memarlıq dəyişikliyinin illüstrasiyasına baxmazdan əvvəl GitLab CI haqqında bir neçə söz demək istəyirəm. Digər CI/CD alətlərindən fərqli olaraq, GitLab uzaq repozitoriya və bir çox başqa əlavə funksiyalar təqdim edir. Beləliklə, GitLab CI-dən daha çoxdur. Buraya mənbə kodunun idarə edilməsi, Çevik idarəetmə, CI/CD boru kəmərləri, giriş alətləri və qutudan kənar ölçülər toplusu daxildir. GitLab arxitekturası Gitlab CI/CD və GitLab Runner-dən ibarətdir. Rəsmi internet saytından qısa təsviri təqdim edirik:
Gitlab CI/CD, vəziyyətini verilənlər bazasında saxlayan, layihələri/qurumları idarə edən və istifadəçi interfeysi təmin edən API ilə veb proqramdır. GitLab Runner qurmaları emal edən proqramdır. O, ayrıca yerləşdirilə bilər və API vasitəsilə GitLab CI/CD ilə işləyir. Çalışan testlər üçün həm Gitlab nümunəsi, həm də Runner lazımdır.
İnfrastrukturun cari vəziyyətinin təsviri
Kəşf etmək üçün bağlantılar
Oxşar alətlər
- Və bir çox başqaları
5. Bulud platformaları
Texnologiyanın qısa təsviri
Bu bölmədə biz “ictimai buludlar” adlı məşhur tendensiya haqqında danışacağıq. Yuxarıda təsvir edilən virtuallaşdırma və konteynerləşdirmə texnologiyalarının təmin etdiyi böyük faydalara baxmayaraq, bizim hələ də hesablama resurslarına ehtiyacımız var. Şirkətlər bahalı serverlər alır və ya data mərkəzləri icarəyə götürürlər, lakin bu halda bizə nə qədər resurs lazım olacağı, onlardan 24/7 və hansı məqsədlər üçün istifadə edəcəyimiz barədə hesablamalar (bəzən qeyri-real) aparmaq lazımdır. Məsələn, istehsal XNUMX/XNUMX işləyən server tələb edir, lakin iş saatları xaricində sınaq üçün oxşar resurslara ehtiyacımız varmı? Bu, həmçinin həyata keçirilən testin növündən də asılıdır. Nümunə olaraq, növbəti gün nəticələr əldə etmək üçün qeyri-iş saatlarında keçirməyi planlaşdırdığımız yük/stress testləri ola bilər. Ancaq mütləq XNUMX/XNUMX server mövcudluğu başdan sona avtomatlaşdırılmış testlər üçün tələb olunmur və xüsusən də əllə sınaq mühitləri üçün tələb olunmur. Belə hallar üçün tələb üzrə lazım olan qədər resurs əldə etmək, onlardan istifadə etmək və ehtiyac olmadıqda ödənişi dayandırmaq yaxşı olardı. Üstəlik, bir neçə siçan klikləməklə və ya bir neçə skript işlətməklə onları dərhal qəbul etmək əla olardı. İctimai buludlar bunun üçün istifadə olunur. Tərifə baxaq:
“İctimai bulud üçüncü tərəf provayderləri tərəfindən ictimai İnternet üzərindən təklif olunan hesablama xidmətləri kimi müəyyən edilir və onlardan istifadə etmək və ya almaq istəyən hər kəs üçün əlçatan edir. Müştərilərə istehlak etdikləri CPU dövrləri, saxlama və ya bant genişliyi üçün yalnız istifadəyə görə ödəniş etməyə imkan verən pulsuz və ya tələb əsasında satıla bilər."
Belə bir fikir var ki, ictimai buludlar bahadır. Lakin onların əsas ideyası şirkət xərclərini azaltmaqdır. Daha əvvəl qeyd edildiyi kimi, ictimai buludlar sizə tələb olunan resursları əldə etməyə və yalnız onlardan istifadə etdiyiniz vaxta görə ödəməyə imkan verir. Həm də bəzən unuduruq ki, işçilər maaş alır, mütəxəssislər də bahalı resursdur. Nəzərə almaq lazımdır ki, ictimai buludlar infrastruktur dəstəyini xeyli asanlaşdırır ki, bu da mühəndislərə diqqəti daha vacib vəzifələrə yönəltməyə imkan verir.
Avtomatlaşdırma infrastrukturu üçün dəyər
Başdan sona UI testləri üçün hansı xüsusi resurslara ehtiyacımız var? Əsasən bunlar brauzerlər və emulyatorlar üçün virtual maşınlar və ya klasterlərdir (növbəti hissədə Kubernetes haqqında danışacağıq). Nə qədər çox brauzer və emulyatorun eyni vaxtda işləməsini istəsək, bir o qədər çox CPU və yaddaş tələb olunur və bunun üçün bir o qədər çox pul ödəməliyik. Beləliklə, testlərin avtomatlaşdırılması kontekstində ictimai buludlar bizə tələb üzrə çoxlu sayda (100, 200, 1000...) brauzer/emulator işlətməyə, test nəticələrini mümkün qədər tez əldə etməyə və belə dəlicəsinə resurs tələb edən ödənişləri dayandırmağa imkan verir. güc.
Ən məşhur bulud provayderləri Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP)-dir. Necə etməli təlimatı GCP-dən necə istifadə edəcəyinə dair nümunələr təqdim edir, lakin ümumiyyətlə, avtomatlaşdırma tapşırıqları üçün nədən istifadə etdiyinizin əhəmiyyəti yoxdur. Onların hamısı təxminən eyni funksionallığı təmin edir. Tipik olaraq, provayder seçmək üçün rəhbərlik şirkətin bütün infrastrukturuna və biznes tələblərinə diqqət yetirir ki, bu da bu məqalənin əhatə dairəsindən kənardır. Avtomatlaşdırma mühəndisləri üçün bulud provayderlərinin istifadəsini, məsələn, Sauce Labs, BrowserStack, BitBar və s. kimi test məqsədləri üçün xüsusi olaraq bulud platformalarından istifadə ilə müqayisə etmək daha maraqlı olacaq. Elə isə gəlin bunu da edək! Fikrimcə, Sauce Labs ən məşhur bulud sınaq fermasıdır, buna görə də müqayisə üçün istifadə etdim.
Avtomatlaşdırma məqsədləri üçün GCP vs Sauce Labs:
Təsəvvür edək ki, eyni vaxtda 8 veb testi və 8 Android testi keçirməliyik. Bunun üçün biz GCP istifadə edəcəyik və Selenoid ilə 2 virtual maşın işlədəcəyik. Birincisində biz brauzerlərlə 8 konteyner qaldıracağıq. İkincidə emulyatorları olan 8 konteyner var. Gəlin qiymətlərə nəzər salaq:
Chrome ilə bir konteyner işlətmək üçün bizə lazımdır n1-standart-1 avtomobil. Android vəziyyətində belə olacaq n1-standart-4 bir emulyator üçün. Əslində, daha çevik və daha ucuz bir yol, CPU/Yaddaş üçün xüsusi istifadəçi dəyərlərini təyin etməkdir, lakin hazırda bu, Sauce Labs ilə müqayisə üçün vacib deyil.
Sos Laboratoriyalarından istifadə üçün tariflər:
İnanıram ki, siz artıq fərqi görmüsünüz, amma yenə də vəzifəmiz üçün hesablamalar olan bir cədvəl təqdim edəcəyəm:
Tələb olunan resurslar
Aylıq
İş saatları(8:8 - XNUMX:XNUMX)
İş saatları+ Üstünlüklü
Veb üçün GCP
n1-standart-1 x 8 = n1-standart-8
$194.18
23 gün * 12 saat * 0.38 = $104.88
23 gün * 12 saat * 0.08 = $22.08
Veb üçün sous laboratoriyaları
Virtual Cloud8 paralel testləri
$1.559
-
-
Android üçün GCP
n1-standart-4 x 8: n1-standart-16
$776.72
23 gün * 12 saat * 1.52 = $419.52
23 gün * 12 saat * 0.32 = $88.32
Android üçün sous laboratoriyaları
Real Device Cloud 8 paralel testləri
$1.999
-
-
Gördüyünüz kimi, qiymət fərqi böyükdür, xüsusən də yalnız on iki saatlıq iş dövründə testlər keçirsəniz. Ancaq üstünlük verilən maşınlardan istifadə etsəniz, xərcləri daha da azalda bilərsiniz. Bu nədir?
Önəmli VM adi nümunələrdən daha aşağı qiymətə yarada və işlədə biləcəyiniz nümunədir. Bununla belə, Compute Engine digər tapşırıqlar üçün həmin resurslara giriş tələb edərsə, bu nümunələri dayandıra (öncədən seçə bilər). Üstünlük verilən nümunələr artıq Hesablama Mühərrikinin tutumudur, ona görə də onların əlçatanlığı istifadəyə görə dəyişir.
Tətbiqləriniz nasazlığa dözümlüdürsə və mümkün nümunə seçimlərinə tab gətirə bilirsə, üstünlük verilən nümunələr Compute Engine xərclərinizi əhəmiyyətli dərəcədə azalda bilər. Məsələn, toplu emal işləri üstünlük verilən nümunələrdə işləyə bilər. Bu nümunələrdən bəziləri emal zamanı dayandırılırsa, iş yavaşlayır, lakin tamamilə dayanmır. Üstünlüklü nümunələr, mövcud nümunələrinizə əlavə iş yükü qoymadan və əlavə normal nümunələr üçün tam qiymət ödəməyi tələb etmədən toplu emal tapşırıqlarınızı tamamlayır.
Və hələ də bitməyib! Əslində, əminəm ki, heç kim 12 saat fasiləsiz testlər keçirmir. Əgər belədirsə, onda siz virtual maşınları lazım olmadıqda avtomatik işə sala və dayandıra bilərsiniz. Faktiki istifadə müddəti gündə 6 saata qədər azaldıla bilər. Sonra vəzifəmizin kontekstində ödəniş 11 brauzer üçün ayda 8 dollara qədər azalacaq. Bu gözəl deyilmi? Lakin üstünlük verilən maşınlarla biz diqqətli olmalı və fasilələrə və qeyri-sabitliyə hazır olmalıyıq, baxmayaraq ki, bu vəziyyətlər proqram təminatı ilə təmin edilə və idarə oluna bilər. Buna dəyər!
Ancaq mən heç vaxt “bulud test fermalarından istifadə etməyin” demirəm. Onların bir sıra üstünlükləri var. Əvvəla, bu, sadəcə virtual maşın deyil, qutudan kənar funksionallıq dəsti ilə tam hüquqlu sınaq avtomatlaşdırma həllidir: uzaqdan giriş, qeydlər, ekran görüntüləri, video qeydlər, müxtəlif brauzerlər və fiziki mobil cihazlar. Bir çox hallarda bu, əsas qəşəng alternativ ola bilər. Sınaq platformaları, ictimai buludların yalnız Linux/Windows sistemlərini təklif edə bildiyi halda, xüsusilə IOS avtomatlaşdırılması üçün faydalıdır. Ancaq iOS haqqında növbəti məqalələrdə danışacağıq. Mən həmişə vəziyyətə baxmağı və tapşırıqlardan başlamağı tövsiyə edirəm: bəzi hallarda ictimai buludlardan istifadə etmək daha ucuz və səmərəlidir, digərlərində isə sınaq platformaları mütləq xərclənən pula dəyər.
İnfrastrukturun cari vəziyyətinin təsviri
Kəşf etmək üçün bağlantılar
Oxşar alətlər:
6. Orkestrləşmə
Texnologiyanın qısa təsviri
Yaxşı xəbərim var - demək olar ki, məqalənin sonundayıq! Hazırda bizim avtomatlaşdırma infrastrukturumuz veb və Android testlərindən ibarətdir ki, biz onları paralel olaraq GitLab CI vasitəsilə Docker-in aktivləşdirdiyi alətlərdən istifadə edirik: Selenium grid və Selenoid. Bundan əlavə, biz brauzerlər və emulyatorlarla konteynerləri yerləşdirmək üçün GCP vasitəsilə yaradılmış virtual maşınlardan istifadə edirik. Xərcləri azaltmaq üçün biz bu virtual maşınları yalnız tələb əsasında işə salırıq və sınaq aparılmadıqda onları dayandırırıq. İnfrastrukturumuzu yaxşılaşdıra biləcək başqa bir şey varmı? Cavab bəli! Kubernetes (K8s) ilə tanış olun!
Əvvəlcə orkestrasiya, klaster və Kubernetes sözlərinin bir-biri ilə necə əlaqəli olduğuna baxaq. Yüksək səviyyədə orkestrləşdirmə proqramları yerləşdirən və idarə edən sistemdir. Test avtomatlaşdırılması üçün belə konteynerləşdirilmiş proqramlar Selenium grid və Selenoiddir. Docker və K8-lər bir-birini tamamlayır. Birincisi tətbiqin yerləşdirilməsi üçün, ikincisi orkestr üçün istifadə olunur. Öz növbəsində, K8s bir çoxluqdur. Klasterin vəzifəsi bir server (klaster) daxilində müxtəlif funksionallıqları, proqramları və xidmətləri quraşdırmağa imkan verən VM-lərdən qovşaqlar kimi istifadə etməkdir. Qovşaqlardan hər hansı biri uğursuz olarsa, digər Qovşaqlar işə düşəcək, bu da tətbiqimizin fasiləsiz işləməsini təmin edir. Bundan əlavə, K8-lərin miqyası ilə bağlı vacib funksionallığı var, bunun sayəsində biz yükə və müəyyən edilmiş limitlərə əsasən optimal resurs miqdarını avtomatik əldə edirik.
Əslində, Kubernetes-i sıfırdan əl ilə yerləşdirmək heç də əhəmiyyətsiz bir iş deyil. Məşhur "Kubernetes The Hard Way" bələdçisinə bir keçid buraxacağam və maraqlanırsınızsa, təcrübə edə bilərsiniz. Ancaq xoşbəxtlikdən, alternativ üsullar və vasitələr var. Ən asan yol GCP-də Google Kubernetes Mühərrikindən (GKE) istifadə etməkdir ki, bu da bir neçə kliklə hazır klaster əldə etməyə imkan verəcək. Mən öyrənməyə başlamaq üçün bu yanaşmadan istifadə etməyi məsləhət görürəm, çünki bu, daxili komponentlərin bir-biri ilə necə inteqrasiya olunacağını öyrənmək əvəzinə, K8-lərdən tapşırıqlarınız üçün istifadə etməyi öyrənməyə diqqət yetirməyə imkan verəcək.
Avtomatlaşdırma infrastrukturu üçün dəyər
Gəlin K8-in təmin etdiyi bir neçə mühüm xüsusiyyətə nəzər salaq:
- tətbiqin yerləşdirilməsi: VM-lər əvəzinə çox qovşaqlı klasterdən istifadə;
- dinamik miqyas: yalnız tələbat əsasında istifadə olunan resursların dəyərini azaldır;
- özünü müalicə: podların avtomatik bərpası (nəticədə qablar da bərpa olunur);
- fasiləsiz yeniləmələrin yayılması və dəyişikliklərin geri qaytarılması: alətlərin, brauzerlərin və emulyatorların yenilənməsi cari istifadəçilərin işini dayandırmır
Ancaq K8s hələ də gümüş güllə deyil. Nəzərdən keçirdiyimiz alətlər (Selenium grid, Selenoid) kontekstində bütün üstünlükləri və məhdudiyyətləri başa düşmək üçün biz K8-lərin strukturunu qısaca müzakirə edəcəyik. Klasterdə iki növ qovşaq var: Əsas qovşaqlar və işçi qovşaqları. Master qovşaqları idarəetmə, yerləşdirmə və planlaşdırma qərarlarına cavabdehdir. İşçi qovşaqları proqramların işlədildiyi yerlərdir. Düyünlər həmçinin konteyner işləmə mühitini ehtiva edir. Bizim vəziyyətimizdə bu, konteynerlə əlaqəli əməliyyatlara cavabdeh olan Docker-dir. Ancaq məsələn, alternativ həllər də var. Ölçəkləmə və ya özünü müalicənin birbaşa konteynerlərə aid olmadığını başa düşmək vacibdir. Bu, öz növbəsində qabları ehtiva edən (adətən hər podda bir konteyner, lakin vəzifədən asılı olaraq daha çox ola bilər) olan podların sayını əlavə etmək/azaltmaqla həyata keçirilir. Yüksək səviyyəli iyerarxiya işçi qovşaqlarından ibarətdir, onların içərisində podlar var, içərisində qablar qaldırılır.
Ölçəkləmə xüsusiyyəti əsasdır və klaster node-pool daxilindəki hər iki qovşaqda və qovşaq daxilindəki qovşaqlarda tətbiq oluna bilər. Həm qovşaqlara, həm də podlara tətbiq olunan 2 növ miqyaslama var. Birinci növ üfüqidir - miqyaslama qovşaqların/podların sayını artırmaqla baş verir. Bu növə daha çox üstünlük verilir. İkinci növ, müvafiq olaraq, şaquli. Ölçəkləmə qovşaqların/podların sayını deyil, ölçüsünü artırmaqla həyata keçirilir.
İndi isə yuxarıdakı şərtlər kontekstində alətlərimizə nəzər salaq.
Selenium şəbəkəsi
Daha əvvəl qeyd edildiyi kimi, Selenium şəbəkəsi çox populyar bir vasitədir və onun konteynerə qoyulması təəccüblü deyil. Buna görə də, Selenium şəbəkəsinin K8-lərdə yerləşdirilə biləcəyi təəccüblü deyil. Bunun necə ediləcəyinə dair bir nümunə rəsmi K8s deposunda tapıla bilər. Həmişə olduğu kimi, bölmənin sonunda bağlantılar əlavə edirəm. Bundan əlavə, necə etmə təlimatı bunun Terraform-da necə ediləcəyini göstərir. Brauzer konteynerlərini ehtiva edən podların sayını necə ölçmək barədə təlimatlar da var. Lakin K8s kontekstində avtomatik miqyaslama funksiyası hələ də tamamilə açıq bir vəzifə deyil. Təhsil almağa başlayanda heç bir praktiki təlimat və ya tövsiyə tapmadım. DevOps komandasının dəstəyi ilə bir neçə araşdırma və təcrübədən sonra biz bir işçi qovşağının içərisində yerləşən bir pod daxilində lazımi brauzerlərlə konteynerlərin artırılması yanaşmasını seçdik. Bu üsul bizə onların sayını artırmaqla qovşaqların üfüqi miqyası strategiyasını tətbiq etməyə imkan verir. Ümid edirəm ki, bu, gələcəkdə dəyişəcək və biz xüsusilə dəyişdirilmiş daxili arxitektura ilə Selenium grid 4 buraxıldıqdan sonra daha yaxşı yanaşmaların və hazır həllərin daha çox təsvirini görəcəyik.
Selenoid:
K8-lərdə selenoid yerləşdirilməsi hazırda ən böyük xəyal qırıqlığıdır. Onlar uyğun deyil. Teorik olaraq, biz Selenoid konteynerini podun içərisində qaldıra bilərik, lakin Selenoid brauzerlərlə konteynerləri işə salmağa başlayanda onlar yenə də eyni podun içərisində olacaqlar. Bu, miqyaslaşdırmanı qeyri-mümkün edir və nəticədə klaster daxilində Selenoidin işi virtual maşındakı işdən fərqlənməyəcəkdir. Hekayənin sonu.
ay:
Selenoid ilə işləyərkən bu darboğazı bilən tərtibatçılar Moon adlı daha güclü alət buraxdılar. Bu alət əvvəlcə Kubernetes ilə işləmək üçün nəzərdə tutulmuşdu və nəticədə avtomatik miqyaslama funksiyası istifadə edilə bilər və istifadə edilməlidir. Üstəlik, mən deyərdim ki, hazırda belədir tək Selenium dünyasında yerli K8s klaster dəstəyi olan bir alət (artıq mövcud deyil, növbəti alətə baxın ). Bu dəstəyi təmin edən Ayın əsas xüsusiyyətləri bunlardır:
Tamamilə vətəndaşlığı olmayan. Selenoid yaddaşda hazırda işləyən brauzer seansları haqqında məlumat saxlayır. Əgər nədənsə onun prosesi çökürsə, onda bütün işləyən seanslar itirilir. Ayın əksinə olaraq daxili vəziyyəti yoxdur və məlumat mərkəzlərində təkrarlana bilər. Brauzer seansları bir və ya bir neçə replika azalsa belə canlı qalır.
Beləliklə, Ay əla bir həlldir, lakin bir problem var: pulsuz deyil. Qiymət seansların sayından asılıdır. Yalnız 0-4 seansı pulsuz işlədə bilərsiniz, bu xüsusilə faydalı deyil. Ancaq beşinci seansdan başlayaraq hər biri üçün 5 dollar ödəməli olacaqsınız. Vəziyyət şirkətdən şirkətə fərqli ola bilər, amma bizim vəziyyətimizdə Aydan istifadə etmək mənasızdır. Yuxarıda təsvir etdiyim kimi, biz tələb əsasında Selenium Grid ilə VM-ləri işlədə və ya klasterdəki qovşaqların sayını artıra bilərik. Təxminən bir boru kəməri üçün biz 500 brauzer işə salırıq və sınaqlar başa çatdıqdan sonra bütün resursları dayandırırıq. Aydan istifadə etsək, testləri nə qədər tez keçirsək də, ayda əlavə 500 x 5 = 2500 dollar ödəməli olacaqdıq. Yenə deyirəm ki, Aydan istifadə etməyin. Tapşırıqlarınız üçün bu, əvəzolunmaz həll ola bilər, məsələn, təşkilatınızda bir çox layihə/komandanız varsa və hamı üçün böyük ümumi klasterə ehtiyacınız varsa. Həmişə olduğu kimi, sonunda bir keçid buraxıram və tapşırığınızın kontekstində bütün lazımi hesablamaları etməyi məsləhət görürəm.
Callisto(Diqqət! Bu orijinal məqalədə deyil və yalnız rusca tərcümədə var)
Dediyim kimi, Selenium çox populyar bir vasitədir və İT sahəsi çox sürətlə inkişaf edir. Mən tərcümə üzərində işləyərkən internetdə Callisto adlı yeni perspektivli alət peyda oldu (salam Cypress və digər Selenium killers). O, yerli olaraq K8-lərlə işləyir və Selenoid qablarını qovşaqlarda paylanmış podlarda işlətməyə imkan verir. Avtomatik miqyaslama da daxil olmaqla hər şey qutudan kənarda işləyir. Fantastik, lakin sınaqdan keçirilməlidir. Mən artıq bu aləti yerləşdirməyi və bir neçə təcrübə keçirməyi bacarmışam. Ancaq uzun məsafədən nəticələr əldə etdikdən sonra nəticə çıxarmaq üçün hələ tezdir, bəlkə də gələcək məqalələrdə nəzərdən keçirəcəm. Hələlik mən yalnız müstəqil araşdırma üçün linklər buraxıram.
İnfrastrukturun cari vəziyyətinin təsviri
Kəşf etmək üçün bağlantılar
Oxşar alətlər
7. Kod olaraq İnfrastruktur (IaC)
Texnologiyanın qısa təsviri
İndi isə son hissəyə gəlirik. Tipik olaraq, bu texnologiya və əlaqəli vəzifələr avtomatlaşdırma mühəndislərinin məsuliyyəti deyil. Və bunun səbəbləri var. Birincisi, bir çox təşkilatlarda infrastruktur məsələləri DevOps departamentinin nəzarəti altındadır və inkişaf qrupları boru kəmərinin nəyin işləməsinə və onunla əlaqəli hər şeyin necə dəstəklənməsinə əhəmiyyət vermirlər. İkincisi, düzünü desək, bir çox şirkətlərdə İnfrastruktur kimi Kodeks (IaC) təcrübəsi hələ də qəbul edilməyib. Ancaq bu, mütləq populyar bir tendensiyaya çevrildi və onunla əlaqəli proseslərdə, yanaşmalarda və alətlərdə iştirak etməyə çalışmaq vacibdir. Və ya heç olmasa yeniliklərdən xəbərdar olun.
Bu yanaşmadan istifadə etmək üçün motivasiyadan başlayaq. GitlabCI-də testlər aparmaq üçün Gitlab Runner-ı işə salmaq üçün ən azı resursa ehtiyac duyacağımızı artıq müzakirə etdik. Brauzerlər/emulatorlar ilə konteynerləri işə salmaq üçün biz VM və ya klaster rezerv etməliyik. Resursları sınamaqdan əlavə, inkişaf, mərhələlər, istehsal mühitlərini dəstəkləmək üçün əhəmiyyətli bir qabiliyyətə ehtiyacımız var ki, bu da verilənlər bazası, avtomatik cədvəllər, şəbəkə konfiqurasiyaları, yük balanslaşdırıcıları, istifadəçi hüquqları və s. daxildir. Əsas məsələ bütün bunları dəstəkləmək üçün lazım olan səydir. Dəyişikliklər etmək və yeniləmələri yaymaq üçün bir neçə yol var. Məsələn, GCP kontekstində biz brauzerdə UI konsolundan istifadə edə və düymələrə basaraq bütün hərəkətləri yerinə yetirə bilərik. Alternativ olaraq, bulud obyektləri ilə qarşılıqlı əlaqə yaratmaq üçün API zənglərindən istifadə etmək və ya istədiyiniz manipulyasiyaları yerinə yetirmək üçün gcloud komanda xətti yardım proqramından istifadə etmək olar. Lakin həqiqətən çox sayda müxtəlif qurumlar və infrastruktur elementləri ilə bütün əməliyyatları əl ilə yerinə yetirmək çətinləşir və ya hətta qeyri-mümkün olur. Üstəlik, bütün bu əl hərəkətləri idarəolunmazdır. Biz onları icradan əvvəl nəzərdən keçirmək üçün təqdim edə, versiyaya nəzarət sistemindən istifadə edə və insidentə səbəb olan dəyişiklikləri tez geri qaytara bilmərik. Bu cür problemləri həll etmək üçün mühəndislər əvvəlki metodlardan çox da yaxşı olmayan avtomatik bash/shell skriptləri yaratdılar və yaradırlar, çünki onları tez oxumaq, başa düşmək, saxlamaq və prosedur üslubunda dəyişdirmək o qədər də asan deyil.
Bu məqalədə və təlimatda mən IaC təcrübəsi ilə bağlı 2 alətdən istifadə edirəm. Bunlar Terraform və Ansible. Bəzi insanlar eyni vaxtda istifadə etməyin mənasız olduğuna inanırlar, çünki onların funksionallığı oxşardır və bir-birini əvəz edir. Ancaq fakt budur ki, əvvəlcə onlara tamamilə fərqli tapşırıqlar verilir. Və bu vasitələrin bir-birini tamamlamalı olması HashiCorp və RedHat-ı təmsil edən tərtibatçıların birgə təqdimatında təsdiqləndi. Konseptual fərq ondan ibarətdir ki, Terraform serverlərin özlərini idarə etmək üçün təchizat vasitəsidir. Ansible, vəzifəsi bu serverlərdə proqram təminatı quraşdırmaq, konfiqurasiya etmək və idarə etmək olan konfiqurasiya idarəetmə vasitəsi olsa da.
Bu vasitələrin digər əsas fərqləndirici xüsusiyyəti kodlaşdırma tərzidir. Bash və Ansible-dan fərqli olaraq, Terraform icra nəticəsində əldə ediləcək arzu olunan son vəziyyətin təsvirinə əsaslanan deklarativ üslubdan istifadə edir. Məsələn, 10 VM yaratmaq və dəyişiklikləri Terraform vasitəsilə tətbiq etmək niyyətindəyiksə, onda 10 VM alacağıq. Skripti yenidən işə salsaq, artıq 10 VM-miz olduğundan heç nə baş verməyəcək və Terraform infrastrukturun cari vəziyyətini dövlət faylında saxladığı üçün bu barədə məlumatlıdır. Lakin Ansible prosessual yanaşmadan istifadə edir və ondan 10 VM yaratmağı xahiş etsəniz, ilk buraxılışda biz Terraforma bənzər 10 VM alacağıq. Ancaq yenidən başladıqdan sonra artıq 20 VM-imiz olacaq. Bu mühüm fərqdir. Prosedur üslubunda biz cari vəziyyəti saxlamırıq və sadəcə yerinə yetirilməli olan addımlar ardıcıllığını təsvir edirik. Əlbəttə ki, biz müxtəlif vəziyyətlərin öhdəsindən gələ bilərik, resursların mövcudluğu və mövcud vəziyyət üçün bir neçə yoxlama əlavə edə bilərik, lakin bu məntiqi idarə etmək üçün vaxt itirməyin və səy göstərməyin mənası yoxdur. Bundan əlavə, bu, səhv etmək riskini artırır.
Yuxarıda göstərilənlərin hamısını ümumiləşdirərək belə bir nəticəyə gələ bilərik ki, Terraform və deklarativ notasiya serverləri təmin etmək üçün daha uyğun vasitədir. Ancaq konfiqurasiya idarəetmə işini Ansible-a həvalə etmək daha yaxşıdır. Bunu aradan qaldıraraq, avtomatlaşdırma kontekstində istifadə hallarına baxaq.
Avtomatlaşdırma infrastrukturu üçün dəyər
Burada başa düşmək lazım olan yeganə vacib şey odur ki, sınaq avtomatlaşdırma infrastrukturu bütün şirkət infrastrukturunun bir hissəsi kimi qəbul edilməlidir. Bu o deməkdir ki, bütün IaC təcrübələri bütün təşkilatın resurslarına qlobal şəkildə tətbiq edilməlidir. Buna kimin cavabdeh olması proseslərinizdən asılıdır. DevOps komandası bu məsələlərdə daha təcrübəlidir, onlar baş verənlərin bütün mənzərəsini görürlər. Bununla belə, QA mühəndisləri binanın avtomatlaşdırılması prosesində və boru kəmərinin strukturunda daha çox iştirak edirlər ki, bu da onlara bütün tələb olunan dəyişiklikləri və təkmilləşdirmə imkanlarını daha yaxşı görməyə imkan verir. Ən yaxşı variant gözlənilən nəticəyə nail olmaq üçün birgə işləmək, bilik və fikir mübadiləsi aparmaqdır.
Test avtomatlaşdırılması kontekstində Terraform və Ansible istifadəsinə dair bir neçə nümunə və əvvəllər müzakirə etdiyimiz alətlər:
1. Terraform-dan istifadə edərək VM-lərin və klasterlərin lazımi xarakteristikalarını və parametrlərini təsvir edin.
2. Ansible istifadə edərək, sınaq üçün lazım olan alətləri quraşdırın: docker, Selenoid, Selenium Grid və brauzerlərin/emulatorların tələb olunan versiyalarını yükləyin.
3. Terraform istifadə edərək, GitLab Runner-ın işə salınacağı VM-nin xüsusiyyətlərini təsvir edin.
4. Ansible istifadə edərək GitLab Runner və lazımi müşayiətedici alətləri quraşdırın, parametrləri və konfiqurasiyaları təyin edin.
İnfrastrukturun cari vəziyyətinin təsviri
Kəşf etmək üçün bağlantılar:
Oxşar alətlər
Gəlin yekunlaşdıraq!
Addım
Texnologiya
Tools
Avtomatlaşdırma infrastrukturu üçün dəyər
1
Yerli qaçış
Node.js, Selenium, Appium
- Veb və mobil üçün ən populyar alətlər
- Bir çox dilləri və platformaları dəstəkləyir (Node.js daxil olmaqla)
2
Versiya nəzarət sistemləri
get
- İnkişaf kodu ilə oxşar faydalar
3
Konteynerləşmə
Docker, Selenium grid, Selenoid (Veb, Android)
- Testlərin paralel olaraq aparılması
- İzolyasiya edilmiş mühitlər
- Sadə, çevik versiya təkmilləşdirmələri
- İstifadə edilməmiş resursların dinamik şəkildə dayandırılması
- Qurmaq asandır
4
CI/CD
Gitlab CI
- Boru kəmərinin bir hissəsini sınaqdan keçirir
- Tez Əlaqə
- Bütün şirkət/komanda üçün görünürlük
5
Bulud platformaları
Google Cloud Platform
- Tələb olunan mənbələr (yalnız lazım olduqda ödəyirik)
- İdarə etmək və yeniləmək asandır
- Bütün resursların görünməsi və nəzarəti
6
Orkestr
Kubernetes
Podların içərisində brauzerlər/emulatorlar olan konteynerlər kontekstində:
- Ölçəkləmə/avtomatik miqyaslama
- Öz-özünə müalicə
- Fasiləsiz yeniləmələr və geri dönmələr
7
Kod kimi infrastruktur (IaC)
Terraform, Ansible
- İnkişaf infrastrukturu ilə oxşar faydalar
- Kod versiyasının bütün üstünlükləri
- Dəyişiklik etmək və saxlamaq asandır
- Tam avtomatlaşdırılmışdır
Ağıl xəritəsi diaqramları: infrastrukturun təkamülü
Addım 1: Yerli
addım 2: VCS
3-cü addım: Konteynerləşdirmə
4-cü addım: CI/CD
5-ci addım: Bulud platformaları
6-cı addım: Orkestr
addım7: IaC
Növbəti nədir?
Beləliklə, məqalənin sonu budur. Amma sonda mən sizinlə bəzi müqavilələr bağlamaq istərdim.
Sizin tərəfdən
Əvvəldə dediyim kimi, istərdim ki, məqalə praktiki cəhətdən faydalı olsun və əldə olunan bilikləri real işdə tətbiq etməkdə sizə yardımçı olsun. yenə əlavə edirəm.
Ancaq bundan sonra da dayanmayın, məşq edin, müvafiq linkləri və kitabları öyrənin, onun şirkətinizdə necə işlədiyini öyrənin, təkmilləşdirilə bilən yerləri tapın və orada iştirak edin. Uğurlar!
Mənim tərəfdən
Başlıqdan aydın olur ki, bu, yalnız birinci hissə idi. Kifayət qədər böyük olmasına baxmayaraq, burada hələ də vacib mövzular işıqlandırılmır. İkinci hissədə IOS kontekstində avtomatlaşdırma infrastrukturuna baxmağı planlaşdırıram. Apple-ın iOS simulyatorlarının yalnız macOS sistemlərində işləməsinə qoyduğu məhdudiyyətlər səbəbindən həllər çeşidimiz daralır. Məsələn, biz simulyatoru idarə etmək üçün Docker-dən və ya virtual maşınları işə salmaq üçün ictimai buludlardan istifadə edə bilmirik. Amma bu o demək deyil ki, başqa alternativlər yoxdur. Sizi qabaqcıl həllər və müasir alətlərlə xəbərdar etməyə çalışacağam!
Həm də monitorinqlə bağlı kifayət qədər böyük mövzuları qeyd etməmişəm. 3-cü hissədə mən ən populyar infrastruktur monitorinq alətlərinə və hansı data və ölçülərə diqqət yetirməliyəm.
Və nəhayət. Gələcəkdə test infrastrukturu və populyar alətlərin qurulması ilə bağlı video kurs buraxmağı planlaşdırıram. Hal-hazırda İnternetdə DevOps ilə bağlı kifayət qədər kurslar və mühazirələr var, lakin bütün materiallar test avtomatlaşdırılması deyil, inkişaf kontekstində təqdim olunur. Bu mövzuda, həqiqətən, belə bir kursun sınaqçılar və avtomatlaşdırma mühəndisləri icması üçün maraqlı və dəyərli olub-olmayacağı ilə bağlı rəyə ehtiyacım var. Əvvəlcədən təşəkkürlər!
Mənbə: www.habr.com