Hissə 1: Web / Android
Qeyd: bu məqalə orijinal məqalənin rus dilinə tərcüməsidir Ancaq bütün illüstrasiyalar, bağlantılar, citatlar və anlayışlar orijinal dildə saxlanır ki, rus dilinə tərcümədə mənanın pozulmasının qarşısı alınsın. Sizə müsbət öyrənmə arzulayıram!
Hazırda DevOps peşəsi IT sənayesində ən çox tələb olunanlardan biridir. Əgər məşhur iş axtarış saytlarını açsanız və maaşlar üzrə filtr tətbiq etsəniz, DevOps ilə əlaqəli iş elanlarının siyahının əvvəlində olduğunu görərsiniz. Ancaq bu, əsasən, 'Senior' vəzifələrinə aiddir ki, bu da namizədin yüksək bacarıq səviyyəsinə, texnologiyalara və alətlərə dair biliklərə sahib olduğunu göstərir. Bununla da, istehsal işinin dayanıqlığı ilə bağlı yüksək dərəcədə məsuliyyət gəlir. Ancaq DevOps-un nə olduğunu unuduruq. Başlangıcda, bu, spesifik bir şəxs və ya departament deyildi. Bu terminə baxdıqda, metodologiya, praktika, mədəniyyət fəlsəfəsi, konseptlər qrupu və s. kimi bir çox gözəl və düzgün isimlər tapacağıq.
Mənim ixtisasım – test avtomatlaşdırma mühəndisi (QA automation engineer), amma hesab edirəm ki, bu yalnız avtomatik testlərin yazılması və test framework-in arxitekturaya yaradılması ilə bağlı olmamalıdır. 2020-ci ildə avtomatlaşdırma infrastrukturunu bilmək də vacibdir. Bu, testlərin icrasından başlayaraq, nəticələrin bütün maraqlı tərəflərə təqdim olunması kimi avtomatlaşdırma prosesini özbaşına təşkil etməyə imkan verir. Nəticədə, DevOps bacarıqları bu işin yerinə yetirilməsi üçün mühüm amildir. Və bütün bunlar yaxşıdır, amma təəssüf ki, bir problem var (spoiler: bu məqalə bu problemi sadələşdirməyə cəhd edir). Problem ondadır ki, DevOps çətindir. Və bu aydındır, çünki şirkətlər asanlıqla edilə bilən şeylər üçün çox pul ödəməyəcək... DevOps dünyasında öyrənilməli olan çox sayda alət, termin və praktika var. Xüsusilə bu, kariyeranın başlanğıcında çətin olur və toplanmış texniki təcrübədən asılıdır.
Mənbə:
Burada giriş hissəsi ilə tamamlayırıq və bu məqalənin məqsədinə diqqət yetiririk.
Bu məqalə nədən bəhs edir
Bu məqalədə mən test avtomatlaşdırma infrastrukturunu qurma təcrübəmi bölüşmək istəyirəm. İnternetdə müxtəlif alətlər və onların necə istifadə olunacağı barədə çox sayda məlumat mənbəyi tapa bilərik, lakin mən onları yalnız avtomatlaşdırma kontekstində nəzərə almaq istəyirəm. Düşünürəm ki, avtomatlaşdırma mühəndislərinin əksəriyyəti, hazırlandığı testlərin heç kimin, sadəcə özləri istisna olmaqla, işə salmadığı və onların dəstəklənməsiylə maraqlanmadığı situasiyaya aşina olublar. Nəticədə, testlər köhnəlir və onları aktual vəziyyətə gətirmək üçün vaxt sərf etməli oluruq. Yenə də, karyeranın əvvəlində bu, düzgün alətlərin seçilməsi, konfiqurasiya edilməsi və saxlanılması ilə bağlı çətin bir vəzifə ola bilər. Bəzi testçilər DevOps (insanlar) tərəfindən kömək almağı seçirlər və dürüst olaq, bu yanaşma çox vaxt işləyir. Bir çox halda bu, yeganə variantımızdır, çünki bütün asılılıqları görə bilmirik. Lakin bildiyimiz kimi, DevOps çox məşğuldur. Onlar şirkətin tam infrastrukturunu, yerləşdirməni, monitorinqi, mikroservisləri və təşkilat/qrupun digər oxşar tapşırıqlarını düşünməlidirlər. Adətən, avtomatlaşdırma prioritet deyil. Beləliklə, mümkün olan hər şeyi bir başdan sona qədər etməyə çalışmalıyıq. Bu, asılılıqları azaldacaq, iş axını sürətləndirəcək, bacarıqlarımızı inkişaf etdirəcək və baş verənlərin daha geniş mənzərəsini görmə imkanı verəcək.
Məqalədə ən tələbatlı və məşhur alətlər təqdim olunur və onların addım-addım avtomatlaşdırma infrastrukturunun qurulmasında necə istifadə oluna biləcəyi göstərilir. Hər qrup, şəxsi təcrübəmdən təsdiqlənmiş alətlərlə təqdim olunur. Lakin bu, eyni alətləri istifadə etməli olduğunuz demək deyil. Alətlərin özləri əhəmiyyət daşımıyır, onlar meydana gəlir və köhnəlir. Bizim mühəndislik vəzifəmiz, bu alətlərin qrupuna niyə ehtiyac duyduğumuzu və onlarla hansı iş tapşırıqlarını həll edə biləcəyimizi başa düşməkdir. Buna görə də, hər bir bölmənin sonunda, bəlkə təşkilatınızda istifadə olunan oxşar alətlərə linklər qoyuram.
Bu məqalədə olmayan şeylər
Yenidən vurğulayıram ki, məqalə spesifik alətlər haqqında deyil, buna görə də burada sənədlərdən kod parçaları və konkret komandaların təsviri olmayacaq. Lakin, hər bir bölmənin sonunda daha ətraflı öyrənmək üçün linklər qoyuram.
Bu, aşağıdakı səbəblərə görə edilir:
- bu material müxtəlif mənbələrdə (sənədlər, kitablar, video kurslar) çox asanlıqla tapıla bilər;
- əgər biz dərinə getsək, bu məqalənin 10, 20, 30 hissəsini yazmalıyıq (halbuki bizim planlarımızda 2-3 var);
- Sadəcə sizin vaxtınızı itirmək istəmirəm, çünki ehtimal ki, eyni məqsədlərə çatmaq üçün başqa alətlərdən istifadə etmək istəyirsiniz.
Təcrübə
Bu materialın hər bir oxucu üçün faydalı olmasını, sadəcə oxunub unudulmasını çox istərdim. Hər bir öyrənmədə praktika çox önəmli bir komponentdir. Bunun üçün mən hazırladım. Həmçinin, sizləri icra olunan əmrlərin xətasız kopyalanmadığını təmin etmək üçün ev tapşırığı gözləyir.
Plan
Addım
Texnologiya
Alatlar
1
Yerli işləmə (vеб / android demo testlərini hazırlayıb yerli işlədin)
Node.js, Selenium, Appium
2
Versiya nəzarət sistemləri
Git
3
Konteynerləşdirmə
Docker, Selenium grid, Selenoid (Web, Android)
4
CI / CD
Gitlab CI
5
Bulud platformaları
Google Cloud Platform
6
Orkestrasiya
Kubernetes
7
Infrastruktur şifrə olaraq (IaC)
Terraform, Ansible
Hər bir bölmənin strukturu
Naratvaziyyəti vizual saxlamaq üçün, hər bir bölmə aşağıdakı plana əsasən təsvir ediləcək:
- texnologiyanın qısa təsviri,
- avtomatlaşdırma infrastrukturu üçün dəyəri,
- infrastrukturun cari vəziyyətinin təsviri,
- öyrənməyə dair linklər,
- oxşar alətlər.
1. Testlərin yerli başlanğıcı
Texnologiyanın qısa təsviri
Bu, sadəcə yerli işlədilən demo testləri başlamaq və onların uğurla keçdiyini yoxlamaq üçün hazırlıq addımıdır. Praktiki hissədə Node.js istifadə olunur, lakin proqramlaşdırma dili və platforma da önəmli deyil, şirkətinizdə istifadə olunanları seçə bilərsiniz.
Ancaq avtomatlaşdırma alətləri olaraq web platformaları üçün Selenium WebDriver və Android platforması üçün Appium istifadə etməyi tövsiyə edirəm, çünki növbəti addımlarda konkret olaraq bu alətlərlə işləməyə uyğun Docker görüntülərini istifadə edəcəyik. Bundan əlavə, iş elanlarında tələblərə baxdığınız zaman, bu alətlər bazarda ən çox tələb olunanlardır.
Qeyd etdiyiniz kimi, yalnız web və Android testlərini nəzərdən keçiririk. Təəssüf ki, IOS - tamamilə fərqli bir hekayədir (Apple'a təşəkkürlər). IOS ilə bağlı həlləri və praktikaları növbəti bölmələrdə nümayiş etdirməyi planlayıram.
Avtomatlaşdırma infrastrukturu üçün dəyəri
İnfrastruktur nöqteyi-nəzərdən, yerli işə başlamağın heç bir dəyəri yoxdur. Siz yalnız testlərin yerli maşında yerli brauzerlərdə və simulatorlarda işlədiyini yoxlayırsınız. Amma bu, mütləq zəruri bir başlanğıç nöqtəsidir.
İnfrastrukturun cari vəziyyətinin təsviri
Öyrənməyə dair linklər
Oxşar alətlər
- istədiyiniz hər hansı bir proqramlaşdırma dili, Selenium/Appium testləri ilə birlikdə;
- hər hansı test;
- hər hansı test-işçi.
2. Versiya nəzarət sistemləri (Git)
Texnologiyanın qısa təsviri
Bir çoxları üçün, versiya idarəetmə sisteminin komanda ilə və fərdi işləmə prosesində olduqca vacib olduğunu demək böyük bir kəşf olmayacaq. Müxtəlif mənbələrə istinad edərək, əminliklə demək mümkündür ki, Git ən populyar nümayəndədir. Versiya idarəetmə sistemi kod mübadiləsi, versiyaların saxlanması, əvvəlki budaqlara bərpa, layihə tarixi izləmi və ehtiyat nüsxələri kimi bir çox üstünlüklər təqdim edir. Hər bir nöqtəni detallı şəkildə müzakirə etməyəcəyik, çünki bununla yaxşı tanış olduğunuzu və gündəlik işinizdə istifadə etdiyinizi əminliklə deyə bilərəm. Ancaq əgər hələ tanış deyilsinizsə, bu məqaləni oxumağı dayandırmağı və mümkün qədər tez bu boşluğu doldurmağı tövsiyə edirəm.
Avtomatlaşdırma infrastrukturu üçün dəyəri
Burada siz rasional bir sual verə bilərsiniz: "Niyə o, bizə Git-dən danışır? Bunu hər kəs bilir və həm kod yazma, həm də avtomatlaşdırma testləri üçün istifadə edir." Tamamilə haqlısınız, amma bu məqalədə biz infrastrukturdan danışılanda bu bölmə 7-ci bölüm olan "İnfrastruktur kodu kimi (IaC)" üçün bir önizləmə rolunu oynayır. Bizim üçün bu, bütün infrastrukturun, o cümlədən test infrastrukturunun, kod şəklində təsvir edilməsi deməkdir, buna görə də biz versiya idarəetmə sistemlərini ona tətbiq edə bilərik və kod yazma və avtomatlaşdırma ilə oxşar faydalar əldə edə bilərik.
IaC-ni daha ətraflı 7-ci mərhələdə müzakirə edəcəyik, amma indidən Git-i lokal olaraq istifadə etməyə başlamaq mümkündür, bir lokal depo yaratmaqla. Ümumi mənzərə, infrastrukturumuz üçün uzaq bir depo əlavə etdikdə genişlənəcək.
İnfrastrukturun cari vəziyyətinin təsviri
Öyrənməyə dair linklər
Oxşar alətlər
3. Konteynerləşdirmə (Docker)
Texnologiyanın qısa təsviri
Konteynerləşdirmənin necə oyun dəyişdirdiyini göstərmək üçün gəlin bir neçə onillik əvvələ səyahət edək. O dövrlərdə insanlar tətbiqləri işə salmaq üçün server maşınları alırdılar. Lakin əksər hallarda, işə salmaq üçün lazım olan 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əyirdilər, lakin bu gücün bir hissəsi tamamilə istifadə olunmadı.
Təkmilləşmənin növbəti mərhələsi virtual maşınlar (VM) oldu ki, bu da istifadə edilməyən resurslara xərclənən vəsaiti aradan qaldırdı. Bu texnologiya tətbiqlərin bir server daxilində bir-birindən müstəqil işə salınmasına imkan verdi, tamamilə izolyasiya olunmuş bir mühit ayıraraq. Lakin, təəssüf ki, hər bir texnologiyanın öz çatışmazlıqları var. VM-lərin işə salınması tam əməliyyat sistemi tələb edir ki, bu da CPU, RAM, saxlama istifadə edir və, əməliyyat sistemindən asılı olaraq, lisenziya xərclərini nəzərə almaq lazımdır. Bu amillər yükləmə sürətinə təsir edir və portativliyi çətinləşdirir.
Və beləliklə, konteynerləşməyə gəlib çatdıq. Bu texnologiya əvvəlki problemi yenidən həll etdi, çünki konteynerlər tam OS istifadə etmir, bu da bir çox resursu sərbəst buraxır və daşınma üçün sürətli və çevik bir həll təqdim edir.
Əlbəttə, konteynerləşmə texnologiyası yeni bir şey deyil və ilk dəfə 70-ci illərin sonunda təqdim edilib. O dövrdə çoxlu tədqiqatlar, işlər və cəhdlər aparılırdı. Lakin məhz Docker bu texnologiyanı uyğunlaşdırdı və onu kütlə üçün əlçatan etdi. Bu gün konteynerlərdən danışarkən, əksər hallarda Dockerı nəzərdə tuturuq. Docker konteynerlərindən danışdıqda, Linux konteynerlərini nəzərdə tuturuq. Konteynerləri işlətmək üçün Windows və macOS sistemlərindən istifadə edə bilərik, lakin bu halda əlavə bir qatın meydana çıxacağını başa düşmək vacibdir. Məsələn, Docker Mac-də konteynerləri məlum olmayan bir yolla yüngül bir Linux VM içində işə salır. Bu mövzuya qayıdacağıq, çünki konteynerlər içərisində Android emulatorlarını çalışdırarkən çox vacib bir incəlik meydana çıxır ki, onu daha ətraflı müzakirə etmək lazımdır.
Avtomatlaşdırma infrastrukturu üçün dəyəri
Konteynerləşmənin və Dockerın möhtəşəm olduğunu anladıq. Gəlin bunu avtomatlaşdırma kontekstində nəzərdən keçirək, çünki hər bir alət və ya texnologiya hansısa bir problemi həll etməlidir. UI testləri kontekstində avtomatlaşdırma testlərinin açıq-aşkar problemlərini müəyyənləşdirək:
- Seleniumun və xüsusilə Appiumun quraşdırılmasında çoxlu asılılıqlar;
- Brauzer versiyaları, simulatorlar və sürücülər arasında uyğunluq problemləri;
- Brauzerlər/simulatorlar üçün izolyasiya olunmuş bir məkanın olmaması, bu da paralel işləyişi üçün xüsusilə kritikdir;
- Eyni anda 10, 50, 100 və ya hətta 1000 brauzeri işə salmaq lazım olduqda idarə etmək və dəstəkləmək çətindir.
Amma Selenium ən populyar avtomatlaşdırma aləti olduğu üçün və Docker ən populyar konteynerləşmə aləti olduğuna görə, kimsə onların birləşməsini cəhd etməyəcək? Əvvəlcə qeyd edilən problemləri həll etmək üçün güclü bir alət əldə etmək məqsədilə. Belə həlləri daha ətraflı nəzərdən keçirək.
Docker-da Selenium grid
Bu alət, bir mərkəzi düyündən çoxlu brauzerləri bir neçə maşında işə salmaq və onlara nəzarət etmək üçün dünyanın ən populyar Selenium alətidir. İşə salmaq üçün ən azı 2 hissənin qeydiyyatdan keçirilməsi tələb olunur: Hub və Node(s). Hub, testlərdən alınan bütün sorğuları alaraq müvafiq Nodes-a paylayan mərkəzi düyündür. Hər bir Node üçün konkret konfiqurasiya qura bilirik, məsələn, lazım olan brauzeri və onun versiyasını göstərərək. Lakin, biz həmçinin bəzi uyğun brauzer sürücüləri ilə özümüz təmin etməliyik və onları müvafiq Nodes-a quraşdırmalıyıq. Buna görə Selenium grid, yalnız Linux OS-da quraşdırmaq mümkün olmayan brauzerlərlə işləməli olduqda, saf formada istifadə edilmir. Qalan bütün hallarda, Selenium grid Hub və Nodes-u işə salmaq üçün Docker imiclərinin istifadəsi daha çevik və düzgün bir həll olacaq. Bu yanaşma düyünlərin idarə olunmasını xeyli asanlaşdırır, çünki biz artıq quraşdırılmış uyğun brauzer və sürücü versiyaları olan lazım olan imici seçə bilərik.
Böyük sayda Nodes-un paralel işə salınması zamanı, xüsusilə sabitliklə bağlı mənfi rəy olsa da, Selenium grid hələ də Selenium testlərinin paralel işə salınması üçün ən populyar alət olaraq qalır. Qeyd etmək vacibdir ki, open-source-da bu alətin müxtəlif dar boğazlarla mübarizə aparan bir çox düzəlişlər və modifikasiyalar davamlı olaraq yaranır.
Web üçün Selenoid
Bu alət, Selenium dünyasında inqilabdır, çünki o, birbaşa paketi içində işləyir və bir çox avtomatlaşdırma mühəndisinin həyatını əhəmiyyətli dərəcədə asanlaşdırıb. Hər şeydən əvvəl, bu Selenium grid-in başqa bir modifikasiyası deyil. Bunun əvəzinə, inkişaf etdiricilər Golang dilində Selenium Hub-un tamamilə yeni versiyasını yaratdılar ki, bu da yüngül Docker imicləri ilə birgə müxtəlif brauzerlər üçün avtomatik test etmə inkişafına təkan verdi. Daha da önəmlisi, Selenium Grid-də biz bütün tələb olunan brauzerləri və onların versiyalarını əvvəldən müəyyənləşdirməliyik ki, bu da tək bir brauzer ilə işləyərkən problem deyil. Lakin bir neçə dəstəklənən brauzer barədə danışarkən, Selenoid 'tələbə uyğun brauzer' xüsusiyyəti sayəsində bir nömrəli həldir. Bizdən tələb olunan tək şey, lazım olan imicləri əvvəlcədən yükləmək və Selenoid-in qarşılıqlı təsir etdiyi konfiqurasiya faylını güncəlləməkdir. Selenoid testlərdən sorğunu aldıqdan sonra, müvafiq brauzer ilə konteyneri avtomatik olaraq işə salacaq. Test başa çatdıqdan sonra, Selenoid konteyneri bırakıb, növbəti sorğular üçün resursları azad edəcək. Bu yanaşma 'düyünlərin deqradasiyası' adlı tanınmış problemi tamamilə aradan qaldırır ki, biz bunu tez-tez Selenium grid-də rastlayırıq.
Amma, təəssüf ki, Selenoid hələ də möcüzəvi bir həll deyil. Biz "istəyə əsaslanan brauzer" funksiyasını əldə etdik, lakin "istəyə əsaslanan resurslar" funksiyası hələ də mövcud deyil. Selenoidi istifadə etmək üçün onu fiziki avadanlıqda və ya VM-də yerləşdirməliyik, bu da bizdən lazım olan resursları əvvəlcədən bilməyimizi tələb edir. Məncə, bu kiçik layihələr üçün problem deyil ki, 10, 20 və ya hətta 30 brauzeri eyni anda işə salır. Amma ya 100, 500, 1000 və ya daha çoxuna ehtiyacımız olarsa? Belə bir resursu daimi olaraq dəstəkləmək və ödəniş etmək mənasızdır. Bu məqalənin 5 və 6-cı bölməsində biz şirkətlərin xərclərini əhəmiyyətli dərəcədə azaldaraq ölçülməyə imkan verən həlləri müzakirə edəcəyik.
Selenoid Android üçün
Web avtomatlaşdırma aləti kimi Selenoidin uğurundan sonra, insanlar Android üçün oxşar bir şey əldə etmək istəyirdilər. Və bu baş verdi - Selenoid Android dəstəyi ilə buraxıldı. Yüksək səviyyəli istifadəçi nöqtəsindən yanaşdıqda, iş prinsipi web avtomatlaşdırması ilə eynidir. Tək fərq odur ki, Selenoid brauzer konteynerləri əvəzinə Android emulyatorlarından ibarət konteynerlər işə salır. Mənim fikrimcə, bu günə qədər Android testlərini paralel olaraq həyata keçirmək üçün ən güclü pulsuz alətdir.
Mən bu alətin neqativ tərəflərini müzakirə etmək istəmirəm, çünki bu mənim üçün çox yaxşıdır. Lakin burada eyni zamanda web avtomatlaşdırması ilə bağlı olan və ölçülmə ilə əlaqəli eyni çatışmazlıqlar var. Bununla yanaşı, aləti ilk dəfə konfiqurasiya edəndə gözlənilməz ola biləcək bir məhdudiyyətdən də bəhs etməliyik. Android görüntülərini işə salmaq üçün bizim fiziki bir maşın və ya nested virtualizasiya dəstəyi olan bir VM lazımdır. Praktik rəhbərlikdə Linux VM-də bunu necə aktivləşdirəcəyimi nümayiş etdirirəm. Ancaq siz macOS istifadəçisisinizsə və Selenoidi yerli olaraq qurmaq istəyirsinizsə, Android testlərini işə salmaq mümkün olmayacaq. Lakin hər zaman nested virtualizasiya ilə konfiqurasiya olunmuş bir Linux VM-i yerli olaraq işə sala və Selenoidi içində qura bilərsiniz.
İnfrastrukturun cari vəziyyətinin təsviri
Bu məqalənin kontekstində infrastrukturun izahı üçün 2 alət əlavə edəcəyik. Bu, web testləri üçün Selenium grid və Android testləri üçün Selenoiddir. GitHub-da Selenoidi web testlərini işə salmaq üçün necə istifadə edəcəyimi də göstərəcəyəm.
Öyrənməyə dair linklər
Oxşar alətlər
- Başqa konteyner alətləri də mövcuddur, lakin Docker - ən populyar. Əgər başqa bir şey sınamaq istəyirsinizsə, unutmayın ki, paralel Selenium testlərini işə salmaq üçün müzakirə etdiyimiz alətlər qutudan çıxarılmadan işləmir.
- Artıq qeyd edildiyi kimi, Selenium grid-in bir çox modifikasiyası var, məsələn,.
4. CI / CD
Texnologiyanın qısa təsviri
Davamlı inteqrasiya praktikası proqram inkişafında olduqca populyardır və versiya idarəetmə sistemləri ilə eyni sıradadır. Buna baxmayaraq, terminologiyada qarışıqlıq olduğunu hiss edirəm. Bu paraqrafda, bu texnologiyanın 3 modifikasiyasını öz nöqteyi-nəzərimdən izah etmək istəyirəm. İnternetdə müxtəlif şərhlər olan çoxsaylı məqalələr tapacaqsınız və əgər sizin fikiriniz fərqlidirsə, bu tamamilə normaldır. Əsas odur ki, siz həmkarlarınızla eyni dalğada olasınız.
Beləliklə, 3 termin var: CI — Davamlı İntegrasiya (Continuous Integration), CD — Davamlı Təslimat (Continuous Delivery) və yenidən CD — Davamlı İcra (Continuous Deployment). (Daha sonra bu terminləri ingilis dilində istifadə edəcəyəm). Hər bir modifikasiya inkişafınızın konveyerinə bir neçə əlavə mərhələ əlavə edir. Lakin continuous (davamlı) ən əsas sözüdür. Bu kontekstdə, kesilmə və ya əl ilə müdaxilə olmadan, başlanğıcdan sona qədər baş verən bir şeyi anlayırıq. Gəlin bu kontekstdə CI & CD və CD-yə nəzər salaq.
- Davamlı İntegrasiya - inkişafın başlanğıc addımıdır. Yeni kod serverə göndərildikdən sonra, dəyişikliklərimizin düzgünlüyü ilə bağlı sürətli bir geri dönüş alacağımızı gözləyirik. Adətən CI, kodun statik analiz alətlərinin və modulyar / daxili API testlərinin işə salınmasını əhatə edir. Bu, kodumuz barədə məlumatları bir neçə saniyə / dəqiqə içində əldə etməyə imkan verir.
- Continuous Delivery daha inkişaf etmiş bir addımdır, burada inteqrasiya / UI testlərini işə salırıq. Amma bu mərhələdə, CI ilə olduğu kimi, nəticələri eyni sürətlə almırıq. Birincisi, bu tip testlər daha uzun müddət tələb edir. İkincisi, biz dəyişikliklərimizi test / staging mühitində yerləşdirmədən əvvəl işə salmalıyıq. Bundan əlavə, mobil inkişafdan danışdıqda, tətbiqimizin bir versiyasını hazırlamaq üçün əlavə bir mərhələ yaranır.
- Davamlı İcra bizim dəyişikliklərimizi production-a avtomatik olaraq buraxmağı ehtiva edir, əgər əvvəlki mərhələlərdə bütün qəbul testləri keçilibsə. Bu mərhələdən sonra, production-da smoke testlərini işə salmaq və maraqlı metrikləri toplamaq kimi müxtəlif mərhələlər də təyin edilə bilər. Davamlı İcra yalnız yaxşı avtomatlaşdırılmış testlərlə mümkün olur. Əgər hər hansı bir əl müdaxiləsi, o cümlədən testlər tələb olunursa, bu artıq Davamlı (davamlı) deyil. Onda, bizim konveyerimizin yalnız Davamlı Təslimat təcrübəsinə uyğun olduğunu demək mümkündür.
Avtomatlaşdırma infrastrukturu üçün dəyəri
Bu bölmədə end-to-end UI testlərindən danışarkən, dəyişikliklərimizi və əlaqəli xidmətləri test mühitlərində yayımlamalı olduğumuzu aydınlaşdırmaq istəyirəm. Continuous Integration bu iş üçün uyğun deyil və biz ən azından Continuous Delivery praktikasının tətbiqinə diqqət yetirməliyik. Həmçinin, UI testləri üçün Continuous Deployment mənalıdır, əgər onları istehsal mühitində işə salmağı planlaşdırırıq.
Arxitektura dəyişikliklərini nəzərdən keçirmədən ə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 depozit təqdim edir və bir çox əlavə funksiyaya malikdir. Beləliklə, GitLab CI-dən daha çoxdur. O, qutu içərisində mənbə kodunun idarə edilməsi, Agile idarəetməsi, CI/CD pipeline-ları, loglama alətləri və metrikanın toplanması üçün imkanları təqdim edir. GitLab-ın arxitekturası GitLab CI/CD və GitLab Runner-dən ibarətdir. Rəsmi saytdan qısa təsvir təqdim edirəm:
GitLab CI/CD, vəziyyətini verilənlər bazasında saxlayan, layihələri/istifadələri idarə edən və istifadəçi interfeysi təqdim edən bir veb tətbiqidir. GitLab Runner isə build-ləri işləyən bir tətbiqdir. O, ayrıca olaraq yerləşdirilə bilər və GitLab CI/CD ilə API vasitəsilə işləyir. Testləri həyata keçirmək üçün həm GitLab nümunəsinə, həm də Runner-a ehtiyacınız var.
İnfrastrukturun cari vəziyyətinin təsviri
Öyrənməyə dair linklər
Oxşar alətlər
- Və daha çox
5. Bulud platformaları
Texnologiyanın qısa təsviri
Bu bölmədə 'ictimai buludlar' adlanan məşhur bir trend haqqında danışacağıq. Yuxarıda təsvir edilən virtualizasiya və konteynerləşdirmə texnologiyalarının qazandırdığı böyük faydalara baxmayaraq, bizə hələ də hesablama resursları lazımdır. Şirkətlər bahalı serverlər alır və ya data mərkəzləri kirayələyir, lakin bu halda nə qədər resursa ehtiyacımız olacağını qiymətləndirmək (bəzən reallıqdan uzaq) zəruridir, onları 24/7 istifadə edəcəyikmi və hansı məqsədlərlə istifadə edəcəyik. Məsələn, istehsal üçün 24 saat işləyən bir serverə ehtiyac var, lakin eyni resurslara qeyri-iş vaxtında test aparmaq üçün ehtiyacımız varmı? Bu, icra edilən testin növündən də asılıdır. Məsələn, biz, nəticələri növbəti gün əldə etmək üçün qeyri-iş saatlarında yerinə yetirəcəyimiz yük/testləri planlaşdırırıq. Ancaq, şübhəsiz, end-to-end avtomatik testlər və xüsusilə əl test mühitləri üçün serverlərin 24 saat mövcudluğu zəruri deyil. Belə hallarda, ehtiyac duyduğumuz qədər resursları tələb etməklə əldə etməyi, bunları istifadə etməyi və artıq lazım olmadıqda ödənişi dayandırmağı istəyərik. Üstəlik, bunları bir neçə tıklama və ya bir neçə skript çalıştırmaqla dərhal əldə etməyimiz gözəl olardı. Bütün bunlar üçün ictimai buludlardan istifadə olunur. Gəlin, tərifinə nəzər salaq:
«İctimai bulud, üçüncü tərəf təminatçıları tərəfindən təqdim olunan hesablama xidmətləri olaraq təyin olunur və bunlar hər kəsin istifadə etməsi və ya alması üçün ictimai İnternet üzərindən mövcud olur. Onlar pulsuz ola bilər və ya tələb əsaslı satıla bilər, müştərilərin istehlak etdikləri CPU dövrələri, saxlama və ya bant genişliyi üçün yalnız istifadə haqqı ödəməyə imkan tanıyır.»
Bütün bu fikrin arxasında, ictimai buludların bahalı olduğu düşüncəsi var. Lakin onların əsas ideyası şirkətin xərclərini azaltmaqdır. Əvvəlcə qeyd edildiyi kimi, ictimai buludlar tələbə uyğun olaraq resurslar əldə etməyə və yalnız istifadəyə görə ödəməyə imkan tanıyır. Bəzən unuduruq ki, işçilərin əmək haqqı var, və mütəxəssislər də bahalı bir resursdur. Eyni zamanda, ictimai buludlar infrastrukturun dəstəyini əhəmiyyətli dərəcədə asanlaşdırdığı üçün mühəndislərin daha vacib işlərə fokuslanmasına imkan verir.
Avtomatlaşdırma infrastrukturu üçün dəyəri
End-to-end UI testləri üçün konkret olaraq hansı resurslara ehtiyacımız var? Əsasən, brauzerləri və emulatorları işə salmaq üçün virtual maşınlar və ya klasterlər (növbəti bölmədə Kubernetes haqqında danışacağıq) lazımdır. Eynit zamanda, biz neçə brauzer və emulatoru birdən işə salmaq istəyiriksə, o qədər CPU və yaddaş tələb olunur, və buna görə də daha çox pul ödəməli olacağıq. Beləliklə, ictimai buludlar testin avtomatlaşdırılması kontekstində bizə tələblərə uyğun olaraq çox sayda (100, 200, 1000 …) brauzer/emulatoru işə salmağa, test nəticələrini mümkün qədər tez əldə etməyə və bu cür sərfəli resursları artıq ödəməməyə imkan verir.
Ən populyar bulud provayderləri Amazon Web Services (AWS), Microsoft Azure və Google Cloud Platform (GCP)dir. Praktik bələdçidə GCP-nin istifadəsinə dair nümunələr təqdim edilir, lakin siz hansıdan istifadə edəcəyiniz ümumiyyətlə əhəmiyyətli deyil. Onların hamısı təxminən eyni funksionalı təqdim edir. Adətən, provayder seçilməsi üçün bələdçi şirkətin infrastrukturuna və iş tələblərinə fokuslanır ki, bu da bu məqalənin xaricindədir. Avtomatizasiya mühəndisləri bulud provayderlərinin istifadəsini xüsusi olaraq test məqsədləri üçün bulud platformalarının istifadəsi ilə müqayisə etməyə maraqlı olacaqlar, məsələn, Sauce Labs, BrowserStack, BitBar və s. Beləliklə, gəlin bunu edək! Mənim fikrimcə, Sauce Labs ən tanınmış bulud test fermasıdır, buna görə onu müqayisə üçün seçdim.
GCP ilə Sauce Labs arasında avtomatizasiya məqsədləri üçün müqayisə:
Tutaq ki, eyni anda 8 veb testi və 8 Android testi keçirməliyik. Bunun üçün GCP-dən istifadə edəcəyik və Selenoid ilə 2 virtual maşın işə salacağıq. Birincisində 8 brauzer konteyneri qaldıracağıq. İkincisində isə 8 emulator konteyneri qaldıracağıq. Gəlin qiymətlərə nəzər salaq:
Bir Chrome konteynerini işə salmaq üçün bizə lazım olacaq n1-standard-1 maşın. Android üçün bu olacaq n1-standard-4 bir emulator üçün. Əslində daha çevik və ucuz yol – CPU/Yaddaş üçün konkret istifadəçi dəyərləri verməkdir, lakin hazırda Sauce Labs ilə müqayisə üçün bu, əsas məsələ deyil.
Sauce Labs-ın istifadə tarifləri:
Artıq fərqi gördüyünüzü düşünürəm, lakin yenə də vəzifəmiz üçün hesablamalar cədvəlini təqdim edim:
Tələb olunan resurslar
Aylıq
İş saatları(səhər 8-dən axşam 8-ə qədər)
İş saatları+ Öncelikli
GCP üçün Veb
n1-standard-1 x 8 = n1-standard-8
$194.18
23 gün * 12saat * 0.38 = 104.88$
23 gün * 12saat * 0.08 = 22.08$
Sauce Labs üçün Veb
Virtual Cloud8 paralel testlər
$1.559
—
—
GCP üçün Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 gün * 12saat * 1.52 = 419.52$
23 gün * 12saat * 0.32 = 88.32$
Sauce Labs üçün Android
Real Device Cloud 8 paralel testlər
$1.999
—
—
Göründüyü kimi, qiymət fərqi olduqca böyükdür, xüsusən də testləri yalnız iş saatlarında icra edərkən. Amma xərcləri daha da azaltmaq mümkündür ki, bunun üçün öncelikli maşınlardan istifadə edəsiniz. Bəs bu nədir?
Öncelikli VM, normal instansiyalardan daha aşağı qiymətə yarada və işlədə biləcəyiniz bir instansiyadır. Lakin, Compute Engine bu instansiyaları digər tapşırıqlar üçün ehtiyac duyarsa dayandıra (öncəliklə) bilər. Öncelikli instansiyalar, Compute Engine-in artıq tutumudur, buna görə də onların mövcudluğu istifadəyə görə dəyişir.
Əgər tətbiqləriniz xəta dözümlüdürsə və mümkün instansiya dayandırmalarına dözə bilirsə, o zaman öncelikli instansiyalar Compute Engine xərclərinizi əhəmiyyətli dərəcədə azalda bilər. Məsələn, toplu emal işləri öncelikli instansiyalarda icra oluna bilər. Əgər o instansiyalardan bəziləri emal zamanı durursa, iş yavaşlayır, lakin tamamilə dayanmaz. Öncelikli instansiyalar toplu emal tapşırıqlarınızı tamamlayır, əlavə iş yükü yaratmadan və əlavə normal instansiyalar üçün tam qiymət ödəmədən.
Və bu hələ də son deyil! Həqiqətən də mən əminəm ki, heç kim 12 saat fasiləsiz testlər icra etmir. Əgər belədirsə, deməli siz virtual maşınları istifadə etmədikdə avtomatik olaraq işə salıb dayandıra bilərsiniz. Gerçək istifadə vaxtı gündə 6 saata qədər azala bilər. O zaman, bizim məsələmizdə ödəniş 8 brauzer üçün aylıq 11$-a qədər düşəcək. Bu, gözəl deyilmi? Amma öncelikli maşınlarla ehtiyatlı olmalıyıq və dayandırmalara və qeyri-stabil işə hazır olmalıyıq, baxmayaraq ki, bu vəziyyətləri proqnozlaşdırmaq və proqramla idarə etmək mümkündür. Buna dəyər!
Amma heç bir halda ‘heç vaxt bulud test fermerlərini istifadə etməyin’ demirəm. Onların bir çox üstünlükləri var. Ən başlıcası, bu yalnız bir virtual maşın deyil, eyni zamanda bir avtomatlaşdırma test çözümüdür ki, içində bir çox funksionallıq var: uzaqdan giriş, loqolar, ekran görüntüləri, video qeyd, müxtəlif brauzerlər və fiziki mobil cihazlar. Bir çox vəziyyətdə bu əvəzolunmaz bir alternativ ola bilər. Xüsusilə test platformaları IOS avtomatizasiyasında faydalıdır, çünki publik buludlar yalnız Linux/Windows sistemlərini təklif edə bilər. Amma IOS barədə danışmağı gələcək məqalələrdə edəcəyik. Mən hər zaman vəziyyəti analiz etməyi və tapşırıklara görə qərar verməyi tövsiyə edirəm: bəzi hallarda publik buludlardan istifadə daha ucuz və səmərəlidir, bəzilərində isə test platformaları mütləq sərfəli olacaq.
İnfrastrukturun cari vəziyyətinin təsviri
Öyrənməyə dair linklər
Analoji alətlər:
6. Orkestrasiya
Texnologiyanın qısa təsviri
Mənim yaxşı xəbərim var – biz məqalənin sonuna demək olar ki, çatdıq! Hal-hazırda bizim avtomatlaşdırma infrastrukturumuz GitLab CI vasitəsilə paralel olaraq işə saldığımız web və Android testlərindən ibarətdir; biz Docker dəstəkləyən alətlərdən istifadə edirik: Selenium grid və Selenoid. Bundan əlavə, biz GCP vasitəsilə yaradılan virtual maşınlardan istifadə edərək içində brauzerlər və emulatorlar olan konteynerləri işə salırıq. Xərcləri azaltmaq üçün bu virtual maşınları yalnız tələb olunduqda işə salırıq və testlər aparılmadıqda dayandırırıq. Bizim infrastrukturu daha da yaxşılaşdırmaq üçün başqa bir şey var? Cavab – bəli! Kubernetes (K8s) ilə tanış olun!
Öncəliklə, orkestrasiyanın, klasterin və Kubernetesin bir-birinə necə bağlı olduğuna nəzər salaq. Yüksək səviyyədə orkestrasiyanın məqsədi tətbiqləri yerləşdirmək və idarə etməkdir. Test avtomatlaşdırması üçün konteynerləşdirilmiş (containerised) tətbiqlər Selenium grid və Selenoid-dir. Docker və K8s bir-birini tamamlayır. Birincisi tətbiqlərin yerləşdirilməsi üçün, ikincisi isə orkestrasiyadır. Öz növbəsində, K8s klasterdir. Klasterin vəzifəsi VMs-ni Nodes kimi istifadə edərək bir server (klaster) daxilində müxtəlif funksionallıqları, proqramları və xidmətləri quraşdırmaqdır. Hər hansı bir Node çöksə, digər Nodes-lar işləməyə davam edir, bu da tətbiqimizin LED-lənməsini təmin edir. Əlavə olaraq, K8s-in miqyaslanma (scaling) ilə bağlı vacib funksionallığı var ki, bu da yüklənməyə və quraşdırılmış məhdudiyyətlərə əsaslanaraq avtomatik şəkildə optimal resurs sayını əldə etməyə imkan tanıyır.
Düzünü desək, Kubernetes-i sıfırdan əl ilə yerləşdirmək tam iddialı bir tapşırıqdır. Mən "Kubernetes The Hard Way" adlı tanınmış praktiki dərsliyə bir bağlantı buraxacağam və əgər siz maraqlanırsınızsa, onu təcrübə edə bilərsiniz. Lakin, şükürlər olsun ki, alternativ yollar və alətlər mövcuddur. Bunlardan ən asanı, Google Kubernetes Engine (GKE) istifadə etməkdir ki, bu da bir neçə klikdən sonra hazır bir klaster əldə etməyə imkan verir. Başlanğıc öyrənmə üçün, məhz bu yanaşmanı tövsiyə edirəm, çünki bu sizə K8s-i öz tapşırıqlarınıza necə tətbiq etməyə fokuslanmağa imkan tanıyacaq, daxili komponentlərin bir-birinə necə inteqrasiya olunmalı olduğunu öyrənməyə deyil.
Avtomatlaşdırma infrastrukturu üçün dəyəri
K8s-in təqdim etdiyi bir neçə vacib xüsusiyyətə nəzər salaq:
- tətbiqin yerləşdirilməsi: multi-nodes klasterdən istifadə, VMs əvəzinə;
- dinamika miqyaslandırma: yalnız tələb olunduqda istifadə olunan resursların xərclərini azaldır;
- özünü bərpa etmə (Self-healing): pods-u avtomatik bərpa edir (nəticədə konteynerlər də bərpa olunur);
- yeniləmə və geri dönüş dəyişikliklərinin dayanmadan həyata keçirilməsi: alətlər, brauzerlər və emulyatorların yenilənməsi cari istifadəçilərin işini dayandırmır
Amma K8s hələ də qızıl güllə deyil. Bizim müzakirə etdiyimiz alətlər (Selenium grid, Selenoid) kontekstində bütün üstünlükləri və məhdudiyyətləri anlamaq üçün K8s-in quruluşunu qısa şəkildə müzakirə edəcəyik. Cluster iki növ Node-dan ibarətdir: Master Nodes və Workers Nodes. Master Nodes idarəetmə, yayılma və scheduling decisions üçün məsuliyyət daşıyır. Workers Nodes isə tətbiqlərin işə salındığı yerlərdir. Nodes həmçinin konteynerlərin iş mühitini ehtiva edir. Bizim halımızda bu, konteynerlərlə bağlı əməliyyatları həyata keçirən Docker-dir. Amma alternativ həllər də mövcuddur, məsələn. Vacibdir ki, genişləndirmə və ya öz-özünə bərpa konteynerlərə birbaşa aid deyil. Bu, pods sayının artırılması/azaldılması yolu ilə həyata keçirilir, bunlar isə öz növbəsində konteynerləri ehtiva edir (adətən bir pod-da bir konteyner, amma tapşırıqdan asılı olaraq daha çox da ola bilər). Yüksək səviyyəli iyerarxiya, worker nodes-dan ibarətdir, hansılar ki, pods-ları, pods-lar isə konteynerləri ehtiva edir.
Genişləndirmə funksiyası əsasdır və cluster node-pool içərisindəki nodes-lara və node içindəki pods-lara tətbiq oluna bilər. Nodes və pods-lara aid iki növ genişləndirmə var. Birinci növ - horizontal - genişləndirmə nodes/pods sayının artırılması ilə baş verir. Bu növ daha üstünlük təşkil edir. İkinci növ isə, uyğun olaraq, vertical. Genişləndirmə nodes/pods-un ölçülərinin artırılması yolu ilə, onların sayının artımı olmadan həyata keçirilir.
İndi alətlərimizi yuxarıda qeyd olunan terminlər kontekstində nəzərdən keçirək.
Selenium grid
Daha əvvəl qeyd edildiyi kimi, Selenium grid – çox populyar bir alətdir və onun konteynerləşdirilməsi (containerised) təəccüblü deyil. Buna görə də, Selenium grid-in K8s-də yerləşdirilməsi gözləniləndir. Bunu necə edəcəyinizə dair nümunəni rəsmi K8s depolarında tapa bilərsiniz. Adətən, bu bölmənin sonunda bağlantıları əlavə edirəm. Bundan əlavə, praktiki bələdçidə Terraform-la bunu necə etmək lazım olduğu göstərilir. Həmçinin, brauzerləri ehtiva edən konteynerlərlə pod-ların sayını necə genişləndirmək barədə təlimat var. Lakin, K8s kontekstində avtomatik genişləndirmə funksiyası hələ də aydın olmayan bir məsələdir. Mən öyrənməyə başlayanda heç bir praktiki bələdçi və ya tövsiyə tapmadım. Bir neçə tədqiqat və təcrübələrdən sonra, DevOps komandasının dəstəyi ilə, biz lazım olan brauzerləri ehtiva edən konteynerləri bir pod-da yerə götürmə yanaşmasını seçdik ki, bu da bir işçi nod içində yerləşir. Bu yanaşma, nodların sayını artırmaqla üfüqi genişləndirmə strategiyasını tətbiq etməyə imkan tanıyır. Ümid edirəm ki, gələcəkdə vəziyyət dəyişəcək və daha çox yaxşı yanaşmaların və hazır həllərin təsvirlərini görəcəyik, xüsusilə də Selenium grid 4-ün dəyişdirilmiş daxili mimarisi buraxıldıqdan sonra.
Selenoid:
Hazırda K8s-də Selenoid yerləşdirmək ən böyük məyusiyyətdir. Onlar uyğun gəlmir. Teorik cəhətdən Selenoid konteynerini bir pod içində işə sala bilərik, amma Selenoid brauzerlə konteynerləri işə salmağa başlayanda, onlar hələ də həmin pod içində olacaq. Bu, genişləndirməni mümkün etməz və nəticədə Selenoid-in klasterdəki işi virtual maşın içindəkindən fərqli olmayacaq. Hekayənin sonu.
Moon:
Bu Selenoid ilə işləyərkən bu dar boğazı bildikdən sonra, tərtibatçılar Moon adlanan daha güclü bir alət buraxdılar. Bu alət, Kubernetes ilə işləmək üçün nəzərdə tutulmuşdur və nəticədə avtomatik genişləndirmə funksiyasını istifadə etmək mümkündür. Bununla yanaşı, indiki dövrdə bu, tək Selenium dünyasında native K8s klaster dəstəyi olan birbaşa bir alətdir (artıq yoxdur, növbəti alətə baxın ). Moon-un bu dəstəyi təmin edən əsas xüsusiyyəti:
Tamamilə vəziyyətsizdir. Selenoid hal-hazırda işləyən brauzer sessiyaları haqqında məlumatı yaddaşda saxlayır. Əgər hansısa bir səbəbdən prosesi çökərsə, bütün işləyən sessiyalar itirilir. Moon, əksinə, daxili bir vəziyyətə malik deyil və məlumat mərkəzləri arasında replika edilə bilər. Brauzer sessiyaları bir və ya daha çox replika çöksə belə, yaşamağa davam edir.
Beləliklə, Moon mükəmməl bir həll olsa da, bir problemi var, o da pulsuz olmamasıdır. Qiymət seansların sayından asılıdır. Pulsuz yalnız 0-4 seansı başlatmaq mümkündür, bu isə o qədər də faydalı deyil. Lakin, artıq beşinci seansdan başlayaraq, hər biri üçün 5 $ ödəməli olacaqsınız. Şirkətə görə vəziyyət fərqli ola bilər, amma bizim vəziyyətimizdə Moon-dan istifadə mənasızdır. Yuxarıda da qeyd etdiyim kimi, tələb əsasında Selenium Grid ilə VM-ləri başlada bilərik, ya da klasterdəki Nodes sayını artıra bilərik. Bir pipeline üçün təxminən 500 brauzer işə salırıq və testlər bitdikdən sonra bütün resursları dayandırırıq. Əgər Moon-dan istifadə etsəydik, əlavə 500 x 5 = 2500 $ ayda ödəməli olacaqdıq və testləri nə qədər tez-tez işə salsaq da fərq etməz. Yenə də, "Moon-dan istifadə etməyin" demirəm. Sizin tapşırıqlarınız üçün bu, əvəzsiz bir həll ola bilər, məsələn, təşkilatınızda çoxlu layihələr/qruplar varsa və hamısı üçün böyük bir ortaq klasterə ehtiyacınız varsa. Hər zamankı kimi, sonunda bir link qoyuram və öz tapşırığınız kontekstində bütün lazım olan hesablamaları etməyə dəvət edirəm.
Callisto: (Diqqət! Bu, orijinal məqalədə yoxdur və yalnız rus dilindəki tərcümədə var.)
Dediyim kimi, Selenium – çox populyar bir alətdir, IT sahəsi isə çox sürətlə inkişaf edir. Tərcümə ilə məşğul olduğum zaman, şəbəkədə yeni ümidverici alət Callisto (Cypress və digər Selenium "qatil"lərinə salam) ortaya çıxdı. O, K8s ilə yerli işləyir və Selenoid konteynerlərini pods-da, Nodes-da paylanmış şəkildə işə salmağa imkan verir. Hər şey sandıqdan çıxan kimi işləyir, avtomatik ölçü artırma da daxil. Fantastikdir, amma test edilməlidir. Artıq bu aləti işə salmağı bacardım və bir neçə eksperiment aparmışam. Amma nəticələri uzun müddət ərzində əldə etdikdən sonra nəticə çıxarmaq hələ tezdir; bəlkə də bunu gələcək məqalələrdə nəzərdən keçirərəm. Hal-hazırda sadəcə müstəqil araşdırmalar üçün linklər qoyuram.
İnfrastrukturun cari vəziyyətinin təsviri
Öyrənməyə dair linklər
Öyrənməyə dair linklər
Oxşar alətlər
7. İnfrastruktur kod olaraq (IaC)
Texnologiyanın qısa təsviri
Və burada son bölməyə yaxınlaşırıq. Adətən, bu texnologiya və ona bağlı olan məsələlər avtomatlaşdırma mühəndislərinin məsuliyyətinə daxil olmur. Bunun öz səbəbləri var. Birincisi, bir çox təşkilatlarda infrastruktur məsələləri DevOps şöbəsinin nəzarəti altındadır və inkişaf komandaları pipeline-in necə işlədiyi və bununla bağlı hər şeyin necə saxlanılacağı ilə çox ilgilənmir. İkincisi, etiraf edək ki, "İnfrastruktur kod olaraq (IaC)" praktikası hələ də bir çox şirkətlərdə tətbiq olunmur. Lakin, mütləq populyar bir trend halına gəldi və buna bağlı olan proseslərə, yanaşmalara və alətlərə cəlb olunmağa çalışmaq vacibdir. Yaxud, ən azından xəbərlərdə olmaq.
Başlamaq üçün bu yanaşmanın istifadəsi motivasiyasından danışaq. Artıq GitlabCI-da testləri icra etmək üçün minimumda Gitlab Runner-i işə salmaq üçün resurslara ehtiyacımız olduğunu müzakirə etmişik. Brauzerləri/emulyatorları işə salmaq üçün VM və ya klaster ayırmalıyıq. Test resurslarından başqa, inkişaf mühitlərinin, staging, production-un dəstəklənməsi üçün əhəmiyyətli sayda gücə də ehtiyacımız var, bunlar arasında verilənlər bazaları, avtomatlaşdırılmış cədvəllər, şəbəkə konfiqurasiyaları, yüklənmə balanslaşdırıcıları, istifadəçi hüquqları və s. var. Əsas problem, bunların hamısını dəstəkləmək üçün tələb olunan səylərdədir. Dəyişikliklər etməyə və yeniləmələri yaymağa bir neçə yol var. Məsələn, GCP kontekstində brauzerdə UI konsolunu istifadə edərək bütün əməliyyatları düymələri klikləyərək icra edə bilərik. Alternativ bir metod, bulud varlıqları ilə qarşılıqlı əlaqə üçün API çağırışlarının istifadəsi və ya gcloud komanda alətinin müvafiq manipulyasiyaların yerinə yetirilməsi üçün istifadəsidir. Lakin həqiqətən müxtəlif varlıqların və infrastruktur elementlərinin sayı çox olduqda, bütün əməliyyatları əl ilə həyata keçirmək çətin və ya hətta mümkünsüz olur. Daha çox, bütün bu əl əməliyyatları nəzarətsizdir. Onları icra etməzdən əvvəl review-a göndərmək, versiya nəzarəti sistemini istifadə etmək və hadisəyə səbəb olan düzəlişləri tez bir zamanda geri qaytarmaq mümkün deyil. Belə problemləri həll etmək üçün mühəndislər avtomatik bash/shell skriptləri yaratmış və yaradır, lakin bunlar əvvəlki metodlardan çox da fərqlənmir, çünki onları sürətlə oxumaq, başa düşmək, prosedura tərzində dəstəkləmək və modifikasiya etmək asan deyil.
Bu məqalədə və praktiki bələdçidə mən IaC tətbiqinə aid olan 2 alətdən istifadə edirəm. Bunlar Terraform və Ansible-dır. Bəziləri eyni vaxtda istifadə etməyin mənasız olduğunu düşünür, çünki onların funksionallığı oxşardır və bir-birini əvəz edir. Lakin məsələ bundadır ki, onların qarşısında qoyulan tapşırıqlar tamamilə fərqlidir. Hətta bu alətlərin bir-birini tamamlamalı olduğu faktı, HashiCorp və RedHat şirkətlərini təmsil edən inkişaf etdiricilər tərəfindən ortaq təqdimatla təsdiqlənmişdir. Konseptual fərq ondadır ki, Terraform – serverlərin özlərini idarə etmək üçün provisioning alətidir. Eyni zamanda Ansible, bu serverlərdə proqram təminatının quraşdırılması, konfiqurasiyası və idarə edilməsi ilə məşğuldur.
Bu alətlərin bir digər əsas fərqləndirici cəhəti kod yazma üslubudur. Bash və Ansible-dan fərqli olaraq, Terraform deklarativ üslubdan istifadə edir ki, bu da yerinə yetirilməli olan arzu olunan son vəziyyətin təsvirinə əsaslanır. Məsələn, əgər 10 VM yaradacağıqsa və dəyişiklikləri Terraform vasitəsilə tətbiq edəcəyiksə, onda 10 VM əldə edəcəyik. Skripti bir daha tətbiq etsək, heç nə olmayacaq, çünki artıq 10 VM-limiz var və Terraform bununla bağlı məlumatlıdır, çünki o, infrastrukturun cari vəziyyətini state faylında saxlayır. Ancaq Ansible prosedur yanaşmasından istifadə edir və əgər ondan 10 VM yaratmağı istəsək, birinci işə salındıqda 10 VM əldə edəcəyik, bu, Terraform ilə eynidir. Amma bir daha işə saldıqda, artıq 20 VM olacaq. Burada əsas fərq də budur. Prosedur üslubunda cari vəziyyəti saxlamırıq və sadəcə yerinə yetirilməsi lazım olan addımların ardıcıllığını təsvir edirik. Təbii ki, müxtəlif vəziyyətləri emal edə bilərik, resursların və cari vəziyyətin varlılığı üçün bir neçə yoxlama əlavə edə bilərik, amma bu logikanı kontrol etməyə vaxt və enerjimizi sərf etməyin mənası yoxdur. Üstəlik, bu, səhv etmə riskini artırır.
Yuxarıda qeyd olunanları ümumiləşdirsək, serverlərin provisioninqi üçün daha uyğun alətin Terraform və deklarativ notasiya olduğunu nəticə çıxarmaq olar. Konfiqurasiyaların idarə olunması işini isə Ansible-ə həvalə etmək daha yaxşıdır. Bununla bağlı aydınlaşdıqdan sonra, avtomatlaşdırma kontekstində istifadə nümunələrinə nəzər salaq.
Avtomatlaşdırma infrastrukturu üçün dəyəri
Burada yalnız onu anlamaq vacibdir ki, test avtomatlaşdırmasının infrastrukturu şirkətın bütün infrastrukturu ilə bir hissə kimi nəzərə alınmalıdır. Bu isə deməkdir ki, bütün IaC təcrübələri təşkilatın resurslarına qlobal şəkildə tətbiq edilməlidir. Bunun üçün kim məsuliyyət daşıyır, sizin proseslərinizdən asılıdır. DevOps komandası bu məsələlərdə daha təcrübəlidir, onlar baş verən hadisələrin tam mənzərəsini görürlər. Lakin QA mühəndisləri avtomatlaşdırma prosesinin qurulmasında və pipeline strukturunda daha çox iştirak etdikləri üçün lazım olan bütün dəyişiklikləri və inkişaf imkanlarını daha yaxşı görə bilirlər. Ən yaxşı variant birgə işləmək, bilik və ideyaları mübadilə etməkdir ki, gözlənilən nəticəyə nail olunsun.
Terraform və Ansible-in test avtomatlaşdırması və əvvəllər müzakirə etdiyimiz alətlər kontekstində istifadəsinə dair bir neçə nümunəni təqdim edim:
1. Terraform vasitəsilə VM-lərin və klasterlərin tələb olunan xüsusiyyətlərini və parametrlərini təsvir etmək.
2. Ansible vasitəsilə test üçün lazım olan alətləri quraşdırmaq: docker, Selenoid, Selenium Grid və tələb olunan brauzer/emulator versiyalarını yükləmək.
3. Terraform vasitəsilə GitLab Runner-in işə salınacağı VM-in xüsusiyyətlərini təsvir etmək.
4. GitLab Runner və zəruri əlavə alqları Ansible ilə quraşdırın, parametrləri və konfiqurasiyaları müəyyən edin.
İnfrastrukturun cari vəziyyətinin təsviri
Öyrənmək üçün bağlantılar:
Oxşar alətlər
Nəticələri yekunlaşdıraq!
Addım
Texnologiya
Alatlar
Avtomatlaşdırma infrastrukturu üçün dəyəri
1
Yerli icra
Node.js, Selenium, Appium
- Web və mobil üçün ən populyar alətlər
- Bir çox dil və platforma dəstəyi (Node.js daxil olmaqla)
2
Versiya nəzarət sistemləri
Git
- Kodu inkişaf etdirmə ilə eyni üstünlüklər
3
Konteynerləşdirmə
Docker, Selenium grid, Selenoid (Web, Android)
- Testlərin paralel icrası
- İzolyasiya olunmuş mühitlər
- Sadə, çevik versiya güncəlləməsi
- İstifadə olunmayan resursların dinamik dayandırılması
- Asan konfiqurasiya
4
CI / CD
Gitlab CI
- Testlər boru kəmərinin bir hissəsidir
- Tez geri bildirim
- Bütün şirkət / komanda üçün görünürlük
5
Bulud platformaları
Google Cloud Platform
- Tələb olunan resurslar (yalnız lazım olduqda ödəyirik)
- Asan idarə etmək və güncəlləmək
- Bütün resursların görünürlüğü və nəzarəti
6
Orkestrasiya
Kubernetes
Konteynerlərdə brauzer/emulatorlarla birlikdə pods kontekstində:
- Şkalalaşdırma / avtomatik şkalalaşdırma
- Özünü bərpa etmə
- Güncəlləmələr və təhqir etmələr kəsilmədən
7
Infrastruktur şifrə olaraq (IaC)
Terraform, Ansible
- İnkişaf infrastrukturunda eyni üstünlüklər
- Kodu versiyalaşdırmanın bütün üstünlükləri
- Dəyişiklikləri etmək və saxlamaq asandır
- Tamamilə avtomatlaşdırılmışdır
Fikir xəritəsi diaqramları: infrastrukturun təkamülü
addım 1: Yerli
addım 2: VCS
addım 3: Konteynerləşdirmə
addım 4: CI/CD
addım 5: Bulud Platformaları
addım 6: Orkestrasiya
addım 7: IaC
Sonra ne olacak?
Beləliklə, bu məqalənin sonudur. Amma yekunda sizinlə bəzi razılıqlar qurmaq istərdim.
Sizin tərəfinizdən
Başlanğıcda dediyim kimi, məqalənin praktiki fayda gətirməsini və öyrəndiyiniz bilikləri real işdə tətbiq etməyə kömək etməsini istərdim. Yenidən əlavə edirəm.
Amma bütün bunlardan sonra belə, dayanmayın, təcrübə edin, müvafiq bağlantıları və kitabları öyrənin, sizin şirkətinizdə bunun necə işlədiyini öyrənin, təkmilləşdiriləcək yerləri tapın və buna qatılın. Uğurlar!
Mənim tərəfimdən
Başlıqdan göründüyü kimi, bu yalnız birinci hissə idi. Bu qədər böyük olmasına baxmayaraq, burada hələ də vacib mövzular açılmamışdır. İkinci hissədə IOS kontekstində avtomatlaşdırma infrastrukturunu nəzərdən keçirməyi planlaşdırıram. Apple-ın IOS simulatorlarını yalnız macOS sistemlərində işə salmağa dair məhdudiyyətlərinə görə, həllər paketimiz daralmışdır. Məsələn, simulatoru işə salmaq üçün Docker-dan və ya virtual maşınlar üçün ictimai buludlardan istifadə etmək imkanımız yoxdur. Amma bu, alternativlərin olmaması demək deyil. Mən sizi qabaqcıl həllər və müasir alətlərlə bağlı məlumatlandırmağa çalışacam!
Bundan əlavə, monitoring ilə bağlı olduqca böyük mövzuları da qaçırdım. 3-cü hissədə, infrastrukturun izlənməsi üçün ən populyar alətləri və hansı məlumatları və metrikaları nəzərə almaq lazım olduğunu müzakirə etməyi planlaşdırıram.
Ən sonda, gələcəkdə mən test infrastrukturu qurmaq və tanınmış alətlər haqqında video kursu buraxmağı planlaşdırıram. Hazırda internetdə DevOps üzrə çox sayda kurs və mühazirə var, amma bütün materiallar inkişaf kontekstində təqdim edilir, avtomatlaşdırılmış testləşdirmə kontekstində deyil. Bu məsələdə mənim üçün geri bildirim çox önəmlidir; belə bir kursun testçilər və avtomatlaşdırıcılar cəmiyyəti üçün maraqlı və dəyərli olub-olmayacağı barədə fikrinizi bilmək istərdim. Əvvəlcədən təşəkkür edirəm!
Mənbə: habr.com
