Hesabat bəzi DevOps təcrübələri haqqında danışacaq, lakin bir tərtibatçının nöqteyi-nəzərindən. Tipik olaraq, DevOps-a qoşulan bütün mühəndislər artıq bir neçə illik inzibati təcrübəyə malikdirlər. Amma bu o demək deyil ki, burada tərtibatçıya yer yoxdur. Çox vaxt tərtibatçılar “günün növbəti təcili kritik səhvini” düzəltməklə məşğul olurlar və DevOps sahəsinə tez nəzər salmağa belə vaxtları yoxdur. Müəllifin anlayışına görə, DevOps, ilk növbədə, sağlam düşüncədir. İkincisi, daha təsirli olmaq üçün bir fürsətdir. Əgər siz inkişaf etdiricisinizsə, sağlam düşüncəyə sahibsinizsə və komanda oyunçusu kimi daha effektiv olmaq istəyirsinizsə, bu hesabat sizin üçündür.
İcazə verin özümü təqdim edim, tam etiraf edirəm ki, otaqda məni tanımayanlar var. Mənim adım Anton Boyko, mən Microsoft Azure MVP-yəm. MVP nədir? Bu, Model-View-Təqdimatçıdır. Model-View-Təqdimatçı məhz mənəm.
Bundan əlavə, hazırda Ciklumda həll memarı vəzifəsində çalışıram. Və bu yaxınlarda özümə belə gözəl bir domen aldım və adətən təqdimatlarda göstərdiyim e-poçtumu yenilədim. Siz mənə yaza bilərsiniz: me [dog] byokoant.pro. Suallarınızı mənə e-poçtla göndərə bilərsiniz. Mən adətən onlara cavab verirəm. Yeganə odur ki, mən iki mövzuya aid olan sualları e-poçtla almaq istəmirəm: siyasət və din. Qalan hər şey haqqında mənə e-poçt vasitəsilə yaza bilərsiniz. Bir az vaxt keçəcək, cavab verəcəm.
Özünüz haqqında bir neçə kəlmə:
- Artıq 10 ildir ki, bu sahədəyəm.
- Microsoft-da işləmişəm.
- Mən 2014-cü ildə haradasa təsis etdiyimiz Ukrayna Azure icmasının qurucu atasıyam. Və bizdə hələ də var və onu inkişaf etdiririk.
- Mən həm də Ukraynada ev sahibliyi etdiyimiz Azure konfransının təsisçisinin atasıyam.
- Mən həmçinin Kiyevdə Qlobal Azure Bootcamp-ın təşkilinə kömək edirəm.
- Dediyim kimi, mən Microsoft Azure MVP-yəm.
- Konfranslarda tez-tez çıxış edirəm. Konfranslarda çıxış etməyi çox sevirəm. Son bir il ərzində təxminən 40 dəfə çıxış edə bildim. Əgər siz Ukrayna, Belarus, Polşa, Bolqarıstan, İsveç, Danimarka, Hollandiya, İspaniyadan keçsəniz və ya Avropadakı başqa bir ölkəni verirsinizsə və ya götürürsünüzsə, o zaman çox mümkündür ki, axınında bulud mövzusu olan konfransa getdiyiniz zaman, Siz məni natiqlər siyahısında görə bilərsiniz.
- Mən də Star Trek fanatıyam.
Bir az Gündəm haqqında danışaq. Gündəliyimiz çox sadədir:
- DevOps-un nə olduğu haqqında danışacağıq. Bunun niyə vacib olduğunu danışaq. Əvvəllər DevOps, CV-də yazdığınız və dərhal +500 dollar maaş aldığınız açar söz idi. İndi maaşınıza +500 dollar almaq üçün məsələn, CV-yə blokçeyn yazmalısınız.
- Və sonra, bunun nə olduğunu bir az başa düşəndə, DevOps təcrübələrinin nə olduğu haqqında danışacağıq. Ancaq ümumiyyətlə DevOps kontekstində deyil, tərtibatçıları maraqlandıra biləcək DevOps təcrübələri haqqında. Onların niyə sizin üçün maraqlı ola biləcəyini sizə deyəcəyəm. Bunu niyə ümumiyyətlə etməli olduğunuzu və bunun sizə daha az ağrı hiss etməsinə necə kömək edə biləcəyini söyləyəcəyəm.
Bir çox insanın göstərdiyi ənənəvi şəkil. Bir çox layihələrdə belə olur. Bu, proqram təminatımızı dəstəkləyən inkişaf və əməliyyat departamentlərimizin olduğu zamandır. Və bu şöbələr bir-biri ilə əlaqə saxlamır.
Ola bilsin, DevOps və əməliyyatlar departamentlərində bunu bu qədər aydın hiss edə bilmirsinizsə, Dev və QA departamentləri ilə bənzətmə apara bilərsiniz. Proqram təminatı hazırlayan insanlar var və tərtibatçıların nöqteyi-nəzərindən pis olan QA insanlar var. Məsələn, mən öz gözəl kodumu depoya təhvil verirəm və orada oturan bir əclaf var ki, bu kodu mənə qaytarır və deyir ki, sizin kodunuz pisdir.
Bütün bunlar insanların bir-biri ilə ünsiyyət qurmaması səbəbindən baş verir. Və bir-birlərinə bəzi paketlər, bəzi tətbiqlər hansısa anlaşılmazlıq divarı vasitəsilə atıb onlarla nəsə etməyə çalışırlar.
Məhz bu divardır ki, DevOps mədəniyyəti məhv etmək üçün nəzərdə tutulmuşdur, yəni. insanları bir-biri ilə ünsiyyət qurmağa məcbur edin və ən azından layihədəki müxtəlif insanların nə etdiyini və işlərinin nə üçün vacib olduğunu başa düşsün.
Biz DevOps haqqında danışanda kimsə sizə deyəcək ki, DevOps layihənin davamlı inteqrasiyası zamanıdır; kimsə deyəcək ki, DevOps, əgər layihə “infrastruktur kod kimi” praktikasını həyata keçirirsə; kimsə deyəcək ki, DevOps-a ilk addım xüsusiyyət budaqlanması, xüsusiyyət bayraqlarıdır.
Əslində, bütün bunlar özünəməxsus şəkildə doğrudur. Ancaq bunlar yalnız bizdə olan son təcrübələrdir. Bu təcrübələrə keçməzdən əvvəl, layihənizdə, şirkətinizdə Dev-Ops metodologiyasının tətbiqinin 3 mərhələsini göstərən bu slaydı nəzərdən keçirməyi təklif edirəm.
Bu slaydın ikinci qeyri-rəsmi adı da var. DevOps-un 3 muşketyorunun nə olduğunu öyrənmək üçün onlayn axtarış edə bilərsiniz. Çox güman ki, bu məqaləni tapa bilərsiniz. Niyə 3 Musketyor? Aşağıda deyilir: insanlar, proseslər və məhsullar, yəni. PPP – Porthos, Porthos və Porthos. Budur DevOps-un 3 muşketyoru. Bu məqalədə bunun nə üçün vacib olduğu və bunun nədən ibarət olduğu daha ətraflı təsvir edilmişdir.
DevOps mədəniyyətini tətbiq etməyə başladığınız zaman onun aşağıdakı ardıcıllıqla həyata keçirilməsi çox vacibdir.
Əvvəlcə insanlarla danışmaq lazımdır. İnsanlara bunun nə olduğunu və ondan necə fayda əldə edə biləcəklərini izah etməlisiniz.
Konfransımız DotNet Fest adlanır. Təşkilatçıların mənə dediyi kimi, biz burada əsasən tərtibatçıların auditoriyasını dəvət etmişik, ona görə də ümid edirəm ki, zalda olan insanların əksəriyyəti inkişafla məşğuldur.
İnsanlar haqqında danışacağıq, tərtibatçıların hər gün nə etmək istədiklərini danışacağıq. Ən çox nə istəyirlər? Onlar yeni kod yazmaq, yeni yaradılmış çərçivələrdən istifadə etmək, yeni funksiyalar yaratmaq istəyirlər. Tərtibatçılar ən az nə istəyirlər? Köhnə səhvləri düzəldin. Ümid edirəm mənimlə razılaşırsınız. Tərtibatçıların istədiyi budur. Onlar yeni funksiyalar yazmaq istəyirlər, səhvləri düzəltmək istəmirlər.
Müəyyən bir tərtibatçının istehsal etdiyi səhvlərin sayı qollarının nə qədər düz olmasından və omba ciblərindən deyil, çiyinlərindən nə qədər böyüdüyündən asılıdır. Ancaq buna baxmayaraq, böyük bir layihəmiz olduqda, bəzən elə olur ki, hər şeyi izləmək mümkün olmur, ona görə də bizə daha stabil və keyfiyyətli kod yazmağa kömək edəcək bəzi yanaşmalardan istifadə etmək yaxşı olardı.
QA ən çox nə istəyir? Onların zalda olub-olmadığını bilmirəm. QA istədiyimi söyləmək mənim üçün çətindir, çünki heç vaxt belə olmamışam. Və uşaqlara heç bir incimə, deyəcəklər ki, ümid edirəm ki, heç vaxt etməyəcəyəm. Amma onların işlərini mənasız və faydasız hesab etdiyim üçün yox, özümü bu işi səmərəli görə bilən insan hesab etmədiyim üçün bunu etməyə cəhd belə etməyəcəyəm. Ancaq başa düşdüyüm kimi, QA-nın ən çox sevmədiyi şey səhərlər işləmək, davamlı olaraq bir növ reqressiya testləri keçirmək, 3 sprint əvvəl tərtibatçılara bildirdikləri eyni səhvlərə addım atmaq və: “Nə vaxt olacaqsınız? , Müsyö D 'Artagnan, bu səhvi düzəldin.' Müsyö d'Artagnan ona cavab verir: "Bəli, bəli, bəli, mən bunu artıq düzəltmişəm". Və necə olur ki, mən bir səhvi düzəltdim və yol boyu 5 etdim.
İstehsalda bu həlli dəstəkləyən insanlar bu həllin səhvsiz işləməsini istəyirlər ki, hər cümə günü bütün normal insanlar bara gedəndə serveri yenidən yükləməli olmasınlar. Tərtibatçılar cümə günü yerləşdirildi, adminlər şənbə gününə qədər oturur, bu yerləşdirməni işə salmağa və düzəltməyə çalışırlar.
İnsanlara onların eyni problemlərin həllinə yönəldiyini izah etdikdə, proseslərin rəsmiləşdirilməsinə keçə bilərsiniz. Bu çox vacibdir. Niyə? Çünki biz “rəsmiləşdirmə” dedikdə, sizin proseslərinizin ən azı bir yerdə salfetdə necə baş verdiyini təsvir etməyiniz vacibdir. Siz başa düşməlisiniz ki, əgər siz, məsələn, QA mühitinə və ya istehsal mühitinə yerləşdirirsinizsə, bu, həmişə bu qaydada baş verir; bu mərhələlərdə biz, məsələn, avtomatik vahid testləri və UI testlərini həyata keçiririk. Yerləşdirmədən sonra yerləşdirmənin yaxşı və ya pis getdiyini yoxlayırıq. Ancaq istehsala yerləşdirdiyiniz zaman təkrar-təkrar təkrarlanmalı olan hərəkətlərin dəqiq siyahısı artıq var.
Və yalnız prosesləriniz rəsmiləşdirildikdə, bu prosesləri avtomatlaşdırmağa kömək edəcək məhsulları seçməyə başlayırsınız.
Təəssüf ki, mən çox vaxt bunun tərsinə baş verdiyini görürəm. Kimsə "DevOps" sözünü eşidən kimi dərhal Jenkins quraşdırmağı təklif edirlər, çünki Jenkins-i quraşdıran kimi DevOps-a sahib olacağına inanırlar. Jenkins-i quraşdırdılar, Jenkins saytındakı "Necə etməli" məqalələrini oxudular, prosesləri bu Necə etməli məqalələrinə daxil etməyə çalışdılar, sonra insanların yanına gəldilər və insanları əyərək dedilər ki, kitabda bunu belə etmək lazımdır, ona görə də biz bunu belə edirik.
Bu Jenkinsin pis alət olması deyil. Mən heç bir şəkildə bunu demək istəmirəm. Ancaq bu məhsullardan yalnız biridir. Hansı məhsuldan istifadə edəcəyiniz son qərarınız olmalıdır və heç bir halda ilkiniz olmalıdır. Məhsulunuz mədəniyyət və yanaşmaların tətbiqi ilə idarə edilməməlidir. Bunu başa düşmək çox vacibdir, buna görə də bu slaydda çox vaxt sərf edirəm və bütün bunları bu qədər uzun müddət izah edirəm.
Ümumiyyətlə DevOps təcrübələri haqqında danışaq. Onlar nədirlər? Fərq nədir? Onları necə sınamaq olar? Onlar niyə vacibdir?
Eşitdiyiniz ilk təcrübə Davamlı İnteqrasiya adlanır. Ola bilsin ki, layihədə kiminsə Davamlı İnteqrasiya (CI) var.
Ən böyük problem odur ki, mən tez-tez bir insandan soruşanda: "Layihədə CI varmı?" və deyir: "Bəli," nə etdiyini soruşduqda, o, mənə tamamilə avtomatlaşdırma prosesini təsvir edir. Bu tamamilə doğru deyil.
Əslində, CI təcrübəsi sadəcə müxtəlif insanların yazdıqları kodu bir növ vahid kod bazasına inteqrasiya etməyə yönəlmişdir. Hamısı budur.
CI ilə yanaşı, adətən digər təcrübələr var - Davamlı Yerləşdirmə, Release Management, lakin biz bu barədə daha sonra danışacağıq.
CI özü bizə deyir ki, müxtəlif insanlar kod yazırlar və bu kod davamlı olaraq vahid kod bazasına inteqrasiya edilməlidir.
Bu bizə nə verir və nə üçün vacibdir? Əgər bizdə DotNet varsa, bu yaxşıdır, bu tərtib edilmiş dildir, biz tətbiqimizi tərtib edə bilərik. Əgər tərtib edirsə, bu, artıq yaxşı bir əlamətdir. Bu hələ heç nə demək deyil, lakin bu, ən azı tərtib edə biləcəyimiz ilk yaxşı işarədir.
Sonra bəzi testlər keçirə bilərik, bu da ayrıca bir təcrübədir. Testlərin hamısı yaşıldır - bu, ikinci yaxşı əlamətdir. Amma yenə deyirəm, bu heç nə demək deyil.
Bəs niyə bunu edərdin? Bu gün haqqında danışacağım bütün təcrübələr təxminən eyni dəyər daşıyır, yəni təxminən eyni faydaları daşıyır və təxminən eyni şəkildə ölçülür.
Birincisi, çatdırılmanı sürətləndirməyə imkan verir. Bu, çatdırılmanı sürətləndirməyə necə imkan verir? Kod bazamızda bəzi yeni dəyişikliklər etdikdə dərhal bu kodla nəsə etməyə cəhd edə bilərik. Cümə axşamının gəlməsini gözləmirik, çünki cümə axşamı onu QA Environment-ə buraxırıq, biz bunu burada və burada edirik.
Sizə həyatımdan bir kədərli hekayə danışacağam. Çoxdan idi, mən hələ gənc və yaraşıqlı idim. İndi mən artıq gənc, gözəl və ağıllı və təvazökaram. Bir müddət əvvəl bir layihədə idim. Təxminən 30 tərtibatçıdan ibarət böyük bir komandamız var idi. Və bizim təxminən 10 il ərzində inkişaf edən böyük, böyük Müəssisə layihəmiz var idi. Və bizim müxtəlif filiallarımız var idi. Anbarda tərtibatçıların getdiyi bir filialımız var idi. Və kodun istehsalda olan versiyasını göstərən bir filial var idi.
İstehsal bölməsi tərtibatçılar üçün mövcud olan filialdan 3 ay geri qaldı. Bu nə deməkdir? Bu o deməkdir ki, bir yerdə tərtibatçıların günahı ucbatından istehsala gedən bir səhv olan kimi, buna icazə verdiklərinə görə və QA-nın günahına görə, ona baxdıqları üçün, bu o deməkdir ki, mən İstehsal üçün düzəliş tapşırığı, sonra 3 ay əvvəl kod dəyişikliklərimi geri qaytarmalıyam. Mən 3 ay əvvəl olanları xatırlamalı və orada düzəltməyə çalışmalıyam.
Əgər bu təcrübəni hələ yaşamamısınızsa, onu ev layihənizdə sınaya bilərsiniz. Əsas odur ki, bunu kommersiyada sınamayın. Bir neçə sətir kod yazın, altı ay ərzində onları unudun və sonra geri qayıdın və bu kod sətirlərinin nə ilə əlaqəli olduğunu və onları necə düzəldə və ya optimallaşdıra biləcəyinizi tez izah etməyə çalışın. Bu, çox, çox maraqlı təcrübədir.
Əgər Davamlı İnteqrasiya təcrübəmiz varsa, o zaman bu, kodumu yazan kimi onu bir sıra avtomatlaşdırılmış alətlərlə burada və elə indi yoxlamağa imkan verir. Bu, mənə tam şəkil verməyə bilər, lakin buna baxmayaraq, ən azı bəzi riskləri aradan qaldıracaq. Hər hansı bir potensial səhv varsa, mən bu barədə indi, yəni bir neçə dəqiqədən sonra biləcəyəm. 3 ayı geri çəkməyə ehtiyacım olmayacaq. Mənə yalnız 2 dəqiqə geri çəkilməli olacaq. Yaxşı bir qəhvə maşınının hətta 2 dəqiqə ərzində qəhvə dəmləməyə vaxtı olmayacaq, belə ki, bu, olduqca gözəldir.
Bu, hər bir layihədə dəfələrlə təkrarlana biləcəyi dəyərə malikdir, yəni. yalnız onu quraşdırdığınız biri deyil. Siz həm təcrübənin özünü təkrarlaya bilərsiniz, həm də layihədə etdiyiniz hər yeni dəyişiklik üçün CI özü təkrarlanacaq. Bu, resursları optimallaşdırmağa imkan verir, çünki komandanız daha səmərəli işləyir. Artıq 3 ay əvvəl işlədiyiniz koddan sizə səhv gəldiyi vəziyyət olmayacaq. Siz oturub ilk iki saatı o zaman nə baş verdiyini anlamağa və nəyisə düzəltməyə başlamazdan əvvəl kontekstin mahiyyətinə daxil olmağa çalışdığınız zaman artıq kontekst dəyişikliyinə malik olmayacaqsınız.
Bu təcrübənin uğur və ya uğursuzluğunu necə ölçə bilərik? Əgər CI layihəsində həyata keçirdiklərimizi böyük patrona hesabat versəniz, o, blah blah bla eşidir. Biz bunu həyata keçirdik, bəs, bəs niyə, bizə nə gətirdi, onu necə ölçürük, nə dərəcədə düzgün və ya səhv həyata keçiririk?
Birincisi odur ki, CI sayəsində biz daha tez-tez və daha tez-tez yerləşdirə bilərik, çünki kodumuz potensial olaraq daha sabitdir. Eyni şəkildə, bir səhv tapmaq üçün vaxtımız azalır və bu səhvi düzəltmək üçün vaxtımız məhz burada və indi sistemdən cavab aldığımız üçün azalır, kodumuzda nə səhvdir.
Bizdə olan başqa bir təcrübə, ən çox CI təcrübəsi ilə birlikdə gələn Avtomatlaşdırma Testi təcrübəsidir. Əl-ələ verirlər.
Burada nəyi başa düşmək vacibdir? Testlərimizin fərqli olduğunu başa düşmək vacibdir. Və hər bir avtomatlaşdırılmış test öz problemlərini həll etməyə yönəldilmişdir. Bizdə, məsələn, modulu ayrıca sınaqdan keçirməyə imkan verən vahid testlərimiz var, yəni. Vakuumda necə işləyir? Bu yaxşıdır.
Müxtəlif modulların bir-biri ilə necə inteqrasiya etdiyini anlamağa imkan verən inteqrasiya testlərimiz də var. Bu da yaxşıdır.
UI ilə işin müştəri tərəfindən müəyyən edilmiş müəyyən tələblərə nə dərəcədə cavab verdiyini yoxlamağa imkan verən UI avtomatlaşdırma testlərimiz ola bilər və s.
Çalışdığınız xüsusi testlər onları nə qədər tez-tez yerinə yetirdiyinizə təsir edə bilər. Vahid testləri adətən qısa və kiçik yazılır. Və onlar müntəzəm olaraq işə salına bilər.
UI avtomatlaşdırma testlərindən danışırıqsa, layihəniz kiçik olsa yaxşıdır. UI avtomatlaşdırma testləriniz kifayət qədər vaxt apara bilər. Ancaq adətən UI avtomatlaşdırma testi böyük bir layihədə bir neçə saat çəkən bir şeydir. Və bir neçə saat olsa yaxşıdır. Yeganə odur ki, hər quruluş üçün onları işə salmağın mənası yoxdur. Onları gecə işlətməyin mənası var. Səhər hamı işə gələndə: həm test edənlər, həm də tərtibatçılar, bir növ hesabat aldılar ki, biz gecə UI avtotestini keçirdik və bu nəticələri əldə etdik. Və burada, məhsulunuzun bəzi tələblərə cavab verdiyini yoxlayacaq serverin bir saatlıq işi, yemək və təşəkkür üçün işləyən kiçik QA mühəndisi olsa belə, eyni QA mühəndisinin bir saatlıq işindən qat-qat ucuz olacaq. Bununla belə, maşının bir saat işləməsi daha ucuz olacaq. Buna görə də ona sərmayə qoymağın mənası var.
Üzərində işlədiyim başqa bir layihəm var. Bu layihədə iki həftəlik sprintlərimiz var idi. Layihə böyük idi, maliyyə sektoru üçün vacib idi və səhvə yol vermək olmazdı. Və iki həftəlik sprintdən sonra inkişaf dövrü daha 4 həftə davam edən sınaq prosesi ilə izlənildi. Faciənin miqyasını təsəvvür etməyə çalışın. Biz iki həftə ərzində kod yazırıq, sonra onu CodeFreeze ilə edirik, proqramın yeni versiyasına paketləyirik və test edənlərə yayırıq. Testçilər onu başqa 4 həftə sınaqdan keçirirlər, yəni. Onlar sınaqdan keçirərkən bizim onlar üçün daha iki versiya hazırlamağa vaxtımız var. Bu, həqiqətən də acınacaqlı haldır.
Biz onlara dedik ki, daha məhsuldar olmaq istəyirsinizsə, Avtomatlaşdırılmış Test təcrübələrini həyata keçirməyiniz məntiqlidir, çünki bu, sizi elə indi incidir.
Davamlı Yerləşdirmə təcrübəsi. Əla, siz tikintini bitirdiniz. Bu artıq yaxşıdır. Kodunuz tərtib edilib. İndi bu quruluşu bəzi mühitlərdə yerləşdirmək yaxşı olardı. Tərtibatçılar üçün bir mühitdə deyək.
Niyə vacibdir? Birincisi, yerləşdirmə prosesinin özü ilə nə qədər uğurlu olduğunuza baxa bilərsiniz. Mən belə layihələrlə rastlaşdım, soruşanda: “Tətbiqin yeni versiyasını necə yerləşdirirsiniz?”, uşaqlar mənə deyirlər: “Biz onu yığırıq və zip arxivinə yığırıq. Adminə poçtla göndəririk. Admin bu arxivi yükləyir və genişləndirir. Və bütün ofis serverin yeni versiyanı götürməsi üçün dua etməyə başlayır.
Sadə bir şeylə başlayaq. Məsələn, onlar CSS-ni arxivə qoymağı unutdular və ya java-skript faylının adındakı heşteqi dəyişdirməyi unutdular. Və biz serverə sorğu göndərəndə brauzer artıq bu java-skript faylının olduğunu düşünür və onu yükləməmək qərarına gəlir. Və köhnə versiya var idi, bir şey çatışmırdı. Ümumiyyətlə, çoxlu problemlər ola bilər. Buna görə də, Davamlı Yerləşdirmə təcrübəsi sizə ən azı təmiz istinad şəklini çəkib onu tamamilə təmiz yeni mühitə yükləsəniz nə baş verəcəyini sınamağa imkan verir. Bunun hara apardığını görə bilərsiniz.
Həmçinin, kodu bir-biriniz arasında inteqrasiya etdikdə, yəni. komanda arasında bu, UI-də necə göründüyünü də görməyə imkan verir.
Çoxlu vanil java-skriptinin istifadə edildiyi yerlərdə yaranan problemlərdən biri iki tərtibatçının pəncərə obyektində eyni adlı dəyişəni tələsik elan etməsidir. Və sonra, şansınızdan asılı olaraq. Kimin java-skript faylı ikinci çıxarılsa, digərinin dəyişikliklərinin üzərinə yazacaq. Həm də çox həyəcanlıdır. Siz daxil olursunuz: bir şey bir insan üçün işləyir, digəri başqası üçün işləmir. Və hamısı istehsalda görünəndə "gözəl" olur.
Növbəti təcrübəmiz Avtomatik Bərpa təcrübəsidir, yəni tətbiqin əvvəlki versiyasına qayıtmaqdır.
Bu tərtibatçılar üçün niyə vacibdir? Hələ də kompüterlərin böyük, proqramların isə kiçik olduğu uzaq, uzaq 90-cı illəri xatırlayanlar var. Veb inkişafının yeganə yolu PHP vasitəsilə idi. Bu, PHP-nin pis bir dil olması deyil, baxmayaraq ki.
Amma problem başqa idi. Biz php saytımızın yeni versiyasını yerləşdirəndə onu necə yerləşdirdik? Çox vaxt Far Manager və ya başqa bir şey açdıq. Və bu faylları FTP-yə yüklədim. Və birdən anladıq ki, kiçik, kiçik səhvimiz var, məsələn, nöqtəli vergül qoymağı unutmuşuq və ya verilənlər bazası üçün parolu dəyişməyi unutmuşuq və yerli hostda olan verilənlər bazası üçün parol var. Və biz FTP-yə tez qoşulmaq və faylları elə orada redaktə etmək qərarına gəlirik. Bu sadəcə yanğındır! Bu, 90-cı illərdə məşhur idi.
Ancaq təqvimə baxmamısınızsa, 90-cı illər təxminən 30 il əvvəl idi. İndi hər şey bir az fərqli şəkildə baş verir. Onlar sizə dedikdə faciənin miqyasını təsəvvür etməyə çalışın: “Biz istehsalata getdik, amma orada nəsə səhv oldu. Budur sizin FTP giriş və parolunuz, istehsala qoşulun və onu orada tez bir zamanda düzəldin." Əgər siz Chuck Norrissinizsə, bu işləyəcək. Əks təqdirdə, bir səhvi düzəltsəniz, daha 10 səhv edə biləcəyinizi riskə atırsınız. Məhz buna görə əvvəlki versiyaya qayıtmaq təcrübəsi sizə çox şey əldə etməyə imkan verir.
Pis bir şey hardasa baş vermiş olsa belə, pisdir, amma ölümcül deyil. Siz əvvəlki versiyaya qayıda bilərsiniz. Bu terminologiyada onu qəbul etmək daha asan olarsa, onu ehtiyat adlandırın. Siz bu əvvəlki versiyaya qayıda bilərsiniz və istifadəçilər hələ də məhsulunuzla işləyə biləcəklər və sizin adekvat bufer vaxtınız olacaq. Sakitcə, tələsmədən, bütün bunları götürüb yerli olaraq sınaqdan keçirə, düzəldə və sonra yeni versiya yükləyə bilərsiniz. Bunu etmək həqiqətən məntiqlidir.
İndi gəlin əvvəlki iki praktikanı bir şəkildə birləşdirməyə çalışaq. Biz Release Management adlı üçüncü alacağıq.
Klassik formada Davamlı Yerləşdirmə haqqında danışarkən deyirik ki, biz depodan hansısa filialdan kodu çəkib, onu tərtib edib yerləşdirməliyik. Bizdə eyni mühit olsa yaxşıdır. Əgər bir neçə mühitimiz varsa, bu o deməkdir ki, kodu hər dəfə, hətta eyni öhdəlikdən də çəkməliyik. Biz onu hər dəfə çıxaracağıq, hər dəfə quracağıq və yeni mühitə yerləşdirəcəyik. Birincisi, bu vaxtdır, çünki böyük bir layihəniz varsa və 90-cı illərdən gəlmişsinizsə, bir neçə saat çəkə bilər.
Bundan əlavə, başqa bir kədər var. Hətta eyni maşın üzərində qurduğunuz zaman eyni mənbələri quracaqsınız, hələ də bu maşının son qurulma zamanı olduğu vəziyyətdə olduğuna dair heç bir zəmanətiniz yoxdur.
Tutaq ki, kimsə gəlib DotNet-i sizin üçün yenilədi və ya əksinə, kimsə nəyisə silmək qərarına gəldi. Və sonra sizdə koqnitiv dissonans var ki, bu öhdəlikdən iki həftə əvvəl biz bir tikinti qururduq və hər şey yaxşı idi, amma indi eyni maşın, eyni öhdəlik, eyni kod kimi görünür ki, qurmağa çalışırıq, amma işləmir. . Bununla uzun müddət məşğul olacaqsınız və bunu başa düşəcəyiniz bir həqiqət deyil. Ən azından əsəblərinizi çox korlayacaqsınız.
Buna görə də, Release Management təcrübəsi artefakt anbarı və ya qalereya və ya kitabxana adlanan əlavə abstraksiya təqdim etməyi təklif edir. İstədiyiniz kimi adlandıra bilərsiniz.
Əsas fikir odur ki, orada bir növ öhdəlik götürdükdən sonra, məsələn, fərqli mühitlərimizə yerləşdirməyə hazır olduğumuz bir filialda, bu öhdəlikdən ərizələr və bu proqram üçün lazım olan hər şeyi toplayırıq, onu qablaşdırırıq. zip arxivinə daxil edin və bəzi etibarlı yaddaşda saxlayın. Və bu yaddaşdan biz bu zip arxivini istənilən vaxt əldə edə bilərik.
Sonra onu götürürük və avtomatik olaraq dev mühitinə yerləşdiririk. Orada yarışırıq və hər şey yaxşı olarsa, o zaman səhnəyə çıxırıq. Hər şey qaydasındadırsa, o zaman biz eyni arxivi istehsala, eyni ikili faylları, tam olaraq bir dəfə tərtib edirik.
Bundan əlavə, belə bir qalereyamız olduqda, əvvəlki versiyaya geri qayıtmaq haqqında danışarkən sonuncu slaydda qeyd etdiyimiz riskləri həll etməyə kömək edir. Təsadüfən səhv bir şey yerləşdirmisinizsə, həmişə bu qalereyadan hər hansı digər əvvəlki versiyanı götürə və eyni şəkildə onu bu mühitlərə yerləşdirə bilərsiniz. Bu, bir şey səhv olarsa, əvvəlki versiyaya asanlıqla qayıtmağa imkan verir.
Başqa bir gözəl təcrübə var. Siz və mən hamımız başa düşürük ki, tətbiqlərimizi əvvəlki versiyaya geri qaytardığımız zaman bu, əvvəlki versiyanın infrastrukturuna da ehtiyacımız olduğu anlamına gələ bilər.
Virtual infrastrukturdan danışanda bir çox insanlar bunun adminlər tərəfindən qurulan bir şey olduğunu düşünür. Tətbiqinizin yeni versiyasını sınaqdan keçirmək istədiyiniz yeni bir server əldə etmək istəyirsinizsə, adminlərə və ya devoplara bilet yazmalısınız. Bunun üçün devops 3 həftə çəkəcək. Və 3 həftədən sonra sizə deyəcəklər ki, biz sizin üçün bir nüvəli, iki giqabayt operativ yaddaşa və DotNet olmayan Windows serverinə malik virtual maşın quraşdırmışıq. Siz deyirsiniz: "Ancaq mən DotNet istəyirdim." Onlar: "Yaxşı, 3 həftədən sonra qayıdın."
İdeya ondan ibarətdir ki, İnfrastrukturdan Kod təcrübələri kimi istifadə etməklə siz virtual infrastrukturunuza başqa resurs kimi baxa bilərsiniz.
Ola bilsin ki, hər hansı biriniz DotNet-də proqramlar hazırlayırsa, Entity Framework adlı kitabxana haqqında eşitmiş ola bilərsiniz. Və hətta eşitmiş ola bilərsiniz ki, Entity Framework Microsoft-un fəal şəkildə irəli sürdüyü yanaşmalardan biridir. Verilənlər bazası ilə işləmək üçün bu, Code First adlı bir yanaşmadır. Bu, verilənlər bazanızın necə görünməsini istədiyiniz kodda təsvir etdiyiniz zamandır. Və sonra tətbiqi yerləşdirirsiniz. Verilənlər bazasına qoşulur, hansı cədvəllərin var, hansı cədvəllərin olmadığını özü müəyyənləşdirir və sizə lazım olan hər şeyi yaradır.
Eyni şeyi infrastrukturunuzla da edə bilərsiniz. Layihə üçün verilənlər bazasına ehtiyacınız olub-olmamağınız və ya layihə üçün Windows serverinə ehtiyacınız olub-olmaması arasında heç bir fərq yoxdur. Bu, sadəcə bir resursdur. Və bu resursun yaradılmasını avtomatlaşdıra bilərsiniz, bu resursun konfiqurasiyasını avtomatlaşdıra bilərsiniz. Müvafiq olaraq, hər dəfə hansısa yeni konsepsiyanı, hansısa yeni yanaşmanı sınamaq istəyəndə devops-a bilet yazmağa ehtiyac qalmayacaq, sadəcə olaraq hazır şablonlardan, hazır skriptlərdən özünüz üçün təcrid olunmuş infrastruktur yerləşdirə və onu həyata keçirə bilərsiniz. bütün təcrübələriniz var. Siz bunu silə, bəzi nəticələr əldə edə və bu barədə əlavə məlumat verə bilərsiniz.
Mövcud olan və eyni zamanda vacib olan, lakin az adamın istifadə etdiyi növbəti təcrübə Tətbiq Performansının Monitorinqidir.
Tətbiq Performansının Monitorinqi haqqında yalnız bir şey demək istədim. Bu praktikada ən vacib olan nədir? Tətbiq Performansının Monitorinqi mənzilin təmiri ilə eynidir. Bu, son vəziyyət deyil, bir prosesdir. Bunu mütəmadi olaraq etməlisiniz.
Yaxşı bir şəkildə, demək olar ki, hər bir quruluşda Tətbiq Performansının Monitorinqini aparmaq yaxşı olardı, baxmayaraq ki, başa düşdüyünüz kimi, bu həmişə mümkün deyil. Lakin, ən azı, hər buraxılış üçün həyata keçirilməlidir.
Niyə vacibdir? Çünki birdən-birə performansınız azalırsa, bunun səbəbini aydın şəkildə başa düşməlisiniz. Əgər komandanızın, məsələn, iki həftəlik sprintləri varsa, o zaman ən azı iki həftədə bir dəfə proqramınızı aydın şəkildə sabitlənmiş prosessor, RAM, disklər və s. olan ayrı serverə yerləşdirməlisiniz. Və eyni performans testlərini həyata keçirin. . Nəticəni alırsınız. Əvvəlki sprintdən necə dəyişdiyinə baxın.
Əgər azalmanın haradasa kəskin şəkildə aşağı düşdüyünü öyrənsəniz, bu, son iki həftə ərzində baş verən dəyişikliklərə görə baş verdiyini ifadə edəcək. Bu, problemi daha tez müəyyən etməyə və həll etməyə imkan verəcəkdir. Yenə deyirəm, bunlar təxminən eyni ölçülərdir ki, onun köməyi ilə nə qədər müvəffəqiyyətlə etdiyinizi ölçə bilərsiniz.
Növbəti təcrübəmiz Konfiqurasiya İdarəetmə təcrübəsidir. Bunu ciddi qəbul edənlər çox azdır. Amma inanın ki, bu əslində çox ciddi bir şeydir.
Bu yaxınlarda gülməli bir hekayə var idi. Uşaqlar yanıma gəlib dedilər: “Bizə ərizəmizin təhlükəsizlik auditini aparmağa kömək edin”. Uzun müddət birlikdə kodlara baxdıq, tətbiqdən danışdılar, diaqramlar çəkdilər. Və artı və ya mənfi hər şey məntiqli, başa düşülən, təhlükəsiz idi, amma bir AMA var idi! Onların mənbə nəzarətində konfiqurasiya faylları, o cümlədən IP verilənlər bazası ilə istehsaldan olanlar, bu verilənlər bazalarına qoşulmaq üçün giriş və parollar və s.
Mən deyirəm: “Uşaqlar, tamam, istehsal mühitinizi firewall ilə bağladınız, lakin mənbə nəzarətində istehsal verilənlər bazası üçün giriş və parolunuz olması və hər hansı bir tərtibatçının onu oxuya bilməsi artıq böyük bir təhlükəsizlik riskidir. . Tətbiqinizin kod nöqteyi-nəzərindən nə qədər təhlükəsiz olmasından asılı olmayaraq, onu mənbə nəzarətində buraxsanız, heç bir yerdə heç bir auditdən keçməyəcəksiniz.” Bu elə mənim haqqında danışdığım mövzudur.
Konfiqurasiyanın idarə edilməsi. Fərqli mühitlərdə fərqli konfiqurasiyalarımız ola bilər. Məsələn, QA, demo, istehsal mühiti və s. üçün verilənlər bazası üçün fərqli giriş və parollarımız ola bilər.
Bu konfiqurasiya da avtomatlaşdırıla bilər. Həmişə proqramın özündən ayrı olmalıdır. Niyə? Tətbiqi bir dəfə qurduğunuz və sonra SQL serverinə filan İP və ya filan İP vasitəsilə qoşulmağınızın vecinə olmadığı üçün o, eyni işləməlidir. Buna görə də, birdən sizlərdən biri hələ də koddakı əlaqə sətirini kodlaşdırırsa, o zaman yadda saxla ki, mən səni tapacağam və mənimlə eyni layihədə özünüzü tapsanız, cəzalandıracağam. Bu, həmişə ayrıca konfiqurasiyada, məsələn, web.config-də yerləşdirilir.
Və bu konfiqurasiya artıq ayrı-ayrılıqda idarə olunur, yəni bu, bir tərtibatçı və idarəçinin gəlib eyni otaqda otura biləcəyi andır. Və tərtibatçı deyə bilər: “Bax, mənim tətbiqimin ikili faylları buradadır. Onlar işləyir. Proqramın işləməsi üçün verilənlər bazası lazımdır. Burada ikili faylların yanında bir fayl var. Bu faylda bu sahə giriş üçün cavabdehdir, bu parol üçün, bu IP üçün. İstənilən yerdə yerləşdirin”. Və admin üçün sadə və aydındır. O, bu konfiqurasiyanı idarə etməklə onu həqiqətən hər yerdə yerləşdirə bilər.
Haqqında danışmaq istədiyim son təcrübə buludlarla çox əlaqəli olan bir təcrübədir. Buludda işləsəniz, maksimum effekt verir. Bu, mühitinizin avtomatik silinməsidir.
Bilirəm ki, bu konfransda işlədiyim komandalardan bir neçə nəfər var. Çalışdığım bütün komandalarla bu təcrübədən istifadə edirik.
Niyə? Əlbəttə ki, hər bir tərtibatçının 24/7 işləyəcək virtual maşını olsa əla olardı. Ancaq bəlkə də bu sizin üçün bir xəbərdir, bəlkə də diqqət etmədiniz, amma tərtibatçının özü 24/7 işləmir. Tərtibatçı adətən gündə 8 saat işləyir. İşə erkən gəlsə belə, idman zalına getdiyi böyük bir nahar var. Tərtibatçı həqiqətən bu resurslardan istifadə edəndə gündə 12 saat olsun. Qanunvericiliyimizə görə həftədə 5 gündən 7-i iş günü hesab olunur.
Müvafiq olaraq, iş günləri bu maşın 24 saat deyil, yalnız 12 saat işləməli, həftə sonları isə bu maşın ümumiyyətlə işləməməlidir. Hər şeyin çox sadə olduğu görünür, amma burada nə demək vacibdir? Bu sadə təcrübəni bu əsas cədvəldə həyata keçirməklə, bu mühitlərin saxlanması xərclərini 70% azaltmağa imkan verir, yəni siz inkişaf etdirmə, QA, demo, mühitin qiymətini götürdünüz və onu 3-ə böldünüz.
Sual yaranır ki, qalan pulla nə etmək lazımdır? Məsələn, tərtibatçılar ReSharper almamışlarsa, almalıdırlar. Və ya bir kokteyl təşkil edin. Əgər əvvəllər həm dev, həm də QA-nın otladığı bir mühitiniz varsa və bu da belədirsə, indi təcrid olunacaq 3 fərqli mühit yarada bilərsiniz və insanlar bir-birinə qarışmayacaqlar.
Davamlı performans ölçmə ilə slaydla bağlı olaraq, layihədə verilənlər bazasında 1 qeydimiz varsa, iki ay sonra bir milyon varsa, performansı necə müqayisə edə bilərik? Səbəbini necə başa düşmək olar və performansı ölçməyin mənası nədir?
Bu yaxşı sualdır, çünki siz həmişə eyni resurslarda performansı ölçməlisiniz. Yəni, siz yeni kodu yayırsınız, performansı yeni kodda ölçürsünüz. Məsələn, müxtəlif performans ssenarilərini sınaqdan keçirməlisiniz, tutaq ki, 1 istifadəçinin olduğu və verilənlər bazası ölçüsünün 000 gigabayt olduğu yüngül yükdə tətbiqin necə işlədiyini yoxlamaq istəyirsiniz. Siz onu ölçdünüz və rəqəmləri aldınız. Sonra başqa bir ssenari götürürük. Məsələn, 5 istifadəçi, verilənlər bazası ölçüsü 5 terabayt. Nəticələri aldıq və onları xatırladıq.
Burada vacib olan nədir? Burada vacib olan odur ki, ssenaridən, məlumatların həcmindən, eyni vaxtda istifadəçilərin sayından və s.-dən asılı olaraq müəyyən məhdudiyyətlərlə üzləşə bilərsiniz. Məsələn, şəbəkə kartının limitinə və ya sabit diskin limitinə və ya prosessor imkanlarının həddinə qədər. Anlamağınız üçün vacib olan budur. Müxtəlif ssenarilərdə müəyyən məhdudiyyətlərlə qarşılaşırsınız. Və siz onları vurduğunuz zaman rəqəmləri başa düşməlisiniz.
Xüsusi test mühitində performansın ölçülməsindən danışırıq? Yəni bu istehsal deyil?
Bəli, bu istehsal deyil, bu, əvvəlki ölçmələrlə müqayisə etmək üçün həmişə eyni olan bir sınaq mühitidir.
Anladım təşəkkürlər!
Sual yoxdursa, məncə, bitirə bilərik. Çox sağ ol!
Mənbə: www.habr.com