DevOps təcrübələri işləyir. Buraxılış quraşdırma vaxtını 10 dəfə azaltdıqda buna özümüz də əmin olduq. VTB-də istifadə etdiyimiz FIS Profile sistemində indi quraşdırma 90 dəqiqə deyil, 10 dəqiqə çəkir. Buraxılış qurma müddəti iki həftədən iki günə qədər azalıb. Davamlı icra qüsurlarının sayı demək olar ki, minimuma enmişdir. “Əl əməyindən” uzaqlaşmaq və satıcıdan asılılığı aradan qaldırmaq üçün qoltuq dəyənəkləri ilə işləməli və gözlənilməz həllər tapmalı olduq. Kesimin altında tam hüquqlu bir daxili inkişafı necə qurduğumuz haqqında ətraflı bir hekayə var.
Proloq: DevOps bir fəlsəfədir
Keçən il ərzində biz VTB-də DevOps təcrübələrinin daxili inkişafı və tətbiqini təşkil etmək üçün çox iş görmüşük:
- 12 sistem üçün daxili inkişaf prosesləri qurduq;
- Biz 15 boru kəmərini işə saldıq, onlardan dördü istehsala gətirildi;
- Avtomatlaşdırılmış 1445 test ssenarisi;
- Biz daxili komandalar tərəfindən hazırlanmış bir sıra buraxılışları uğurla həyata keçirdik.
Daxili inkişaf və DevSecOps təcrübələrinin həyata keçirilməsini təşkil etmək ən çətin olanlardan biri FIS Profile sistemi - qeyri-relational DBMS-də pərakəndə məhsul prosessoru olduğu ortaya çıxdı. Buna baxmayaraq, biz inkişafı qura bildik, boru kəmərini işə sala bildik, məhsula fərdi buraxılmayan paketlər quraşdıra bildik və buraxılışları necə yığmağı öyrəndik. Tapşırıq asan deyildi, lakin maraqlı və həyata keçirilməsində aşkar məhdudiyyətlər olmadan: sistem budur - daxili inkişaf qurmaq lazımdır. Yeganə şərt CD-dən məhsuldar mühitdən əvvəl istifadə etməkdir.
Əvvəlcə icra alqoritmi sadə və aydın görünürdü:
- Biz ilkin inkişaf təcrübəsini inkişaf etdiririk və kobud qüsurlar olmadan kod komandasından məqbul keyfiyyət səviyyəsinə nail oluruq;
- Biz mümkün qədər mövcud proseslərə inteqrasiya edirik;
- Aydın mərhələlər arasında kodu ötürmək üçün bir boru kəmərini kəsdik və onun uclarından birini davama itələyirik.
Bu müddət ərzində tələb olunan ölçüdə inkişaf komandası bacarıqları inkişaf etdirməli və buraxılışlara verdiyi töhfənin payını məqbul səviyyəyə qaldırmalıdır. Və budur, tapşırığı tamamlanmış hesab edə bilərik.
Görünür ki, bu, tələb olunan nəticəyə aparan tamamilə enerjiyə qənaət edən bir yoldur: budur DevOps, budur komandanın performans göstəriciləri, burada toplanmış təcrübə... Amma praktikada biz DevOps-un hələ də fəlsəfə ilə bağlı olduğuna dair daha bir təsdiq aldıq. , və "gitlab prosesinə bağlı deyil, ansible, nexus və daha aşağı siyahıda."
Fəaliyyət planını bir daha təhlil etdikdən sonra anladıq ki, biz özümüzdə bir növ autsorsing satıcısı qururuq. Buna görə də, yuxarıda təsvir edilən alqoritmə proseslərin yenidən qurulması, eləcə də bu prosesdə aparıcı rola nail olmaq üçün bütün inkişaf marşrutu boyunca təcrübənin inkişafı əlavə edildi. Ən asan variant deyil, amma bu, ideoloji cəhətdən düzgün inkişaf yoludur.
Daxili inkişaf haradan başlayır?
Bu işləmək üçün ən uyğun sistem deyildi. Arxitektura baxımından bu, bir çox ayrı-ayrı icra edilə bilən obyektlərdən (skriptlər, prosedurlar, partiyalar və s.) ibarət olan və qara qutu prinsipi ilə işləyən bir böyük qeyri-münasibətli DBMS idi: o, sorğu və məsələləri qəbul edir. cavab. Diqqətə layiq olan digər çətinliklərə aşağıdakılar daxildir:
- ekzotik dil (MUMPS);
- Konsol interfeysi;
- Məşhur avtomatlaşdırma alətləri və çərçivələri ilə inteqrasiyanın olmaması;
- Verilənlərin həcmi onlarla terabayt;
- Saatda 2 milyondan çox əməliyyat yükü;
- Əhəmiyyətlilik - İşgüzar Tənqidi.
Eyni zamanda, bizim tərəfimizdə mənbə kodu deposu yox idi. Bütün. Sənədləşmə var idi, lakin bütün əsas bilik və bacarıqlar kənar təşkilatın tərəfində idi.
Biz onun xüsusiyyətlərini və aşağı paylanmasını nəzərə alaraq sistemin işlənməsini demək olar ki, sıfırdan mənimsəməyə başladıq. 2018-ci ilin oktyabrında başladı:
- Sənədləşməni və kodun yaradılmasının əsaslarını öyrənib;
- Biz satıcıdan qısa inkişaf kursunu öyrəndik;
- İlkin inkişaf bacarıqlarını mənimsəmiş;
- Biz yeni komanda üzvləri üçün təlim kitabçası tərtib etdik;
- Biz komandanı “döyüş” rejiminə daxil etməyə razılaşdıq;
- Kod keyfiyyətinə nəzarət ilə problemi həll etdi;
- İnkişaf üçün stend təşkil etdik.
Biz üç ay təcrübəni inkişaf etdirməyə və sistemə daxil olmağa sərf etdik və 2019-cu ilin əvvəlindən daxili inkişaf parlaq gələcəyə doğru hərəkətə başladı, bəzən çətinliklə, lakin inamlı və məqsədyönlü şəkildə.
Repository miqrasiyası və avtotestlər
İlk DevOps tapşırığı depodur. Biz tez bir zamanda giriş təmin etmək barədə razılığa gəldik, lakin bir magistral filialı olan cari SVN-dən bir neçə filial modelinə keçid və Git Flow-un inkişafı ilə hədəfimiz Git-ə köçmək lazım idi. Həmçinin öz infrastrukturu olan 2 komandamız, üstəlik xaricdə satıcı komandasının bir hissəsi var. Mən iki Gits ilə yaşamalı və sinxronizasiyanı təmin etməli idim. Belə bir vəziyyətdə iki şərdən daha kiçik idi.
Anbarın miqrasiyası dəfələrlə təxirə salındı, o, cəbhə xəttindən olan həmkarlarının köməyi ilə yalnız aprel ayında tamamlandı. Git Flow ilə biz başlanğıc üçün hər şeyi sadə saxlamağa qərar verdik və düzəliş, inkişaf etdirmə və buraxma ilə klassik sxemdə qərarlaşdıq. Ustadan (aka prod kimi) imtina etmək qərarına gəldilər. Aşağıda bu seçimin niyə bizim üçün optimal olduğunu izah edəcəyik. Satıcıya məxsus, iki komanda üçün ümumi olan xarici anbar işçi kimi istifadə edilmişdir. O, qrafikə uyğun olaraq daxili repozitoriya ilə sinxronlaşdırılıb. İndi Git və Gitlab ilə prosesləri avtomatlaşdırmaq mümkün idi.
Avtotestlər məsələsi təəccüblü şəkildə asanlıqla həll edildi - bizə hazır çərçivə təqdim edildi. Sistemin xüsusiyyətlərini nəzərə alaraq, ayrıca əməliyyat çağırmaq iş prosesinin başa düşülən hissəsi idi və eyni zamanda vahid testi rolunu oynayırdı. Qalan tək şey test məlumatlarını hazırlamaq və skriptləri çağırmaq və nəticələri qiymətləndirmək üçün istədiyiniz qaydanı təyin etmək idi. Əməliyyat statistikası, proseslərin kritikliyi və mövcud reqressiya metodologiyası əsasında formalaşan ssenarilərin siyahısı doldurulduqca avtomatik sınaqlar görünməyə başladı. İndi boru kəmərinin tikintisinə başlaya bilərdik.
Necə oldu: avtomatlaşdırmadan əvvəlki model
İcra prosesinin mövcud modeli ayrı bir hekayədir. Hər bir modifikasiya ayrıca artımlı quraşdırma paketi kimi əl ilə köçürüldü. Daha sonra Jira-da əl ilə qeydiyyat və mühitlərdə əl ilə quraşdırma gəldi. Fərdi paketlər üçün hər şey aydın görünürdü, lakin buraxılışın hazırlanması ilə işlər daha mürəkkəb idi.
Montaj müstəqil obyektlər olan fərdi tədarüklər səviyyəsində həyata keçirilmişdir. İstənilən dəyişiklik yeni çatdırılmadır. Digər şeylər arasında, əsas buraxılış kompozisiyasının 60-70 paketinə 10-15 texniki versiya əlavə edildi - buraxılışa nəyisə əlavə edərkən və ya çıxararkən əldə edilən və buraxılışlardan kənar satışlarda dəyişiklikləri əks etdirən versiyalar.
Çatdırılmalar daxilindəki obyektlər bir-biri ilə üst-üstə düşdü, xüsusən də yarıdan az unikal olan icra olunan kodda. Həm artıq quraşdırılmış koddan, həm də quraşdırılması yeni planlaşdırılan koddan çoxlu asılılıqlar var idi.
Kodun tələb olunan versiyasını əldə etmək üçün quraşdırma ardıcıllığına ciddi riayət etmək lazım idi, bu müddət ərzində obyektlər fiziki olaraq dəfələrlə, təxminən 10-12 dəfə yenidən yazılmışdır.
Paketlərin dəstini quraşdırdıqdan sonra parametrləri işə salmaq üçün təlimatları əl ilə yerinə yetirməli oldum. Buraxılış satıcı tərəfindən yığılıb və quraşdırılıb. Buraxılışın tərkibi demək olar ki, həyata keçirilmə anından əvvəl aydınlaşdırıldı ki, bu da "decoupling" paketlərinin yaradılmasına səbəb oldu. Nəticədə, tədarükün əhəmiyyətli bir hissəsi öz "decouplings" quyruğu ilə buraxılışdan buraxılışa keçdi.
İndi aydın olur ki, bu yanaşma ilə - buraxılış tapmacasını paket səviyyəsində toplamaq - tək bir master filialının praktiki mənası yoxdur. İstehsalda quraşdırma bir saat yarımdan iki saata qədər əl əməyini çəkdi. Ən azı quraşdırıcı səviyyəsində obyektin işlənməsi qaydasının müəyyən edilməsi yaxşıdır: sahələr və strukturlar onlar üçün məlumat və prosedurlardan əvvəl daxil edilmişdir. Bununla belə, bu yalnız ayrı bir paket daxilində işləmişdir.
Bu yanaşmanın məntiqi nəticəsi, buraxıldıqdan sonra qızdırmalı şəkildə aradan qaldırılan obyektlərin əyri versiyaları, lazımsız kodlar, çatışmayan təlimatlar və obyektlərin qarşılıqlı təsirləri şəklində məcburi quraşdırma qüsurları idi.
İlk yeniləmələr: montaj və çatdırılma
Avtomatlaşdırma bu marşrut boyunca bir boru vasitəsilə kodu ötürməklə başladı:
- Hazır çatdırılmanı anbardan götürün;
- Onu xüsusi bir mühitə quraşdırın;
- Avtotestləri həyata keçirin;
- Quraşdırma nəticəsini qiymətləndirin;
- Test əmrinin tərəfində aşağıdakı boru xəttinə zəng edin.
Növbəti boru kəməri tapşırığı Jira-da qeydiyyatdan keçirməli və tapşırıqların yerinə yetirilməsi vaxtından asılı olan seçilmiş sınaq dövrələrinə əmrlərin paylanmasını gözləməlidir. Trigger - müəyyən bir ünvana çatdırılmağa hazır olması barədə məktub. Bu, əlbəttə ki, açıq-aşkar qoltuqağacı idi, amma mən bir yerdən başlamalı idim. 2019-cu ilin may ayında kodun ötürülməsi mühitlərimizin yoxlanılması ilə başladı. Proses başladı, onu layiqli formaya salmaq qalır:
- Hər bir modifikasiya quraşdırma paketinə uyğun gələn və hədəf master filialına birləşən ayrı bir filialda həyata keçirilir;
- Boru kəmərinin işə salınması tetikleyicisi, daxili komandanın baxıcıları tərəfindən bağlanan birləşmə sorğusu vasitəsilə əsas filialda yeni öhdəliyin görünməsidir;
- Repozitoriyalar hər beş dəqiqədə bir dəfə sinxronlaşdırılır;
- Quraşdırma paketinin yığılması başlayır - satıcıdan alınan assemblerdən istifadə etməklə.
Bundan sonra kodun yoxlanılması və ötürülməsi, borunun işə salınması və bizim tərəfdə yığılması üçün artıq mövcud addımlar var idi.
Bu seçim iyulda işə salınıb. Keçidin çətinlikləri satıcı və cəbhə xətti arasında müəyyən narazılıqla nəticələndi, lakin növbəti bir ay ərzində biz bütün kobud kənarları aradan qaldırıb komandalar arasında proses qura bildik. İndi təhvil vermə və çatdırılma ilə montajımız var.
Avqust ayında boru kəmərimizdən istifadə edərək istehsal üzrə ayrıca paketin ilk quraşdırılmasını başa çatdıra bildik və sentyabr ayından istisnasız olaraq, fərdi buraxılmayan paketlərin bütün quraşdırılması CD alətimiz vasitəsilə həyata keçirildi. Bundan əlavə, biz satıcıdan daha kiçik bir komanda ilə buraxılış tərkibinin 40% -də daxili tapşırıqların payına nail ola bildik - bu, müəyyən bir uğurdur. Ən ciddi vəzifə qaldı - buraxılışı yığmaq və quraşdırmaq.
Son həll: kümülatif quraşdırma paketləri
Satıcının göstərişlərinin skriptinin belə avtomatlaşdırma olduğunu mükəmməl başa düşdük; prosesin özünü yenidən nəzərdən keçirməli olduq. Həll aydın idi - tələb olunan versiyaların bütün obyektləri ilə buraxılış filialından məcmu təchizatı toplamaq.
Biz konsepsiyanın sübutu ilə başladıq: buraxılış paketini keçmiş tətbiqin məzmununa uyğun olaraq əl ilə yığdıq və onu mühitlərimizə quraşdırdıq. Hər şey düzəldi, konsepsiya reallaşdı. Sonra, başlanğıc parametrlərini skript etmək və onları öhdəliyə daxil etmək məsələsini həll etdik. Biz yeni paket hazırladıq və onu kontur yeniləməsinin bir hissəsi olaraq sınaq mühitlərində sınaqdan keçirdik. Tətbiq qrupunun geniş şərhlərinə baxmayaraq, quraşdırma uğurlu oldu. Ancaq əsas odur ki, noyabr ayında buraxılışda assambleyamızla birlikdə istehsala başlamaq üçün bizə icazə verildi.
Cəmi bir aydan çox vaxt qaldıqda, əl ilə seçilmiş ləvazimatlar vaxtın tükəndiyini açıq şəkildə göstərirdi. Onlar quruluşu buraxılış budağından etmək qərarına gəldilər, amma niyə ayrılmalıdır? Bizdə Prod-ə bənzər bir şey yoxdur və mövcud filiallar yaxşı deyil - çoxlu lazımsız kodlar var. Biz təcili olaraq məhsul bəyənmələrini kəsməliyik və bu, üç mindən çox öhdəlikdir. Əl ilə yığmaq qətiyyən seçim deyil. Məhsulun quraşdırılması jurnalından keçən və filiala öhdəliklər toplayan bir skript hazırladıq. Üçüncü dəfə düzgün işlədi və "faylla bitirdikdən" sonra filial hazır oldu.
Quraşdırma paketi üçün öz inşaatçımızı yazdıq və bir həftə ərzində bitirdik. Sonra biz quraşdırıcını sistemin əsas funksionallığından dəyişdirməli olduq, çünki o, açıq mənbəlidir. Bir sıra yoxlamalar və dəyişikliklərdən sonra nəticə uğurlu hesab edildi. Bu vaxt buraxılışın tərkibi formalaşdı, düzgün quraşdırılması üçün sınaq dövrəsini istehsal ilə uyğunlaşdırmaq lazım idi və bunun üçün ayrıca bir skript yazılmışdır.
Təbii ki, ilk quraşdırma haqqında çoxlu şərhlər var idi, lakin ümumilikdə kod işlədi. Təxminən üçüncü quraşdırmadan sonra hər şey yaxşı görünməyə başladı. Tərkibinə nəzarət və obyektlərin versiyaya nəzarəti əl rejimində ayrı-ayrılıqda izlənildi ki, bu da bu mərhələdə kifayət qədər əsaslandırıldı.
Əlavə bir problem nəzərə alınmalı olan çox sayda qeyri-reliz idi. Lakin Prod-bənzər filial və Rebase ilə tapşırıq şəffaf oldu.
İlk dəfə, tez və səhvsiz
Biz buraxılışa optimist münasibətlə və müxtəlif sxemlərdə ondan çox uğurlu quraşdırma ilə yanaşdıq. Amma sözün əsl mənasında, son tarixdən bir gün əvvəl məlum oldu ki, satıcı buraxılışı qəbul edilmiş şəkildə quraşdırmaya hazırlamaq üçün işləri başa çatdırmayıb. Əgər nədənsə quruluşumuz işləməsə, buraxılış pozulacaq. Üstəlik, səylərimizlə, xüsusilə də xoşagəlməzdir. Geri çəkilməyə yolumuz yox idi. Ona görə də biz alternativ variantları düşündük, fəaliyyət planları hazırladıq və quraşdırmaya başladıq.
Təəccüblüdür ki, 800-dən çox obyektdən ibarət olan bütün buraxılış ilk dəfə və cəmi 10 dəqiqə ərzində düzgün başladı. Səhvləri axtararaq qeydləri yoxlamaq üçün bir saat sərf etdik, lakin heç bir şey tapmadıq.
Bütün ertəsi gün buraxılış söhbətində səssizlik hökm sürürdü: heç bir tətbiq problemi, əyri versiyalar və ya “uyğun olmayan” kod. Hətta nədənsə yöndəmsiz idi. Daha sonra bəzi şərhlər ortaya çıxdı, lakin digər sistemlər və əvvəlki təcrübə ilə müqayisədə onların sayı və prioriteti nəzərəçarpacaq dərəcədə aşağı idi.
Kumulyativ təsirin əlavə təsiri montaj və sınaq keyfiyyətinin artması idi. Tam buraxılışın çoxsaylı quraşdırılmasına görə, qurma qüsurları və yerləşdirmə səhvləri vaxtında müəyyən edildi. Tam buraxılış konfiqurasiyalarında sınaq, artan quraşdırma zamanı görünməyən obyektlərin qarşılıqlı təsirindəki qüsurları əlavə olaraq müəyyən etməyə imkan verdi. Xüsusilə buraxılışa 57% töhfəmizi nəzərə alsaq, bu, mütləq uğur idi.
Xülasə və Nəticələr
Bir ildən az müddətdə biz bacardıq:
- Ekzotik sistemdən istifadə edərək tam hüquqlu daxili inkişaf qurmaq;
- Kritik satıcı asılılığını aradan qaldırın;
- Çox xoşagəlməz bir miras üçün CI/CD-ni işə salın;
- İcra proseslərinin yeni texniki səviyyəyə yüksəldilməsi;
- Yerləşdirmə vaxtını əhəmiyyətli dərəcədə azaltmaq;
- İcra xətalarının sayını əhəmiyyətli dərəcədə azaltmaq;
- Özünüzü qabaqcıl inkişaf mütəxəssisi kimi əminliklə bəyan edin.
Əlbəttə ki, təsvir edilənlərin çoxu tamamilə axmaq kimi görünür, lakin bunlar sistemin xüsusiyyətləri və orada mövcud olan proses məhdudiyyətləridir. Hazırda dəyişikliklər IS Profile məhsul və xidmətlərinə (master hesablar, plastik kartlar, əmanət hesabları, əmanət, nağd kreditlər) təsir edib, lakin potensial olaraq yanaşma DevOps təcrübələrinin tətbiqi vəzifəsinin qoyulduğu istənilən İS-ə tətbiq oluna bilər. Kumulyativ model bir çox tədarüklərdən sonrakı tətbiqlər (buraxılmayanlar da daxil olmaqla) üçün təhlükəsiz şəkildə təkrarlana bilər.
Mənbə: www.habr.com