Salam, Habr! Əvvəllər mən İnfrastrukturdakı həyatdan kod paradiqması kimi şikayət etdim və mövcud vəziyyəti həll etmək üçün heç nə təklif etmədim. Bu gün sizə ümidsizlik uçurumundan xilas olmağa və vəziyyəti düzgün istiqamətə yönəltməyə hansı yanaşma və təcrübələrin kömək edəcəyini söyləmək üçün qayıdıram.
Bir əvvəlki məqalədə Mən bu sahə ilə bağlı təəssüratlarımı bölüşdüm, bu sahədə mövcud vəziyyət haqqında düşünməyə çalışdım və hətta bütün tərtibatçılara məlum olan standart təcrübələrin kömək edə biləcəyini təklif etdim. Görünə bilər ki, həyatdan çoxlu şikayətlər var idi, amma mövcud vəziyyətdən çıxış yolu təklifləri yox idi.
Biz kimik, haradayıq və hansı problemlərimiz var
Hazırda biz altı proqramçı və üç infrastruktur mühəndisindən ibarət Sre Onboarding Team-dəyik. Hamımız İnfrastrukturu kod (IaC) kimi yazmağa çalışırıq. Biz bunu ona görə edirik ki, biz əsasən kodu necə yazmağı bilirik və “ortadan yuxarı” tərtibatçı olmaq tariximiz var.
- Bizim bir sıra üstünlüklərimiz var: müəyyən fon, təcrübə bilikləri, kod yazmaq bacarığı, yeni şeylər öyrənmək istəyi.
- Bir mənfi cəhət də var ki, bu da bir mənfi cəhətdir: infrastruktur avadanlıqları haqqında məlumatın olmaması.
IaC-də istifadə etdiyimiz texnologiya yığını.
- Resurs yaratmaq üçün terraform.
- Şəkillərin yığılması üçün qablaşdırıcı. Bunlar Windows, CentOS 7 şəkilləridir.
- Jsonnet drone.io-da güclü bir quruluş yaratmaq, həmçinin packer json və terraform modullarımızı yaratmaq üçün.
- Azure.
- Şəkillər hazırlayarkən həssasdır.
- Köməkçi xidmətlər və təminat skriptləri üçün Python.
- Bütün bunlar komanda üzvləri arasında paylaşılan plaginlərlə VSCode-da.
Məndən nəticə belə idi: Mən (ilk növbədə özümə) nikbinlik aşılamağa çalışdım, demək istədim ki, bu sahədə mövcud olan çətinliklər və mürəkkəbliklərin öhdəsindən gəlmək üçün bizə məlum olan yanaşma və təcrübələri sınayacağıq.
Hazırda biz aşağıdakı IaC problemləri ilə mübarizə aparırıq:
- Kod inkişafı üçün alət və vasitələrin qüsursuzluğu.
- Yavaş yerləşdirmə. İnfrastruktur real dünyanın bir hissəsidir və yavaş ola bilər.
- Yanaşmaların və təcrübələrin olmaması.
- Biz yeniyik və çox şey bilmirik.
Extreme Programming (XP) xilasetmə üçün
Bütün tərtibatçılar Ekstremal Proqramlaşdırma (XP) və onun arxasında duran təcrübələrlə tanışdırlar. Bir çoxumuz bu yanaşma ilə işləmişik və bu, uğurlu olmuşdur. Bəs niyə infrastruktur problemlərini aradan qaldırmaq üçün orada müəyyən edilmiş prinsip və təcrübələrdən istifadə etməyək? Bu cür yanaşmaq və nə baş verdiyini görmək qərarına gəldik.
XP yanaşmasının sənayeniz üçün tətbiqinin yoxlanılmasıXP-nin yaxşı uyğunlaşdığı mühitin təsviri və onun bizimlə əlaqəsi:
1. Dinamik olaraq dəyişən proqram təminatı tələbləri. Son məqsədin nə olduğu bizə aydın idi. Ancaq təfərrüatlar fərqli ola bilər. Biz özümüz hara taksi lazım olduğuna qərar veririk, buna görə tələblər vaxtaşırı dəyişir (əsasən özümüz). Avtomatlaşdırmanı özü həyata keçirən və özü tələbləri və iş həcmini məhdudlaşdıran SRE komandasını götürsək, bu məqam yaxşı uyğun gəlir.
2. Yeni texnologiyadan istifadə edərək müəyyən vaxta malik layihələrin yaratdığı risklər. Bizə məlum olmayan bəzi şeylərdən istifadə edərkən risklərlə qarşılaşa bilərik. Və bu 100% bizim vəziyyətimizdir. Bütün layihəmiz tam tanış olmadığımız texnologiyaların istifadəsi idi. Ümumiyyətlə, bu daimi problemdir, çünki... İnfrastruktur sektorunda hər zaman ortaya çıxan bir çox yeni texnologiyalar var.
3,4. Kiçik, birgə yerləşən genişləndirilmiş inkişaf komandası. İstifadə etdiyiniz avtomatlaşdırılmış texnologiya vahid və funksional testlərə imkan verir. Bu iki məqam bizə o qədər də uyğun gəlmir. Birincisi, biz koordinasiyalı komanda deyilik, ikincisi, doqquz nəfərik, böyük komanda sayıla bilər. Baxmayaraq ki, "böyük" komandanın bəzi təriflərinə görə, çoxu 14+ nəfərdir.
Gəlin bəzi XP təcrübələrinə və onların əks əlaqənin sürətinə və keyfiyyətinə necə təsir etdiyinə baxaq.
XP Əlaqə Loop Prinsip
Anladığım qədər geribildirim sualın cavabıdır, mən düzgün işləyirəmmi, ora gedirikmi? XP-də bunun üçün ilahi bir sxem var: vaxt geribildirimi. Maraqlısı odur ki, biz nə qədər aşağı olsaq, OS-nin lazımi suallara cavab verməsini bir o qədər tez əldə edə bilərik.
Bu, bizim İT sənayemizdə tez bir zamanda ƏS əldə etməyin mümkün olması ilə bağlı olduqca maraqlı müzakirə mövzusudur. Təsəvvür edin ki, altı ay ərzində bir layihə ilə məşğul olmaq nə qədər ağrılıdır və yalnız bundan sonra başlanğıcda bir səhv olduğunu öyrənin. Bu, dizaynda və mürəkkəb sistemlərin istənilən tikintisində baş verir.
IaC vəziyyətimizdə rəy bizə kömək edir. Dərhal yuxarıdakı diaqrama kiçik bir düzəliş edəcəyəm: buraxılış planının aylıq dövrü yoxdur, lakin gündə bir neçə dəfə baş verir. Bu OS dövrü ilə əlaqəli bəzi təcrübələr var ki, biz onları daha ətraflı nəzərdən keçirəcəyik.
Vacibdir: rəy yuxarıda qeyd olunan bütün problemlərin həlli ola bilər. XP təcrübələri ilə birlikdə sizi ümidsizlik uçurumundan çıxara bilər.
Özünüzü ümidsizlik uçurumundan necə çıxarmaq olar: üç təcrübə
Testlər
Testlər XP rəy döngəsində iki dəfə qeyd olunur. Sadəcə belə deyil. Onlar bütün Ekstremal Proqramlaşdırma texnikası üçün son dərəcə vacibdir.
Vahid və Qəbul testləriniz olduğu güman edilir. Bəziləri sizə bir neçə dəqiqə, bəziləri isə bir neçə gün ərzində rəy bildirir, ona görə də onların yazılması daha uzun çəkir və daha az nəzərdən keçirilir.
Klassik sınaq piramidası var ki, daha çox test olmalıdır.
Bu çərçivə IaC layihəsində bizə necə tətbiq olunur? Əslində... heç də yox.
- Vahid testləri, onların çox olmasına baxmayaraq, çox ola bilməz. Yoxsa çox dolayı yolla nəyisə sınaqdan keçirirlər. Əslində, biz bunları heç yazmırıq deyə bilərik. Ancaq bu cür testlər üçün edə bildiyimiz bir neçə tətbiq var:
- jsonnet kodu sınaqdan keçirilir. Bu, məsələn, bizim dron montaj boru kəmərimizdir, bu olduqca mürəkkəbdir. Jsonnet kodu testlərlə yaxşı əhatə olunub.
Biz bundan istifadə edirik . - Resurs işə salındıqda icra olunan skriptlər üçün testlər. Skriptlər Python-da yazılır və buna görə də onların üzərində testlər yazıla bilər.
- jsonnet kodu sınaqdan keçirilir. Bu, məsələn, bizim dron montaj boru kəmərimizdir, bu olduqca mürəkkəbdir. Jsonnet kodu testlərlə yaxşı əhatə olunub.
- Testlərdə konfiqurasiyanı yoxlamaq potensial olaraq mümkündür, lakin biz bunu etmirik. Yoxlama resursunun konfiqurasiya qaydalarını vasitəsilə konfiqurasiya etmək də mümkündür . Bununla belə, oradakı yoxlamalar terraform üçün çox sadədir, lakin bir çox test skriptləri AWS üçün yazılmışdır. Biz Azure-dayıq, ona görə də bu, yenidən tətbiq edilmir.
- Komponent inteqrasiya testləri: bu, onları necə təsnif etdiyinizdən və hara qoymağınızdan asılıdır. Amma əsasən işləyirlər.
İnteqrasiya testləri belə görünür.
Bu, Drone CI-də şəkillər yaratarkən bir nümunədir. Onlara çatmaq üçün Packer şəklinin formalaşması üçün 30 dəqiqə, sonra onların keçməsi üçün daha 15 dəqiqə gözləmək lazımdır. Ancaq onlar mövcuddur!Şəkil yoxlama alqoritmi
- Packer əvvəlcə təsviri tamamilə hazırlamalıdır.
- Testin yanında yerli vəziyyətə malik bir terraform var, bu görüntüyü yerləşdirmək üçün istifadə edirik.
- Açılan zaman, təsvirlə işləməyi asanlaşdırmaq üçün yaxınlıqda yerləşən kiçik bir modul istifadə olunur.
- VM təsvirdən yerləşdirildikdən sonra yoxlamalar başlaya bilər. Əsasən, yoxlamalar avtomobillə aparılır. Başlanğıcda skriptlərin necə işlədiyini və demonların necə işlədiyini yoxlayır. Bunu etmək üçün, ssh və ya winrm vasitəsilə biz yeni qaldırılmış maşına daxil oluruq və konfiqurasiya vəziyyətini və ya xidmətlərin işlək olub olmadığını yoxlayırıq.
- Terraform modullarında inteqrasiya testləri ilə də vəziyyət oxşardır. Bu cür testlərin xüsusiyyətlərini izah edən qısa bir cədvəldir.
Boru kəməri ilə bağlı rəy təxminən 40 dəqiqədir. Hər şey çox uzun müddət olur. Bu reqressiya üçün istifadə edilə bilər, lakin yeni inkişaf üçün ümumiyyətlə qeyri-realdır. Əgər buna çox, çox hazırsınızsa, işləyən skriptlər hazırlayın, onda 10 dəqiqəyə qədər azalda bilərsiniz. Ancaq bunlar hələ də 5 saniyədə 100 parça edən Vahid testləri deyil.
Şəkillərin və ya terraform modullarının yığılması zamanı vahid testlərinin olmaması işi sadəcə REST vasitəsilə idarə oluna bilən ayrı-ayrı xidmətlərə və ya Python skriptlərinə keçirməyə təşviq edir.
Məsələn, virtual maşın işə salındıqda özünü xidmətdə qeyd etdiyinə əmin olmalıyıq , və virtual maşın məhv edildikdə, o, özünü sildi.
Bizdə ScaleFT xidmət olduğu üçün API vasitəsilə onunla işləmək məcburiyyətindəyik. Orada bir sarğı yazılmışdı ki, onu çəkib deyə bilərsən: “Gir, bunu və bunu sil”. Bütün lazımi parametrləri və girişləri saxlayır.
Bunun üçün artıq normal testlər yaza bilərik, çünki bu, adi proqram təminatından heç bir fərqi yoxdur: bir növ apiha ələ salınır, onu çəkirsən və gör nə olur.
Testlərin nəticələri: Bir dəqiqə ərzində OS-yə verməli olan vahid testi onu vermir. Piramidada daha yüksək sınaq növləri effektivdir, lakin problemlərin yalnız bir hissəsini əhatə edir.
Cüt proqramlaşdırma
Testlər, əlbəttə ki, yaxşıdır. Onların çoxunu yaza bilərsiniz, onlar müxtəlif növ ola bilər. Onlar öz səviyyələrində işləyəcək və bizə rəy bildirəcəklər. Ancaq ən sürətli OS verən pis Unit testləri ilə bağlı problem qalır. Eyni zamanda, mən hələ də işləmək asan və xoş olan sürətli OS istəyirəm. Nəticə həllinin keyfiyyətini qeyd etmək olmaz. Xoşbəxtlikdən, vahid testlərdən daha sürətli geribildirim təmin edə bilən üsullar var. Bu cüt proqramlaşdırmadır.
Kod yazarkən onun keyfiyyəti haqqında mümkün qədər tez rəy əldə etmək istəyirsiniz. Bəli, hər şeyi bir xüsusiyyət bölməsində yaza bilərsiniz (heç kəs üçün heç bir şeyi pozmamaq üçün), Github-da bir çəkmə sorğusu edə bilərsiniz, fikri çəkisi olan birinə təyin edə və cavab gözləyə bilərsiniz.
Ancaq uzun müddət gözləyə bilərsiniz. İnsanların hamısı məşğuldur və bir cavab olsa belə, ən yüksək keyfiyyətdə olmaya bilər. Tutaq ki, cavab dərhal gəldi, rəyçi dərhal bütün fikri başa düşdü, amma cavab yenə də gec, faktdan sonra gəlir. Kaş ki, daha tez olsaydı. Cüt proqramlaşdırmanın məqsədi budur - dərhal, yazı zamanı.
Aşağıda cüt proqramlaşdırma üslubları və onların IaC-də işləyərkən tətbiqi imkanları verilmişdir:
1. Klassik, Təcrübəli+Təcrübəli, taymerlə dəyişin. İki rol - sürücü və naviqator. İki nəfər. Onlar eyni kod üzərində işləyirlər və əvvəlcədən müəyyən edilmiş müəyyən müddətdən sonra rolları dəyişirlər.
Problemlərimizin üslubla uyğunluğunu nəzərdən keçirək:
- Problem: kodun inkişafı üçün alətlərin və vasitələrin qüsursuzluğu.
Mənfi təsir: inkişafı daha uzun çəkir, biz yavaşlayırıq, işin tempi/ritmi itir.
Necə mübarizə aparırıq: biz fərqli alətlərdən, ümumi IDE-dən istifadə edirik və həmçinin qısa yolları öyrənirik. - Problem: Yavaş yerləşdirmə.
Mənfi təsir: işləyən kod parçası yaratmaq üçün lazım olan vaxtı artırır. Gözləyəndə darıxırıq, gözləyərkən əllərimiz başqa bir şey etmək üçün uzanır.
Necə mübarizə aparırıq: bunun öhdəsindən gələ bilmədik. - Problem: yanaşmaların və təcrübələrin olmaması.
Mənfi təsir: bunu necə yaxşı və necə pis etmək barədə heç bir məlumat yoxdur. Rəyin qəbulunu uzadır.
Necə mübarizə aparırıq: cüt işdə qarşılıqlı fikir mübadiləsi və təcrübə demək olar ki, problemi həll edir.
IaC-də bu üslubdan istifadə ilə bağlı əsas problem qeyri-bərabər iş tempidir. Ənənəvi proqram təminatı inkişafında çox vahid bir hərəkətiniz var. Beş dəqiqə sərf edib N yaza bilərsiniz. 10 dəqiqə sərf edib 2N, 15 dəqiqə - 3N yaza bilərsiniz. Burada beş dəqiqə sərf edib N yaza bilərsən, sonra daha 30 dəqiqə sərf edib N-nin onda birini yaza bilərsən. Burada heç nə bilmirsən, ilişib qalırsan, axmaq. İstintaq vaxt aparır və diqqəti proqramlaşdırmadan yayındırır.
Nəticə: təmiz formada bizim üçün uyğun deyil.
2. Pinq-ponq. Bu yanaşma bir şəxsin testi yazmasını, digərinin isə bunun üçün həyata keçirməsini əhatə edir. Unit testləri ilə hər şeyin mürəkkəb olduğunu və proqramlaşdırması çox vaxt aparan inteqrasiya testini yazmalı olduğunuzu nəzərə alsaq, stolüstü tennisin bütün asanlığı yox olur.
Deyə bilərəm ki, biz test skriptinin hazırlanması və onun kodunun tətbiqi üçün məsuliyyətləri ayırmağa çalışdıq. Bir iştirakçı ssenari ilə çıxış etdi, işin bu hissəsində o, cavabdeh idi, son söz dedi. Digəri isə icraya cavabdeh idi. Yaxşı nəticə verdi. Bu yanaşma ilə ssenarinin keyfiyyəti artır.
Nəticə: təəssüf ki, iş tempi stolüstü tennisdən IaC-də cüt proqramlaşdırma təcrübəsi kimi istifadə etməyə imkan vermir.
3.Güclü Stil. . İdeya ondan ibarətdir ki, bir iştirakçı direktiv naviqator olur, ikincisi isə icra sürücüsü rolunu alır. Bu halda, qərar qəbul etmək hüququ yalnız naviqatorun üzərinə düşür. Sürücü yalnız çap edir və bir sözlə baş verənlərə təsir edə bilər. Rollar uzun müddət dəyişmir.
Öyrənmək üçün yaxşıdır, lakin güclü yumşaq bacarıqlar tələb edir. Budur, biz tələsdik. Texnika çətin idi. Və söhbət heç də infrastrukturdan getmir.
Nəticə: potensial olaraq istifadə edilə bilər, biz cəhddən əl çəkmirik.
4. Mobbing, swarming və bütün məlum, lakin sadalanmayan üslublar Biz bunu hesab etmirik, çünki Biz bunu sınamamışıq və işimizin kontekstində bu barədə danışmaq mümkün deyil.
Cüt proqramlaşdırmadan istifadə üzrə ümumi nəticələr:
- Bizdə qeyri-bərabər iş tempi var ki, bu da çaşqınlıq yaradır.
- Biz kifayət qədər yaxşı yumşaq bacarıqlara rast gəldik. Mövzu sahəsi isə bizim bu çatışmazlıqlarımızı aradan qaldırmağa kömək etmir.
- Uzun sınaqlar və alətlərlə bağlı problemlər qoşalaşmış inkişafı çətinləşdirir.
5. Buna baxmayaraq, uğurlar da oldu. Biz öz “Konvergensiya - Divergensiya” metodumuzu tapdıq. Bunun necə işlədiyini qısaca təsvir edəcəyəm.
Bir neçə günlük (bir həftədən az) daimi tərəfdaşlarımız var. Bir işi birlikdə edirik. Bir müddət birlikdə otururuq: biri yazır, digəri oturub dəstək komandasına baxır. Sonra bir müddət dağılırıq, hər biri müstəqil işlər görür, sonra yenidən bir araya gəlirik, çox tez sinxronizasiya edirik, birlikdə nəsə edirik və yenidən dağılırıq.
Planlaşdırma və ünsiyyət
OS problemlərinin həll olunduğu təcrübələrin son bloku tapşırıqların özləri ilə işin təşkilidir. Buraya həm də cüt işdən kənar təcrübə mübadiləsi daxildir. Üç praktikaya baxaq:
1. Məqsəd ağacı vasitəsilə məqsədlər. Biz layihənin ümumi idarəçiliyini sonsuz gələcəyə gedən bir ağac vasitəsilə təşkil etdik. Texniki olaraq, izləmə Miro-da aparılır. Bir vəzifə var - bu, aralıq məqsəddir. Ondan ya kiçik məqsədlər və ya tapşırıqlar qrupları gedir. Tapşırıqlar özləri onlardan gəlir. Bütün tapşırıqlar bu lövhədə yaradılır və saxlanılır.
Bu sxem həm də mitinqlərdə sinxronlaşdırdığımız zaman gündə bir dəfə baş verən əks əlaqəni təmin edir. Hər kəsin qarşısında ümumi, lakin strukturlaşdırılmış və tamamilə açıq plana sahib olmaq hər kəsin nə baş verdiyindən və nə qədər irəlilədiyimizdən xəbərdar olmağa imkan verir.
Tapşırıqların vizual görməsinin üstünlükləri:
- Səbəb əlaqəsi. Hər bir tapşırıq hansısa qlobal məqsədə gətirib çıxarır. Tapşırıqlar kiçik məqsədlər üçün qruplaşdırılır. İnfrastruktur sahəsinin özü olduqca texnikidir. Məsələn, başqa nginx-ə miqrasiya ilə bağlı runbook yazmağın biznesə hansı xüsusi təsir göstərdiyi həmişə dərhal aydın olmur. Yaxınlıqda hədəf kartın olması onu daha aydın edir.
Səbəb əlaqəsi problemlərin mühüm xüsusiyyətidir. O, birbaşa suala cavab verir: "Mən doğru şeyi edirəm?" - Paralellik. Biz doqquz nəfərik və hamını bir tapşırığa atmaq fiziki cəhətdən mümkün deyil. Bir sahədən tapşırıqlar həmişə kifayət olmaya bilər. Biz kiçik işçi qrupları arasında işi paralel aparmağa məcburuq. Eyni zamanda, qruplar bir müddət öz tapşırıqları üzərində otururlar, onları başqası gücləndirə bilər. Bəzən insanlar bu işçi qrupundan uzaqlaşırlar. Kimsə tətilə gedir, kimsə DevOps conf üçün hesabat hazırlayır, kimsə Habr-da məqalə yazır. Paralel olaraq hansı məqsəd və vəzifələrin həyata keçirilə biləcəyini bilmək çox vacib olur.
2. Səhər iclaslarının əvəzedici aparıcıları. Stand-uplarda bizdə bu problem var - insanlar paralel olaraq bir çox işi görürlər. Bəzən tapşırıqlar bir-biri ilə sıx bağlıdır və kimin nə etdiyini başa düşmək olmur. Digər komanda üzvünün fikri isə çox önəmlidir. Bu, problemin həlli kursunu dəyişə biləcək əlavə məlumatdır. Əlbəttə ki, adətən yanınızda kimsə var, amma məsləhətlər və məsləhətlər həmişə faydalıdır.
Bu vəziyyəti yaxşılaşdırmaq üçün biz “Aparıcı Stand-Upun dəyişdirilməsi” texnikasından istifadə etdik. İndi onlar müəyyən siyahıya görə fırlanır və bu da öz təsirini göstərir. Növbə sizə gəldikdə, yaxşı bir Scrum görüşünü keçirmək üçün içəri girmək və nə baş verdiyini anlamaq məcburiyyətindəsiniz.
3. Daxili demo. Cüt proqramlaşdırmadan problemin həllində kömək, problem ağacında vizuallaşdırma və səhər skrum görüşlərində kömək yaxşıdır, lakin ideal deyil. Bir cüt olaraq, yalnız biliklərinizlə məhdudlaşırsınız. Tapşırıq ağacı qlobal olaraq kimin nə etdiyini anlamağa kömək edir. Səhər iclasındakı aparıcı və həmkarlar problemlərinizə dərindən girməyəcəklər. Onlar, şübhəsiz ki, nəyisə qaçıra bilərlər.
Həll yolu görülən işləri bir-birinə nümayiş etdirməkdə və sonra müzakirə etməkdə tapıldı. Biz həftədə bir dəfə bir saat görüşürük və son bir həftə ərzində gördüyümüz tapşırıqların həlli yollarını göstəririk.
Nümayiş zamanı tapşırığın təfərrüatlarını açıqlamaq və onun işini mütləq nümayiş etdirmək lazımdır.
Hesabat yoxlama siyahısından istifadə etməklə aparıla bilər.1. Kontekstə daxil olun. Tapşırıq haradan gəldi, niyə lazım idi?
2. Problem əvvəllər necə həll olunurdu? Məsələn, siçanın kütləvi kliklənməsi tələb olunurdu və ya ümumiyyətlə heç nə etmək mümkün deyildi.
3. Biz onu necə təkmilləşdiririk. Məsələn: "Bax, indi scriptosik var, bu da readme."
4. Necə işlədiyini göstərin. Bəzi istifadəçi ssenarisini birbaşa həyata keçirmək məsləhətdir. Mən X istəyirəm, Y edirəm, Y (və ya Z) görürəm. Məsələn, mən NGINX yerləşdirirəm, url-ni çəkirəm və 200 OK alıram. Əgər hərəkət uzun olarsa, onu əvvəlcədən hazırlayın ki, sonra göstərə biləsiniz. Əgər kövrəkdirsə, nümayişdən bir saat əvvəl onu çox pozmamaq məsləhətdir.
5. Problemin necə uğurla həll edildiyini, hansı çətinliklərin qaldığını, nəyin tamamlanmadığını, gələcəkdə hansı təkmilləşdirmələrin mümkün olduğunu izah edin. Məsələn, indi CLI, sonra CI-də tam avtomatlaşdırma olacaq.
Hər bir natiq üçün 5-10 dəqiqə saxlaması məsləhətdir. Əgər nitqiniz açıq-aydın vacibdirsə və daha uzun sürəcəksə, bunu sre-ələ keçirmə kanalında əvvəlcədən əlaqələndirin.
Üzbəüz hissədən sonra mövzuda həmişə müzakirə olur. Tapşırıqlarımızla bağlı ehtiyac duyduğumuz rəy burada görünür.
Nəticədə, baş verənlərin faydalılığını müəyyən etmək üçün sorğu aparılır. Bu, nitqin mahiyyəti və tapşırığın əhəmiyyəti ilə bağlı rəydir.
Uzun nəticələr və bundan sonra nə olacaq
Görünə bilər ki, məqalənin tonu bir qədər bədbindir. Bu səhvdir. Əlaqənin iki aşağı səviyyəsi, yəni testlər və cüt proqramlaşdırma işləyir. Ənənəvi inkişafda olduğu kimi mükəmməl deyil, amma bunun müsbət təsiri var.
Testlər, hazırkı formada, yalnız qismən kodu əhatə edir. Bir çox konfiqurasiya funksiyaları sınaqdan keçirilməmişdir. Kod yazarkən onların faktiki işə təsiri azdır. Bununla belə, inteqrasiya testlərinin təsiri var və onlar qorxmadan refaktorinqlər aparmağa imkan verir. Bu, böyük nailiyyətdir. Həmçinin, diqqətin yüksək səviyyəli dillərdə inkişafa keçməsi ilə (bizdə python var, get) problem aradan qalxır. Və "yapışqan" üçün çoxlu yoxlamalara ehtiyacınız yoxdur, ümumi inteqrasiya yoxlaması kifayətdir.
Cütlərdə işləmək daha çox konkret insanlardan asılıdır. Tapşırıq faktoru və yumşaq bacarıqlarımız var. Bəzi insanlarda çox yaxşı işləyir, digərlərində isə daha pisdir. Bunun mütləq faydaları var. Aydındır ki, cüt işin qaydalarına kifayət qədər riayət edilməsə belə, tapşırıqların birlikdə yerinə yetirilməsi faktının özü nəticənin keyfiyyətinə müsbət təsir göstərir. Şəxsən mənə cütlükdə işləmək daha asan və daha xoş gəlir.
ƏS-ə təsir etməyin daha yüksək səviyyəli yolları - planlaşdırma və tapşırıqlarla işləmək dəqiq effekt verir: yüksək keyfiyyətli bilik mübadiləsi və təkmilləşdirilmiş inkişaf keyfiyyəti.
Bir sətirdə qısa nəticələr
- HR praktikləri IaC-də işləyirlər, lakin daha az səmərəlidir.
- Nə işlədiyini gücləndirin.
- Öz kompensasiya mexanizmləriniz və təcrübələrinizlə gəlin.
Mənbə: www.habr.com