Gəlin CI alətləri və CI-nin niyə tamamilə fərqli şeylər olduğunu müzakirə edək.
CI hansı ağrıları həll etmək niyyətindədir, ideya haradan gəldi, onun işlədiyinə dair ən son təsdiqləmələr hansılardır, yalnız Jenkins quraşdırmayan bir təcrübəniz olduğunu necə başa düşmək olar.
Davamlı İnteqrasiya haqqında hesabat hazırlamaq ideyası bir il əvvəl, müsahibələrə gedəndə və iş axtararkən ortaya çıxdı. 10-15 şirkətlə danışdım, onlardan yalnız biri CI-nin nə olduğunu aydın şəkildə cavablandıra bildi və bunun onlarda olmadığını necə başa düşdüklərini izah edə bildi. Qalanları Jenkins haqqında anlaşılmaz cəfəngiyatdan danışırdılar :) Yaxşı, bizdə Jenkins var, o, qurur, CI! Hesabat zamanı Davamlı İnteqrasiyanın əslində nə olduğunu və Jenkins və buna bənzər alətlərin nə üçün bununla çox zəif əlaqədə olduğunu izah etməyə çalışacağam.
Beləliklə, CI sözünü eşidəndə ağlınıza nə gəlir? Əksər insanlar Jenkins, Gitlab CI, Travis və s. haqqında düşünəcəklər.
Google-da axtarsaq belə, o bizə bu vasitələri verəcək.
Sorğu ilə tanışsınızsa, alətləri sadaladıqdan dərhal sonra onlar sizə deyəcəklər ki, CI siz öhdəliyin Pull Request-də testlər qurduğunuz və işlətdiyiniz zamandır.
Davamlı İnteqrasiya alətlər haqqında deyil, filialda testlərlə montajlar haqqında deyil! Davamlı İnteqrasiya yeni kodun çox tez-tez inteqrasiyası təcrübəsidir və ondan istifadə etmək üçün Jenkins, GitLab və s.-nin hasarlanmasına ehtiyac yoxdur.
Tam hüquqlu CI-nin nəyə bənzədiyini anlamazdan əvvəl gəlin əvvəlcə onu düşünən insanların kontekstinə dalaq və onların həll etməyə çalışdıqları ağrıları hiss edək.
Və bir komanda olaraq birlikdə işləməyin ağrısını həll etdilər!
Tərtibatçıların komandalarda inkişaf edərkən qarşılaşdıqları çətinliklərə dair nümunələrə baxaq. Burada bir layihəmiz, git-də master filialımız və iki tərtibatçımız var.
Və hamının çoxdan öyrəşdiyi kimi işə getdilər. İşlərin böyük sxemində bir tapşırıq götürdük, bir xüsusiyyət bölməsi yaratdıq və kodu yazdıq.
Biri xüsusiyyəti daha tez bitirdi və onu master ilə birləşdirdi.
İkinciyə daha çox vaxt lazım idi, sonradan birləşdi və münaqişə ilə nəticələndi. İndi tərtibatçı biznesin ehtiyac duyduğu xüsusiyyətləri yazmaq əvəzinə, vaxtını və enerjisini münaqişələrin həllinə sərf edir.
Xüsusiyyətinizi ümumi bir usta ilə birləşdirmək nə qədər çətin olsa, ona daha çox vaxt sərf edirik. Mən bunu kifayət qədər sadə bir nümunə ilə göstərdim. Bu, cəmi 2 tərtibatçının olduğu bir nümunədir.Təsəvvür edin ki, bir şirkətdə 10 və ya 15 və ya 100 nəfər bir depoya yazır. Bütün bu münaqişələri həll etmək üçün dəli olacaqsınız.
Bir az fərqli bir vəziyyət var. Bizim bir ustamız və bəzi tərtibatçılarımız var.
Bir budaq yaratdılar.
Biri öldü, hər şey yaxşı idi, tapşırığı keçdi.
İkinci tərtibatçı isə öz tapşırığını verdi. Deyək ki, o, araşdırmaya göndərib. Bir çox şirkətlərin baxış adlanan praktikası var. Bir tərəfdən, bu təcrübə yaxşı və faydalıdır, digər tərəfdən, bir çox cəhətdən bizi ləngidir. Biz buna girməyəcəyik, amma pis nəzərdən keçirmə hekayəsinin nəyə gətirib çıxara biləcəyinə dair gözəl bir nümunə budur. Nəzərdən keçirilməsi üçün çəkmə sorğusu göndərdiniz. Tərtibatçı üçün başqa bir şey yoxdur. Nə etməyə başlayır? O, başqa işləri görməyə başlayır.
Bu müddət ərzində ikinci tərtibatçı başqa bir şey etdi.
Birincisi üçüncü tapşırığı tamamladı.
Və bir müddət sonra onun baxışı sınaqdan keçirildi və o, razılaşmağa çalışır. Bəs nə baş verir? Çoxlu sayda münaqişələri tutur. Niyə? Çünki onun çəkmə sorğusu nəzərdən keçirilərkən, kodda çox şey dəyişmişdi.
Münaqişələri olan hekayədən əlavə, ünsiyyətli bir hekayə var. Mövzunuz nəzərdən keçirilərkən, nəyisə gözləyərkən, uzun müddət bir xüsusiyyət üzərində işləyərkən, xidmətinizin kod bazasında başqa nələrin dəyişdiyini izləməyi dayandırırsınız. Ola bilsin ki, indi həll etməyə çalışdığınız məsələ dünən artıq həll olunub və siz hansısa üsul götürüb yenidən istifadə edə bilərsiniz. Ancaq bunu görməyəcəksiniz, çünki siz həmişə köhnəlmiş filialla işləyirsiniz. Və bu köhnəlmiş filial həmişə birləşmə münaqişəsini həll etmək məcburiyyətində qalmağınızla nəticələnir.
Belə çıxır ki, biz bir komanda kimi işləsək, yəni depoda bir nəfər deyil, 5-10 nəfər gəzirsə, kodumuzu mastera nə qədər əlavə etməsək, bir o qədər çox əziyyət çəkirik, çünki son nəticədə ehtiyacımız var. bir şey sonra onu birləşdirin. Və nə qədər çox konfliktimiz varsa və nə qədər köhnə versiya ilə işləyiriksə, bir o qədər çox problemimiz olur.
Birlikdə bir şey etmək ağrılıdır! Biz həmişə bir-birimizin yolunu kəsirik.
Bu problem 20 ildən çox əvvəl diqqət çəkib. Ekstremal Proqramlaşdırmada Davamlı İnteqrasiya təcrübəsinin ilk qeydini tapdım.
Ekstremal Proqramlaşdırma ilk çevik çərçivədir. Səhifə 96-cı ildə yaranıb. Və ideya bir növ proqramlaşdırma təcrübələrindən, planlaşdırma və digər şeylərdən istifadə etmək idi ki, inkişaf mümkün qədər çevik olsun, beləliklə müştərilərimizdən gələn hər hansı dəyişikliyə və ya tələblərə tez cavab verə bilək. Və 24 il əvvəl bununla üzləşməyə başladılar ki, əgər bir şeyi çox uzun müddət və kənarda görürsənsə, onda münaqişələrin olduğu üçün ona daha çox vaxt sərf edirsən.
İndi biz “Davamlı İnteqrasiya” ifadəsini ayrı-ayrılıqda təhlil edəcəyik. Birbaşa tərcümə etsək, davamlı inteqrasiya əldə edirik. Ancaq bunun nə qədər davamlı olduğu çox aydın deyil, çox fasiləlidir. Amma onun nə qədər inteqrasiyası da çox açıq deyil.
Və buna görə indi sizə Ekstremal Proqramlaşdırmadan sitatlar verirəm. Və hər iki sözü ayrıca təhlil edəcəyik.
İnteqrasiya - Artıq dediyim kimi, biz çalışırıq ki, hər bir mühəndis kodun ən müasir versiyası ilə işləsin ki, o öz kodunu mümkün qədər tez-tez ümumi filiala əlavə etməyə çalışsın ki, bunlar kiçik filiallar olsun. Çünki onlar böyükdürsə, onda bir həftə ərzində birləşmə münaqişələri ilə asanlıqla ilişib qala bilərik. Bu, şəlalə kimi uzun bir inkişaf dövrümüz varsa, bu xüsusilə doğrudur, burada tərtibatçı nəhəng bir xüsusiyyəti kəsmək üçün bir ay ərzində getdi. Və o, çox uzun müddət inteqrasiya mərhələsində ilişib qalacaq.
İnteqrasiya odur ki, biz filialımızı götürüb master ilə inteqrasiya edirik, onu birləşdiririk. Biz transbase tərtibatçısı olduğumuz zaman son seçim var, burada heç bir əlavə filial olmadan dərhal mastera yazmağımızı təmin etməyə çalışırıq.
Ümumiyyətlə, inteqrasiya kodunuzu götürüb master-a sürükləmək deməkdir.
Burada “davamlı” sözü ilə nə nəzərdə tutulur, davamlılıq nəyə deyilir? Təcrübə o deməkdir ki, tərtibatçı öz kodunu mümkün qədər tez inteqrasiya etməyə çalışır. Bu, hər hansı bir tapşırığı yerinə yetirərkən onun məqsədidir - kodunu mümkün qədər tez masterə daxil etmək. İdeal bir dünyada tərtibatçılar bunu bir neçə saatdan bir edərdilər. Yəni kiçik bir problem götürüb ustada birləşdirəcəksiniz. Hər şey əladır. Bunun üçün səy göstərirsiniz. Və bu davamlı olaraq edilməlidir. Bir şey edən kimi dərhal ustaya qoyursan.
Və bir şeyi düzəldən tərtibatçı, onun işləməsi və heç bir şeyi pozmaması üçün etdiklərinə görə məsuliyyət daşıyır. Sınaq hekayəsi adətən buradan çıxır. Onun işlədiyinə əmin olmaq üçün öhdəliklərimizdə, birləşməmizdə bəzi sınaqlar keçirmək istəyirik. Və burada Jenkins sizə kömək edə bilər.
Ancaq hekayələrlə: dəyişiklikləri kiçik edək, tapşırıqları kiçik edək, problem yaradaq və dərhal onu ustaya daxil etməyə çalışaq - burada heç bir Jenkins kömək etməyəcək. Çünki Jenkins sizə yalnız testlər keçirməyə kömək edəcək.
Onlarsız edə bilərsiniz. Bu sizə heç bir zərər verməyəcək. Çünki təcrübənin məqsədi gələcəkdə hər hansı bir münaqişəyə çox vaxt sərf etməmək üçün mümkün qədər tez-tez ölçməkdir.
Təsəvvür edək ki, nədənsə 2020-ci ildə internetsiz qalmışıq. Və biz yerli işləyirik. Bizdə Jenkins yoxdur. Bu yaxşıdır. Siz hələ də davam edib yerli filial yarada bilərsiniz. Orada bəzi kod yazdınız. Tapşırığı 3-4 saat ərzində yerinə yetirdik. Master-a keçdik, git pull etdik və filialımızı orada birləşdirdik. Hazır. Bunu tez-tez edirsinizsə, sizi təbrik edirik, Davamlı İnteqrasiyaya sahibsiniz!
Müasir dünyada enerji sərf etməyə dəyər olduğuna dair hansı sübutlar var? Çünki ümumiyyətlə, çətindir. Bu cür işləməyə çalışsanız, bəzi planlaşdırmanın indi təsirlənəcəyini başa düşəcəksiniz, vəzifələrin parçalanmasına daha çox vaxt ayırmalı olacaqsınız. Çünki əgər insan... etsən, o zaman tez barışa bilməyəcəksən və buna uyğun olaraq bəlaya düşəcəksən. Artıq təcrübəniz olmayacaq.
Və bahalı olacaq. Davamlı İnteqrasiyadan istifadə edərək sabahdan dərhal işləmək mümkün olmayacaq. Buna öyrəşmək hamınıza çox uzun vaxt aparacaq, tapşırıqların parçalanmasına öyrəşmək çox uzun vaxt aparacaq, əgər sizdə varsa, nəzərdən keçirmə təcrübəsini təkrar etməyə alışmaq çox uzun vaxt aparacaq. . Çünki bizim məqsədimiz onun bu gün əriməsidir. Üç gün ərzində nəzərdən keçirsəniz, probleminiz var və Davamlı İnteqrasiya sizin üçün işləmir.
Bəs hazırda bu təcrübəyə sərmayə qoymağın məntiqli olduğunu söyləyən hər hansı müvafiq sübutumuz varmı?
Ağlıma gələn ilk şey State of DevOps oldu. Bu, uşaqların 7 ildir apardıqları araşdırmadır. İndi bunu müstəqil bir təşkilat kimi edirlər, lakin Google altında.
Və onların 2018-ci ildəki araşdırması, sürətli inteqrasiya edən, tez-tez inteqrasiya edən və daha yaxşı İT performans göstəricilərinə malik olan qısamüddətli filiallardan istifadə etməyə çalışan şirkətlər arasında korrelyasiya olduğunu göstərdi.
Bu göstəricilər hansılardır? Bu, onların sorğu vərəqlərində bütün şirkətlərdən götürdükləri 4 göstəricidir: yerləşdirmə tezliyi, dəyişikliklər üçün vaxt, xidməti bərpa etmək vaxtı, uğursuzluq dərəcəsini dəyişdirmək.
Və birincisi, bu korrelyasiya var, biz bilirik ki, tez-tez ölçən şirkətlər daha yaxşı ölçülərə malikdir. Və şirkətlərin bir neçə kateqoriyaya bölünməsi var: bunlar yavaş-yavaş bir şey istehsal edən, orta performanslı, yüksək performanslı və elit şirkətlərdir. Elit Netflix, Amazon, super sürətli, hər şeyi tez, gözəl və səmərəli edir.
Cəmi bir ay əvvəl baş verən ikinci hekayə. Texnologiya Radarında Gitflow haqqında əla məqalə var. Gitflow budaqlarının uzunömürlü olması ilə digərlərindən fərqlənir. Uzun müddət yaşayan buraxılış budaqları və uzun müddət yaşayan budaqları var. Texnologiya Radarında bu təcrübə HOLD-a keçdi. Niyə? Çünki insanlar inteqrasiyanın acısı ilə üzləşirlər.
Əgər filialınız çox uzun müddət yaşayırsa, ilişib qalır, çürüyür və biz ona bir növ dəyişiklik etmək üçün daha çox vaxt sərf etməyə başlayırıq.
Və bu yaxınlarda Gitflow müəllifi dedi ki, əgər məqsədiniz Davamlı İnteqrasiyadırsa, məqsədiniz mümkün qədər tez-tez yuvarlanmaqdırsa, Gitflow pis fikirdir. O, məqaləyə ayrıca əlavə etdi ki, əgər bunun üçün səy göstərə biləcəyiniz bir arxa planınız varsa, Gitflow sizin üçün artıqdır, çünki Gitflow sizi yavaşlatacaq, Gitflow sizə inteqrasiya ilə bağlı problemlər yaradacaq.
Bu o demək deyil ki, Gitflow pisdir və istifadə edilməməlidir. Başqa hallar üçündür. Məsələn, bir xidmətin və ya tətbiqin bir neçə versiyasını dəstəkləmək lazım olduqda, yəni uzun müddət ərzində dəstəyə ehtiyacınız olduqda.
Ancaq bu cür xidmətləri dəstəkləyən insanlarla danışsanız, bu versiyanın 3.2 ay əvvəl olan 4 olması ilə bağlı çox ağrı eşidəcəksiniz, lakin bu düzəliş ona daxil deyildi və indi bunu etmək üçün, bir dəstə dəyişiklik etməlisiniz. İndi onlar yenidən ilişib qalıblar və indi bir həftədir ki, yeni bir funksiya tətbiq etməyə çalışırlar.
Alexander Kovalev söhbətdə düzgün qeyd etdiyi kimi, korrelyasiya səbəbiyyətlə eyni deyil. Bu doğrudur. Yəni, Davamlı İnteqrasiyanız varsa, bütün göstəricilərin əla olacağı ilə bağlı birbaşa əlaqə yoxdur. Ancaq müsbət bir əlaqə var ki, əgər biri biridirsə, çox güman ki, digəri də var. Fakt deyil, amma çox güman ki. Bu, sadəcə bir əlaqədir.
Deyəsən, biz artıq nəsə edirik, deyəsən artıq birləşirik, amma bizdə hələ də Davamlı İnteqrasiya olduğunu, tez-tez birləşdiyimizi necə başa düşmək olar?
Jez Humble Handbook, Accelerate, Continuous Delivery veb saytı və Continuous Delivery kitabının müəllifidir. O, bu testi təklif edir:
- Mühəndis kodu hər gün ustaya çatır.
- Hər bir öhdəlik üçün vahid testləri həyata keçirirsiniz.
- Ustada konstruksiya yıxıldı, təxminən 10 dəqiqəyə düzəldilib.
O, kifayət qədər təcrübəniz olduğundan əmin olmaq üçün belə bir testdən istifadə etməyi təklif edir.
Mən sonuncunu bir az mübahisəli hesab edirəm. Yəni 10 dəqiqə ərzində düzəldə bilsəniz, o zaman sizdə Davamlı İnteqrasiya var, bir az qəribə səslənir, fikrimcə, amma mənası var. Niyə? Çünki tez-tez donursunuzsa, bu, dəyişikliklərinizin kiçik olması deməkdir. Kiçik bir dəyişiklik master quruluşunuzun pozulduğunu bildirirsə, dəyişiklik kiçik olduğu üçün tez bir nümunə tapa bilərsiniz. Burada kiçik bir birləşmə etdiniz, içindəki 20-30 sətir dəyişdi. Və buna uyğun olaraq, səbəbin nə olduğunu tez başa düşə bilərsiniz, çünki dəyişikliklər kiçikdir, problemi axtarmaq üçün çox kiçik bir sahəniz var.
Məhsulumuz buraxıldıqdan sonra parçalansa belə, Davamlı İnteqrasiya təcrübəmiz varsa, bizim üçün hərəkət etmək daha asandır, çünki dəyişikliklər kiçikdir. Bəli, bu plana təsir edəcək. Bu zərər verəcək. Və yəqin ki, bu təcrübədə ən çətin şey tapşırıqları parçalamağa alışmaqdır, yəni bunu necə etməkdir ki, bir şeyi götürüb bir neçə saat ərzində edə biləsiniz və eyni zamanda nəzərdən keçirə biləsiniz. sizdə bir var. Baxış ayrı bir ağrıdır.
Vahid testləri inteqrasiyanızın uğurlu olub olmadığını və heç bir şeyin pozulmadığını anlamağa kömək edən köməkçidir. Fikrimcə, bu da tamamilə məcburi deyil, çünki bu, praktika nöqtəsi deyil.
Bu, Davamlı İnteqrasiyaya qısa girişdir. Bu praktikada hər şey var. Suallara hazıram.
Yenə qısaca xülasə edəcəyəm:
- Davamlı İnteqrasiya Jenkins deyil, Gitlab deyil.
- Bu bir vasitə deyil, kodumuzu ustada mümkün qədər tez birləşdirdiyimiz bir təcrübədir.
- Gələcəkdə birləşmələrlə yaranan böyük ağrıdan qaçmaq üçün bunu edirik, yəni gələcəkdə daha çox yaşamamaq üçün indi bir az ağrı yaşayırıq. Bütün məsələ budur.
- Yan tərəfdə kod vasitəsilə ünsiyyət var, amma mən bunu çox nadir hallarda görürəm, amma bu da bunun üçün nəzərdə tutulub.
Suallar
Qeyri-parçalanmamış vəzifələrlə nə etməli?
Parçalamaq. Problem nədir? Bir misal göstərə bilərsiniz ki, bir tapşırıq var və o, parçalanmayıb?
Elə tapşırıqlar var ki, onları "tamamilə" sözündən ayırmaq mümkün deyil, məsələn, çox dərin təcrübə tələb edən və həzm oluna bilən nəticə əldə etmək üçün əslində bir ay ərzində həll edilə bilən vəzifələr.
Əgər mən sizi düzgün başa düşürəmsə, o zaman nəsə böyük və mürəkkəb bir iş var ki, nəticəsi yalnız bir aydan sonra görünəcək?
Bəli doğrudur. Bəli, nəticəni bir aydan gec olmayaraq qiymətləndirmək mümkün olacaq.
Yaxşı. Ümumiyyətlə, bu problem deyil. Niyə? Çünki bu zaman biz budaqlardan danışarkən, özəlliyi olan budaqdan danışmırıq. Xüsusiyyətlər böyük və mürəkkəb ola bilər. Onlar çox sayda komponentə təsir göstərə bilər. Və ola bilsin ki, biz onları bir qolda tamam edə bilmərik. Bu yaxşıdır. Sadəcə bu hekayəni parçalamaq lazımdır. Əgər funksiya tam hazır deyilsə, bu o demək deyil ki, onun kodunun bəzi hissələri birləşdirilə bilməz. Miqrasiyanı əlavə etdiniz və xüsusiyyət daxilində bəzi mərhələlər var. Deyək ki, bir mərhələniz var - köçürmə edin, yeni bir üsul əlavə edin. Və siz artıq hər gün bunları ölçə bilərsiniz.
Yaxşı. Onda nə mənası var?
Hər gün kiçik şeyləri öldürməyin nə mənası var?
Bəli.
Bir şeyi sındırsalar, dərhal görürsən. Nəyisə sındıran kiçik bir parçanız var, onu düzəltmək sizin üçün daha asandır. Məsələ burasındadır ki, indi kiçik bir parçanı birləşdirmək bir neçə həftə ərzində böyük bir şeyi birləşdirməkdən daha asandır. Üçüncü məqam isə odur ki, digər mühəndislər kodun hazırkı versiyası ilə işləyəcəklər. Görəcəklər ki, bura bəzi köçlər əlavə olunub, sonra hansısa üsul ortaya çıxıb ki, onlar da istifadə etmək istəyə bilərlər. Hər kəs kodunuzda nə baş verdiyini görəcək. Məhz bu üç şey üçün məşq edilir.
Təşəkkür edirəm, məsələ bağlandı!
(Oleq Soroka) Əlavə edə bilərəmmi? Hər şeyi düz dedin, sadəcə bir cümlə əlavə etmək istəyirəm.
So.
Davamlı İnteqrasiya ilə kod, xüsusiyyət tamamilə hazır olduqda deyil, quruluş pozulmağı dayandırdıqda ümumi filiala birləşdirilir. Və siz gündə bir neçə dəfə istədiyiniz qədər ustalaşmağı öhdəsinə götürə bilərsiniz. İkinci cəhət odur ki, əgər nədənsə aylıq tapşırığı ən azı üç gün ərzində tapşırıqlara bölə bilmirsinizsə, mən üç saata yaxın susuram, deməli, böyük probleminiz var. Davamlı İnteqrasiyaya malik olmamağınız isə bu problemlərin ən kiçikidir. Bu o deməkdir ki, memarlıq və sıfır mühəndislik təcrübələri ilə bağlı probleminiz var. Çünki bu tədqiqat olsa belə, istənilən halda fərziyyə və ya dövriyyə şəklində formalaşmalıdır.
Uğurlu şirkətləri geridə qalanlardan fərqləndirən 4 göstərici haqqında danışdıq. Bu 4 göstəricini görmək üçün hələ yaşamalıyıq. Orta tapşırığınızın tamamlanması bir ay çəkirsə, mən ilk növbədə bu metrikaya diqqət yetirərdim. Əvvəlcə 3 günə endirərdim. Və bundan sonra Continous haqqında düşünməyə başladım.
Düzgün başa düşdüm ki, hər hansı bir işi başa çatdırmaq üçün bir ay lazım olsa, ümumiyyətlə mühəndislik təcrübələrinə sərmayə qoymağın mənası yoxdur.
Davamlı İnteqrasiyanız var. Və elə bir mövzu var ki, 10 dəqiqə ərzində ya düzəlişi düzəldə, ya da geri qaytara bilərsiniz. Təsəvvür edin ki, siz onu yaydınız. Üstəlik, hətta davamlı yerləşdirməniz var, onu istehsal etmək üçün yaydınız və yalnız bundan sonra nəyinsə səhv getdiyini gördük. Siz onu geri qaytarmalısınız, lakin siz artıq verilənlər bazanızı köçürmüsünüz. Artıq növbəti versiyanın verilənlər bazası sxeminə sahibsiniz, üstəlik, bir növ ehtiyat nüsxəniz də var və məlumatlar da orada yazılmışdır.
Və hansı alternativiniz var? Kodu geri qaytarsanız, o, artıq bu yenilənmiş verilənlər bazası ilə işləyə bilməz.
Baza yalnız irəliləyir, bəli.
Mühəndislik təcrübəsi zəif olan insanlar çox güman ki, bu barədə qalın kitabı oxumayıblar... Yedəklə nə etməli? Əgər ehtiyat nüsxədən bərpa etsəniz, bu, həmin an topladığınız məlumatları itirdiyiniz deməkdir. Məsələn, bazanın yeni versiyası, orada qeydiyyatdan keçən istifadəçilərlə üç saat işlədik. Siz köhnə ehtiyat nüsxəsindən imtina edirsiniz, çünki sxem yeni versiya ilə işləmir, ona görə də bu istifadəçiləri itirmisiniz. Onlar isə narazıdırlar, söyüş söyürlər.
Davamlı İnteqrasiya və Davamlı Çatdırılmanı dəstəkləyən bütün təcrübələrə yiyələnmək üçün sadəcə yazmağı öyrənmək kifayət deyil.... Birincisi, onların çoxu ola bilər, praktiki olmayacaq. Üstəlik Scientific kimi bir sıra digər təcrübələr də var. Belə bir təcrübə var, GitHub onu bir vaxtlar populyarlaşdırdı. Bu, həm köhnə kodun, həm də yeni kodun eyni vaxtda işlədiyi zamandır. Bu, siz yarımçıq bir funksiya yaratdığınız zamandır, lakin o, müəyyən dəyər qaytara bilər: ya funksiya kimi, ya da Rest API kimi. Siz həm yeni kodu, həm də köhnə kodu icra edirsiniz və aralarındakı fərqi müqayisə edirsiniz. Bir fərq varsa, bu hadisəni qeyd edirsiniz. Beləliklə, müəyyən bir müddət ərzində ikisi arasında uyğunsuzluq yaşamamısınızsa, köhnənin üstünə çıxmağa hazır yeni bir xüsusiyyətiniz olduğunu bilirsiniz.
Yüzlərlə belə təcrübə var. Transbase inkişafı ilə başlamağı təklif edərdim. O, Davamlı İnteqrasiyada 100% deyil, amma təcrübələr eynidir, biri digəri olmadan yaxşı yaşaya bilməz.
Təcrübələri görə biləcəyiniz bir nümunə olaraq transbase inkişafını göstərdinizmi və ya insanlara transbase inkişafından istifadə etməyə başlamağı təklif edirsiniz?
Baxın, çünki ondan istifadə edə bilməyəcəklər. Onlardan istifadə etmək üçün çox oxumaq lazımdır. Bir adam soruşduqda: "Bir ay çəkəcək bir xüsusiyyət ilə nə etmək lazımdır, bu o deməkdir ki, transbase inkişafı haqqında oxumayıb." Mən hələ bunu tövsiyə etməzdim. Mən yalnız böyük vəzifələri daha kiçik olanlara necə düzgün şəkildə arxitekturaya bölmək mövzusuna diqqət yetirməyi məsləhət görərdim. Bu parçalanmanın mahiyyətidir.
Parçalanma memarın alətlərindən biridir. Əvvəlcə analiz, sonra parçalanma, sonra sintez, sonra inteqrasiya edirik. Və hər şey bizim üçün belə olur. Və biz hələ də parçalanma yolu ilə Davamlı İnteqrasiyaya yüksəlməliyik. Birinci mərhələdə suallar yaranır və biz artıq dördüncü mərhələdən danışırıq, yəni inteqrasiyanı nə qədər tez-tez ediriksə, bir o qədər yaxşıdır. Bunu etmək hələ tezdir, əvvəlcə monolitinizi kəsmək yaxşı olardı.
Bəzi diaqramda bir sıra oxlar və kvadratlar çəkmək lazımdır. Deyə bilməzsiniz ki, indi yeni bir tətbiqin memarlıq diaqramını göstərəcəyəm və içərisində tətbiq üçün yaşıl düymə olan bir kvadrat göstərəcəyəm. Hər halda, daha çox kvadrat və oxlar olacaq. Gördüyüm hər diaqramda birdən çox var idi. Və hətta qrafik təsvir səviyyəsində parçalanma artıq baş verir. Buna görə də, kvadratlar müstəqil edilə bilər. Yoxdursa, memar üçün böyük suallarım var.
Çatdan bir sual var: "Əgər baxış məcburidirsə və uzun müddət çəkirsə, bəlkə bir gün və ya daha çox?"
Təcrübə ilə bağlı probleminiz var. Baxış bir gün və ya daha çox davam etməməlidir. Bu, əvvəlki sualın eyni hekayəsidir, yalnız bir az daha yumşaqdır. Baxış bir gün davam edərsə, çox güman ki, bu nəzərdən çox böyük dəyişiklik olacaq. Bu o deməkdir ki, onu daha kiçik etmək lazımdır. Oleqin tövsiyə etdiyi transbase inkişafında davamlı baxış adlı bir hekayə var. Onun fikri budur ki, biz qəsdən belə kiçik bir çəkmə tələbi edirik, çünki biz daim və bir az da birləşməyə çalışırıq. Beləliklə, çəkmə sorğusu bir abstraksiya və ya 10 sətir dəyişir. Bu baxış sayəsində bir neçə dəqiqə çəkir.
Baxış bir gün və ya daha çox çəkirsə, nəsə səhvdir. Birincisi, arxitektura ilə bağlı bəzi problemləriniz ola bilər. Və ya bu, məsələn, 1 sətirdən ibarət böyük bir kod parçasıdır. Yaxud memarlığınız o qədər mürəkkəbdir ki, insan onu başa düşə bilməz. Bu bir az yan problemdir, lakin onu da həll etmək lazımdır. Ola bilsin ki, ümumiyyətlə nəzərdən keçirməyə ehtiyac yoxdur. Bu barədə də düşünməliyik. Baxış sizi ləngidən şeydir. Ümumiyyətlə, onun üstünlükləri var, ancaq bunu niyə etdiyinizi başa düşməlisiniz. Bu, məlumatı tez ötürməyiniz üçün bir yoldurmu, daxili olaraq bəzi standartlar təyin etməyiniz üçün bir yoldur, yoxsa nə? Bu nəyə lazımdır? Çünki baxışı ya çox tez etmək lazımdır, ya da tamamilə ləğv etmək lazımdır. Bu, transbase inkişafı kimidir - hekayə çox gözəldir, lakin yalnız yetkin uşaqlar üçün.
4 göstəriciyə gəldikdə, bunun nəyə gətirib çıxardığını başa düşmək üçün hələ də onları silməyi tövsiyə edərdim. Rəqəmlərə baxın, şəkilə baxın, hər şey necə pisdir.
(Dmitri) Mən sizinlə bu barədə müzakirəyə girməyə hazıram. Rəqəmlər və ölçülər hamısı əladır, təcrübələr əladır. Ancaq biznesin buna ehtiyacı olub olmadığını başa düşməlisiniz. Elə müəssisələr var ki, onların bu cür dəyişmə sürətinə ehtiyacı yoxdur. Hər 15 dəqiqədən bir dəyişiklik etmək mümkün olmayan şirkətləri tanıyıram. Və çox pis olduqları üçün deyil. Bu belə bir həyat dövrüdür. Və budaqları xüsusiyyət, keçid funksiyası etmək üçün sizə dərin bilik lazımdır.
Bu mürəkkəbdir. Əgər keçid funksiyası haqqında hekayəni daha ətraflı oxumaq istəyirsinizsə, onu çox tövsiyə edirəm . Və Martin Fowlerin keçid funksiyaları haqqında gözəl məqaləsi var: hansı növlər var, həyat dövrləri və s. Dəyişdirmə funksiyası mürəkkəbdir.
Və siz hələ də suala cavab verməmisiniz: "Cenkins lazımdır, ya yox?"
Jenkins heç bir halda lazım deyil. Ciddi olsa da, alətlər: Jenkins, Gitlab sizə rahatlıq gətirəcək. Montajın yığıldığını və ya yığılmadığını görəcəksiniz. Onlar sizə kömək edə bilər, amma təcrübə verməyəcəklər. Onlar sizə yalnız bir dairə verə bilərlər - Ok, Ok deyil. Və sonra, əgər siz də testlər yazırsınızsa, çünki testlər yoxdursa, demək olar ki, mənasızdır. Buna görə də, daha rahat olduğu üçün lazımdır, amma ümumiyyətlə onsuz yaşaya bilərsiniz, çox şey itirməyəcəksiniz.
Yəni təcrübələriniz varsa, bu, sizə lazım olmadığını bildirirmi?
Düzdür. Jez Humble testini tövsiyə edirəm. Orada sonuncu məqama münasibətim birmənalı deyil. Ancaq ümumiyyətlə, üç şeyiniz varsa, daim birləşirsiniz, master-da tapşırıqlar üzrə testlər keçirirsiniz, ustada quruluşu tez bir zamanda düzəldirsiniz, onda bəlkə də başqa heç nə lazım deyil.
İştirakçılardan sual gözləyərkən bir sualım var. Biz sadəcə məhsul kodundan danışırdıq. Siz onu infrastruktur kodu üçün istifadə etmisiniz? Eyni koddur, eyni prinsiplər və eyni həyat dövrü var, yoxsa fərqli həyat dövrləri və prinsipləri var? Adətən, hamı Davamlı İnteqrasiya və İnkişafdan danışanda hamı unudur ki, orada infrastruktur kodu da var. Və son vaxtlar daha çox olur. Və bütün bu qaydaları ora gətirmək lazımdırmı?
Hətta belə olması lazım deyil, əla olardı, çünki həyatı eyni şəkildə asanlaşdırar. Bash skriptləri ilə deyil, kodla işləyən kimi, amma normal kodumuz var.
Stop, stop, bir bash skripti də koddur. Köhnə sevgimə toxunma.
Yaxşı, mən sənin xatirələrini tapdalamayacağam. Mənim bash üçün şəxsi nifrətim var. O, hər zaman çirkin və qorxulu qırılır. Və tez-tez gözlənilmədən qırılır, buna görə də xoşuma gəlmir. Amma yaxşı, deyək ki, sizdə bash kodu var. Bəlkə mən həqiqətən başa düşmürəm və orada normal sınaq çərçivələri var. Sadəcə xəbərim yoxdur. Və eyni faydaları əldə edirik.
İnfrastrukturla kod kimi işlədiyimiz anda biz tərtibatçılarla eyni problemlərlə üzləşirik. Bir neçə ay əvvəl bir həmkarımın mənə bash-da 1 sətir üçün çəkmə sorğusu göndərdiyi bir vəziyyətlə qarşılaşdım. Və siz 000 saat baxışda oturursunuz. Eyni problemlər yaranır. Hələ koddur. Və bu hələ də əməkdaşlıqdır. Biz çəkmə sorğusu ilə ilişib qalmışıq və məsələn, eyni birləşmə konfliktlərini eyni bash-da həll etdiyimizlə bağlı qalırıq.
Mən indi ən gözəl infra proqramlaşdırmada bu hər şeyə çox fəal şəkildə baxıram. İndi Pulumini infrastruktura gətirmişəm. Bu, ən təmiz formada proqramlaşdırmadır. Orada daha gözəldir, çünki mən proqramlaşdırma dilinin bütün imkanlarına sahibəm, yəni eyni ifs ilə mavidən gözəl keçid etdim və hər şey qaydasındadır. Yəni mənim dəyişikliyim artıq ustadadır. Artıq hər kəs onu görə bilər. Digər mühəndislər bu barədə bilirlər. Artıq orada nəyəsə təsir edib. Bununla belə, o, bütün infrastrukturlar üçün aktiv deyildi. Məsələn, sınaq skamyalarım üçün işə salındı. Ona görə də sualınıza bir daha cavab vermək lazımdır. Bu, kodla işləyən mühəndislər kimi bizim üçün də həyatı asanlaşdırır.
Başqa kimin sualları varsa?
Sualım var. Oleqlə müzakirəni davam etdirmək istəyirəm. Ümumiyyətlə, mən hesab edirəm ki, siz haqlısınız, əgər bir işi başa çatdırmaq bir ay çəkirsə, deməli, sizin arxitektura probleminiz var, təhlil, parçalanma, planlaşdırma və s probleminiz var. Amma məndə belə bir hiss var ki, başlasanız Davamlı İnteqrasiyaya görə canlı yaşamağa çalışsanız, o zaman ağrıları planlaşdırmaqla düzəltməyə başlayacaqsınız, çünki başqa yerdə ondan uzaqlaşa bilməyəcəksiniz.
(Oleq) Bəli, düzdür. Bu təcrübə hər hansı digər ciddi mədəniyyəti dəyişdirən təcrübə ilə müqayisə edilə bilər. Ən çətin şey vərdişlər, xüsusən də pis vərdişlərdir. Və bu təcrübəni həyata keçirmək üçün ətrafınızdakıların vərdişlərində ciddi dəyişiklik tələb olunursa: tərtibatçılar, rəhbərlik, istehsal meneceri, onda sizi sürprizlər gözləyir.
Hansı sürprizlər ola bilər? Deyək ki, daha tez-tez inteqrasiya olunacağınıza qərar verdiniz. İnteqrasiya ilə əlaqəli başqa şeyləriniz var, məsələn, artefaktlar. Və sizin şirkətinizdə, məsələn, hər bir artefaktın bir növ artefakt saxlama sistemində bir şəkildə nəzərə alınmalı olduğu bir siyasət var. Və bir az vaxt tələb edir. Bir şəxs buraxılış meneceri olaraq bu artefaktın istehsalda buraxılmağa hazır olmasını təmin etmək üçün sınaqdan keçirdiyi qutunu işarələməlidir. Əgər 5-10-15 dəqiqə çəkirsə, lakin siz həftədə bir dəfə layout edirsinizsə, onda həftədə bir dəfə yarım saat sərf etmək kiçik bir vergidir.
Gündə 10 dəfə Davamlı İnteqrasiya edirsinizsə, onda 10 dəfə 30 dəqiqəyə vurulmalıdır. Və bu, bu buraxılış menecerinin iş vaxtının miqdarını aşır. Sadəcə bunu etməkdən yorulur. Bəzi təcrübələr üçün sabit xərclər var. Hamısı budur.
Və ya bu qaydanı ləğv etməlisiniz ki, artıq belə bir zibillik etməməyəsiniz, yəni nəyəsə uyğun olmaq üçün əl ilə dərəcə təyin etməyəsiniz. Siz tamamilə bəzi avtomatlaşdırılmış hazırlıq testlərinə arxalanırsınız.
Və kimdənsə sübuta ehtiyacınız varsa, patron buna imza atsın və siz Vasya icazə verdiyini demədən istehsalata girməsəniz və s. Çünki vergi ilə bağlı hansısa fəaliyyət varsa, o zaman hər şey 100 dəfə artır. Buna görə də dəyişiklik çox vaxt hamı tərəfindən sevinclə qarşılanmayacaq. Çünki insanların vərdişlərini dəyişmək çətindir.
İnsan adi işini görəndə, demək olar ki, düşünmədən edir. Onun koqnitiv yükü sıfırdır. O, sadəcə olaraq onunla oynayır, beynində artıq yoxlama siyahısı var, bunu min dəfə edib. Gəlib ona deyən kimi: “Gəlin bu təcrübəni ləğv edək və bazar ertəsindən başlayaraq yenisini tətbiq edək” bu, onun üçün güclü bir idrak yükü olur. Və hər kəsə bir anda gəlir.
Buna görə də, ən sadə şey, hər kəs bu lüksü ödəyə bilməsə də, həmişə etdiyim şey budur, bu aşağıdakılardır. Yeni bir layihə başlayırsa, adətən bütün sınaqdan keçirilməmiş təcrübələr dərhal bu layihəyə daxil edilir. Layihə gənc olsa da, biz heç nəyi riskə atmırıq. Hələ Prod yoxdur, məhv ediləcək bir şey yoxdur. Buna görə də təlim kimi istifadə edilə bilər. Bu yanaşma işləyir. Amma bütün şirkətlərin belə layihələrə tez-tez başlamaq imkanı yoxdur. Bu da bir az qəribə olsa da, indi tam rəqəmsal transformasiya olduğu üçün rəqiblərlə ayaqlaşa bilmək üçün hər kəs təcrübələrə başlamalıdır.
Buradan belə nəticəyə gəlirsiniz ki, əvvəlcə nə etməli olduğunuzu başa düşməlisiniz. Dünya ideal deyil, məhsul da ideal deyil.
Bəli, bunlar bir-birinə bağlıdır.
Müəssisələr də həmişə başa düşmürlər ki, bu yolla getməlidirlər.
Elə bir vəziyyət var ki, heç bir dəyişiklik etmək mümkün deyil. Bu, komanda üzərində daha çox təzyiqin olduğu bir vəziyyətdir. Komanda artıq çox yanıb. Onun heç bir təcrübə üçün boş vaxtı yoxdur. Səhərdən axşama kimi xüsusiyyətlər üzərində işləyirlər. İdarəetmə isə getdikcə daha az xüsusiyyətlərə malikdir. Daha çox tələb olunur. Belə bir vəziyyətdə heç bir dəyişiklik mümkün deyil. Komandaya yalnız onu demək olar ki, sabah da dünənki kimi edəcəyik, sadəcə bir az daha çox xüsusiyyətlər etməliyik. Bu mənada heç bir praktikaya keçid mümkün deyil. Bu klassik bir vəziyyətdir ki, baltanı itiləmək üçün vaxt yoxdur, ağacları kəsmək lazımdır, ona görə də onu darıxdırıcı balta ilə kəsirlər. Burada sadə məsləhətlər yoxdur.
(Dmitri) Söhbətdən bir izahat oxuyacağam: “Ancaq müxtəlif səviyyələrdə çoxlu test əhatəsinə ehtiyacımız var. Testlər üçün nə qədər vaxt ayrılır? Bir az bahadır və çox vaxt aparır”.
(Oleq) Bu klassik yanlış fikirdir. Özünə güvənmək üçün kifayət qədər testlər olmalıdır. Davamlı İnteqrasiya elə bir şey deyil ki, testlərin 100%-i əvvəlcə edilir və yalnız bundan sonra siz bu təcrübəni tətbiq etməyə başlayırsınız. Davamlı İnteqrasiya idrak yükünüzü azaldır, çünki gözlərinizlə gördüyünüz dəyişikliklərin hər biri o qədər açıqdır ki, onun nəyisə sındırıb-sındırmayacağını hətta testlər olmadan da anlayırsınız. Dəyişikliklər kiçik olduğu üçün bunu tez bir zamanda başınızda yoxlaya bilərsiniz. Yalnız əl test cihazlarınız olsa belə, onlar üçün də daha asandır. Siz yuvarlandın və dedin: "Bax, bir şey qırılıb?" Yoxladılar, “yox, heç nə pozulmayıb” dedilər. Çünki tester hara baxacağını bilir. Bir kod parçası ilə əlaqəli bir öhdəliyiniz var. Və bu, xüsusi davranışla istifadə olunur.
Burada, əlbəttə, bəzədilib.
(Dmitri) Mən burada razı deyiləm. Sizi bundan xilas edəcək bir təcrübə var - test əsaslı inkişaf.
(Oleq) Yaxşı, mən hələ o nöqtəyə çatmamışam. Birinci illüziya ondan ibarətdir ki, siz testlərin 100%-ni yazmalısınız və ya Davamlı İnteqrasiya etməyə ümumiyyətlə ehtiyacınız yoxdur. Bu doğru deyil. Bunlar iki paralel təcrübədir. Və onlar birbaşa asılı deyillər. Test əhatə dairəniz optimal olmalıdır. Optimal - bu o deməkdir ki, siz özünüz əminsiniz ki, ustanızın öhdəlikdən sonra qaldığı ustad keyfiyyəti sərxoş cümə axşamı "Yerləşdirmə" düyməsini inamla basmağa imkan verir. Buna necə nail olursunuz? Baxış vasitəsilə, əhatə dairəsi vasitəsilə, yaxşı monitorinq vasitəsilə.
Yaxşı monitorinq testlərdən fərqlənmir. Əgər siz əvvəlcədən məhsulda bir dəfə testlər keçirsəniz, onlar bütün istifadəçi skriptlərinizi bir dəfə yoxlayırlar və bu da budur. Əgər siz onları sonsuz bir döngədə işlədirsinizsə, bu, hər şeyi sonsuz şəkildə sınaqdan keçirən yerləşdirilmiş monitorinq sisteminizdir - qəzaya uğrayıb-yıxılmaması. Bu vəziyyətdə yeganə fərq, bir və ya iki dəfə edilməsidir. Çox yaxşı testlər dəsti... sonsuz işləyir, bu monitorinqdir. Və düzgün monitorinq belə olmalıdır.
Və buna görə də, cümə axşamı hazırlaşıb evə gedəndə bu vəziyyətə tam olaraq necə nail olacaqsınız, başqa sualdır. Ola bilsin ki, siz sadəcə cəsarətli bir pisliksiniz.
Gəlin Davamlı İnteqrasiyaya bir az qayıdaq. Bir az fərqli mürəkkəb məşqə qaçdıq.
İkinci illüziya isə odur ki, MVP-ni tez bir zamanda etmək lazımdır, ona görə də orada testlərə ümumiyyətlə ehtiyac yoxdur. Bu şəkildə deyil. Fakt budur ki, MVP-də bir istifadəçi hekayəsi yazdığınız zaman onu ya topda inkişaf etdirə bilərsiniz, yəni bir növ istifadəçi hekayəsinin olduğunu eşitdiniz və dərhal onu kodlamağa qaçdınız və ya TDD-dən istifadə edərək işləyə bilərsiniz. Və TDD-ə görə, təcrübədən göründüyü kimi, daha çox vaxt çəkmir, yəni testlər yan təsirdir. TDD təcrübəsi sınaqdan ibarət deyil. Testə əsaslanan inkişaf adlandırılana baxmayaraq, söhbət ümumiyyətlə testlərdən getmir. Bu həm də daha çox memarlıq yanaşmasıdır. Bu, lazım olanı yazmaq, lazım olmayanı yazmamaq yanaşmasıdır. Bu, tətbiq arxitekturasının yaradılması baxımından düşüncənizin növbəti iterasiyasına diqqət yetirmək təcrübəsidir.
Ona görə də bu illüziyalardan qurtulmaq o qədər də asan deyil. MVP və testlər bir-birinə zidd deyil. Hətta, əksinə, TDD təcrübəsindən istifadə edərək MVP etsəniz, bunu ümumiyyətlə məşq etmədən, ancaq topda etdiyinizdən daha yaxşı və daha sürətli edəcəksiniz.
Bu, çox aydın olmayan və mürəkkəb bir fikirdir. İndi daha çox testlər yazacağımı və eyni zamanda daha sürətli bir şey edəcəyimi eşidəndə bu, tamamilə qeyri-adekvat səslənir.
(Dmitri) Burada bir çox insanlar MVP deyəndə normal bir şey yazmağa çox tənbəl olurlar. Və bunlar hələ də fərqli şeylərdir. MVP-ni işləməyən bəzi pis şeyə çevirməyə ehtiyac yoxdur.
Bəli, bəli, haqlısınız.
Və sonra birdən məhsulda MVP.
Forever.
Testlər yazdığınızı və daha çox iş gördüyünü eşitdiyiniz zaman TDD çox qeyri-adi səslənir. Çox qəribə səslənir, amma əslində bu şəkildə daha sürətli və daha gözəl çıxır. Test yazarkən artıq beyninizdə hansı kodun və necə adlandırılacağı, həmçinin ondan hansı davranışı gözlədiyimiz barədə çox düşünürsünüz. Siz sadəcə demirsiniz ki, mən hansısa funksiyanı yazdım və o, nəsə edir. Əvvəlcə elə bilirdin ki, onun filan şəraiti var, filan cür çağırılacaq. Siz bunu testlərlə əhatə edirsiniz və buradan interfeyslərinizin kodunuzda necə görünəcəyini başa düşürsünüz. Bunun memarlığa böyük təsiri var. Kodunuz avtomatik olaraq daha modul olur, çünki əvvəlcə onu necə sınayacağınızı anlamağa çalışırsınız və yalnız bundan sonra yazın.
TDD ilə mənim başıma gələn o oldu ki, mən hələ Ruby proqramçısı olanda bir anda Ruby mentorunu işə götürdüm. Və deyir: "Gəlin bunu TDD-yə uyğun edək." Düşündüm: "Lənət olsun, indi əlavə bir şey yazmalıyam." Və razılaşdıq ki, iki həftə ərzində TDD-dən istifadə edərək Python-da bütün iş kodunu yazacağam. İki həftədən sonra geri qayıtmaq istəmədiyimi başa düşdüm. İki həftəlik bunu hər yerdə tətbiq etməyə çalışdıqdan sonra, sadəcə düşünməyin sizin üçün nə qədər asanlaşdığını anlayırsınız. Amma bu açıq-aşkar deyil, ona görə də mən hər kəsə tövsiyə edirəm ki, əgər sizdə TDD-nin çətin, vaxt aparan və lazımsız olduğunu hiss edirsinizsə, cəmi iki həftə ərzində onunla işləməyə çalışın. Mənim üçün ikisi kifayət idi.
(Dmitri) Biz bu fikri infrastrukturun istismarı baxımından genişləndirə bilərik. Yeni bir şey işə salmazdan əvvəl monitorinq edirik və sonra işə salırıq. Belə olan halda monitorinq bizim üçün normal sınaq halına gəlir. Və monitorinq yolu ilə inkişaf var. Amma demək olar ki, hamı deyir ki, uzundur, mən tənbələm, müvəqqəti qaralama hazırlamışam. Normal monitorinq etmişiksə, CI sisteminin vəziyyətini başa düşürük. Və CI sistemində çoxlu monitorinq var. Biz sistemin vəziyyətini başa düşürük, onun içində nə olduğunu başa düşürük. Və inkişaf zamanı biz sadəcə olaraq sistemi elə edirik ki, istənilən vəziyyətə çatsın.
Bu təcrübələr çoxdan məlumdur. Biz bunu təxminən 4 il əvvəl müzakirə etmişik. Amma 4 il ərzində praktiki olaraq heç nə dəyişməyib.
Amma bu qeyddə mən rəsmi müzakirəyə son qoymağı təklif edirəm.
Video (media elementi kimi daxil edilib, lakin nədənsə işləmir):
Mənbə: www.habr.com