Неліктен CI құралдары мен CI мүлдем басқа нәрселер екенін талқылайық.
CI қандай ауруды шешуге арналған, идея қайдан пайда болды, оның жұмыс істейтіндігі туралы соңғы растаулар қандай, сізде Дженкинсті орнатпаған тәжірибе бар екенін қалай түсінуге болады.
Үздіксіз интеграция туралы репортаж жасау идеясы бір жыл бұрын сұхбат алуға және жұмыс іздеп жүргенімде пайда болды. Мен 10-15 компаниямен сөйлестім, олардың біреуі ғана CI деген не екенін нақты жауап бере алды және оларда оның жоқ екенін қалай түсінгендерін түсіндіре алды. Қалғандары Дженкинс туралы түсініксіз сандырақ айтты :) Ал, бізде Дженкинс бар, ол жасайды, CI! Баяндама барысында мен Үздіксіз интеграция деген не екенін және Дженкинс пен ұқсас құралдардың неліктен мұнымен өте әлсіз байланысы бар екенін түсіндіруге тырысамын.
Сонымен, CI деген сөзді естігенде әдетте не ойға келеді? Көптеген адамдар Дженкинс, Гитлаб CI, Травис және т.б. туралы ойлайды.
Біз оны гуглдан іздесек те, ол бізге осы құралдарды береді.
Сұраумен таныс болсаңыз, құралдарды тізімдегеннен кейін бірден олар сізге тапсырмаға тарту сұрауында сынақтарды құрастыру және іске қосу кезінде CI екенін айтады.
Үздіксіз интеграция - бұл құралдар туралы емес, филиалдағы сынақтары бар жинақтар туралы емес! Үздіксіз интеграция - бұл жаңа кодты өте жиі біріктіру тәжірибесі және оны пайдалану үшін Дженкинс, GitLab және т.б. қоршау қажет емес.
Толық CI қандай болатынын білмес бұрын, алдымен оны ойлап тапқан адамдардың контекстіне сүңгіп, олар шешуге тырысқан ауырсынуды сезінейік.
Олар команда болып жұмыс істеудің азабын шешті!
Әзірлеушілер топта даму кезінде кездесетін қиындықтардың мысалдарын қарастырайық. Мұнда бізде жоба, git-тегі негізгі бөлім және екі әзірлеуші бар.
Және олар бәрі бұрыннан үйреніп кеткендей жұмысқа кетті. Біз заттардың үлкен схемасында тапсырма алдық, функция тармағын жасап, кодты жаздық.
Біреуі функцияны тезірек аяқтап, оны шеберге біріктірді.
Екіншісіне көп уақыт керек болды, ол кейін қосылып, жанжалмен аяқталды. Енді әзірлеуші бизнеске қажет мүмкіндіктерді жазудың орнына, өз уақыты мен күшін қақтығыстарды шешуге жұмсайды.
Мүмкіндікті жалпы шебермен біріктіру неғұрлым қиын болса, соғұрлым біз оған көбірек уақыт бөлеміз. Мен мұны өте қарапайым мысалмен көрсеттім. Бұл тек 2 әзірлеуші болатын мысал. Елестетіп көріңізші, компаниядағы 10 немесе 15 немесе 100 адам бір репозиторийге жазады. Осы жанжалдардың бәрін шешу үшін сіз ақылсыз боласыз.
Біраз басқа жағдай бар. Бізде шебер және кейбір әзірлеушілер бірдеңе істеп жатыр.
Олар бұтақ жасады.
Біреуі қайтыс болды, бәрі жақсы болды, ол тапсырманы тапсырды.
Ал екінші әзірлеуші өз міндетін тапсырды. Оны тексеруге жіберді делік. Көптеген компанияларда шолу деп аталатын тәжірибе бар. Бір жағынан, бұл тәжірибе жақсы және пайдалы болса, екінші жағынан, ол бізді көптеген жағынан баяулатады. Біз бұған кірмейміз, бірақ міне, нашар шолу оқиғасы неге әкелуі мүмкін екендігінің тамаша мысалы. Сіз тексеруге сұрауды жібердіңіз. Әзірлеушіге басқа ештеңе жоқ. Ол не істей бастайды? Ол басқа тапсырмаларды орындауға кіріседі.
Осы уақыт ішінде екінші әзірлеуші тағы бір нәрсе жасады.
Біріншісі үшінші тапсырманы орындады.
Біраз уақыттан кейін оның шолуы сыналды және ол келісімге келуге тырысады. Сонымен, не болып жатыр? Ол көптеген қақтығыстарды ұстайды. Неліктен? Өйткені оның сұрауы шолуда ілулі тұрғанда, кодта көп нәрсе өзгерді.
Қақтығыстары бар оқиғадан басқа, коммуникациялар бар әңгіме бар. Сіздің ағын шолуда ілулі тұрғанда, ол бірдеңені күтіп тұрғанда, функциямен ұзақ уақыт жұмыс істеп жатқанда, қызметіңіздің код базасында тағы не өзгеретінін бақылауды тоқтатасыз. Мүмкін сіз қазір шешуге тырысып жатқан нәрсе кеше шешілген және сіз қандай да бір әдісті алып, оны қайта пайдалана аласыз. Бірақ сіз мұны көрмейсіз, себебі сіз әрқашан ескірген филиалмен жұмыс жасайсыз. Және бұл ескірген филиал әрқашан біріктіру қайшылығын шешуге әкеледі.
Егер біз бір команда болып жұмыс жасасақ, яғни репозиторийде бір адам емес, 5-10 адам айналысса, кодты шеберге ұзағырақ қоспасақ, соғұрлым көп зардап шегеміз, өйткені бізге ақыр соңында қажет. бір нәрсе, содан кейін оны біріктіріңіз. Бізде қаншалықты көп қақтығыстар болса және біз жұмыс істейтін ескі нұсқада, бізде соғұрлым көп проблемалар бар.
Бірге бірдеңе жасау өте ауыр! Біз әрқашан бір-бірімізге кедергі келтіреміз.
Бұл мәселе 20 жылдан астам бұрын байқалды. Мен экстремалды бағдарламалаудағы үздіксіз интеграция тәжірибесі туралы алғашқы ескертуді таптым.
Экстремалды бағдарламалау - бұл алғашқы икемді фреймворк. Бұл бет 96 жылы пайда болды. Ал идея бағдарламалау тәжірибесін, жоспарлауды және басқа да нәрселерді пайдалану болды, осылайша әзірлеу мүмкіндігінше икемді болады, осылайша біз клиенттеріміздің кез келген өзгерістеріне немесе талаптарына тез жауап бере аламыз. Олар осыдан 24 жыл бұрын, егер сіз бірдеңені өте ұзақ уақыт және шетте қалатын болсаңыз, онда сізде қақтығыстар болғандықтан оған көбірек уақыт бөлетіндігіңізбен бетпе-бет келе бастады.
Енді біз «Үздіксіз интеграция» тіркесін жеке талдаймыз. Егер біз оны тікелей аударсақ, біз үздіксіз интеграция аламыз. Бірақ оның қаншалықты үздіксіз екендігі анық емес, ол өте үзіліссіз. Бірақ оның қаншалықты интеграцияланғаны да анық емес.
Сондықтан мен қазір экстремалды бағдарламалаудан дәйексөздерді ұсынамын. Ал біз екі сөзді бөлек талдаймыз.
Интеграция - Жоғарыда айтқанымдай, біз әрбір инженер кодтың ең соңғы нұсқасымен жұмыс істеуін қамтамасыз етуге тырысамыз, осылайша ол өз кодын мүмкіндігінше жиі ортақ тармаққа қосуға тырысады, осылайша бұл кішігірім филиалдар. Өйткені, егер олар үлкен болса, онда біз бір апта бойы біріктіру қақтығыстарына оңай түсе аламыз. Бұл, әсіресе, егер бізде сарқырама сияқты ұзақ даму циклі болса, онда әзірлеуші бір ай бойы үлкен мүмкіндікті кесіп тастаған болса. Және ол интеграциялық кезеңде өте ұзақ уақыт тұрып қалады.
Интеграция дегеніміз - біз филиалымызды алып, оны шебермен біріктіреміз, біз оны біріктіреміз. Біз трансбаза әзірлеушісі болған кезде, біз шеберге ешқандай қосымша тармақтарсыз дереу жазуды қамтамасыз етуге тырысамыз.
Жалпы алғанда, интеграция сіздің кодыңызды алып, оны шеберге апаруды білдіреді.
Бұл жерде «үздіксіз» деген сөз нені білдіреді, үздіксіздік деп нені айтамыз? Практика әзірлеуші өз кодын мүмкіндігінше тезірек біріктіруге тырысатынын білдіреді. Бұл оның кез келген тапсырманы орындау кезіндегі мақсаты - оның кодын шеберге мүмкіндігінше тезірек енгізу. Идеал әлемде әзірлеушілер мұны бірнеше сағат сайын жасайды. Яғни, сіз кішкене мәселені алып, оны шеберге біріктіресіз. Бәрі керемет. Бұл сіз ұмтылатын нәрсе. Және бұл үздіксіз жасалуы керек. Бірдеңе істеген бойда оны бірден шеберге саласыз.
Ал бірдеңені жасайтын әзірлеуші оның жұмыс істеуі және ештеңені бұзбауы үшін жасаған әрекетіне жауап береді. Бұл жерде әдетте сынақ оқиғасы шығады. Біз оның жұмыс істейтініне көз жеткізу үшін міндеттемеде, біріктіруде кейбір сынақтарды өткізгіміз келеді. Міне, Дженкинс сізге көмектесе алады.
Бірақ әңгімелермен: өзгертулерді кішігірім жасайық, тапсырмаларды кішігірім етіп алайық, мәселені шешіп, оны бірден шеберге енгізуге тырысайық - мұнда Дженкинс көмектеспейді. Өйткені Дженкинс тек сынақтарды жүргізуге көмектеседі.
Сіз оларсыз жасай аласыз. Бұл сізге мүлде зиян тигізбейді. Өйткені тәжірибенің мақсаты - болашақта кез келген қақтығыстарға көп уақытты жоғалтпау үшін мүмкіндігінше жиі өлшеу.
Қандай да бір себептермен 2020 жылы интернетсіз қалдық деп елестетейік. Ал біз жергілікті жерде жұмыс істейміз. Бізде Дженкинс жоқ. Бұл жақсы. Сіз әлі де алға шығып, жергілікті филиал жасай аласыз. Сіз оған кейбір код жаздыңыз. Тапсырманы 3-4 сағатта орындадық. Біз мастерге ауысып, git pull жасадық және филиалымызды сол жерде біріктірдік. Дайын. Егер сіз мұны жиі жасасаңыз, құттықтаймыз, сізде үздіксіз интеграция бар!
Қазіргі әлемде энергияны жұмсауға тұрарлық қандай дәлелдер бар? Өйткені, жалпы бұл қиын. Егер сіз осылай жұмыс істеуге тырыссаңыз, кейбір жоспарлауға енді әсер ететінін түсінесіз, сізге тапсырмаларды бөлшектеуге көбірек уақыт бөлуге тура келеді. Өйткені адам... жасасаңыз, онда сіз тез тіл табыса алмайсыз және сәйкесінше, қиындыққа тап боласыз. Енді сізде жаттығу болмайды.
Және бұл қымбат болады. Үздіксіз интеграцияны пайдаланып ертеңнен бастап бірден жұмыс істеу мүмкін болмайды. Барлығыңызға үйрену үшін өте ұзақ уақыт қажет, тапсырмаларды бөлшектеуге дағдылану өте ұзақ уақыт алады, егер сізде бар болса, шолу тәжірибесін қайта орындауға дағдылану өте ұзақ уақытты алады. . Өйткені біздің мақсатымыз – оның бүгін еруі. Егер сіз үш күн ішінде шолуды жасасаңыз, сізде проблемалар бар және Үздіксіз интеграция сіз үшін жұмыс істемейді.
Бірақ дәл қазір бізде осы тәжірибеге инвестиция салудың мағынасы бар екенін көрсететін тиісті дәлелдер бар ма?
Менің ойыма келген бірінші нәрсе DevOps күйі болды. Бұл жігіттердің 7 жыл бойы жүргізген зерттеуі. Енді олар мұны тәуелсіз ұйым ретінде жасайды, бірақ Google астында.
Ал олардың 2018 жылғы зерттеуі жылдам біріктірілетін, жиі біріктірілетін және АТ өнімділігінің көрсеткіштері жақсырақ қысқа мерзімді филиалдарды пайдалануға тырысатын компаниялар арасындағы корреляцияны көрсетті.
Бұл көрсеткіштер қандай? Бұл сауалнамалардағы барлық компаниялардан алатын 4 көрсеткіш: орналастыру жиілігі, өзгертулерді орындау уақыты, қызметті қалпына келтіру уақыты, сәтсіздік деңгейі.
Және, біріншіден, бұл корреляция бар, біз жиі өлшейтін компаниялар әлдеқайда жақсы көрсеткіштерге ие екенін білеміз. Және оларда компанияларды бірнеше санатқа бөлу бар: бұл бірдеңені баяу шығаратын баяу, орташа өнімді, жоғары өнімді және элиталық компаниялар. Элита - бұл Netflix, Amazon, олар өте жылдам, бәрін тез, әдемі және тиімді жасайды.
Бір ай бұрын болған екінші оқиға. Technology Radar-да Gitflow туралы тамаша мақала бар. Gitflow басқалардан ерекшеленеді, оның тармақтары ұзақ өмір сүреді. Ұзақ өмір сүретін босату тармақтары бар және ұзақ уақыт бойы өмір сүретін тармақтары бар. Технологиялық радардағы бұл тәжірибе HOLD режиміне көшті. Неліктен? Өйткені адамдар интеграцияның азабына ұшырайды.
Егер сіздің филиалыңыз өте ұзақ өмір сүрсе, ол кептеліп қалады, шіріп кетеді және біз оған қандай да бір өзгеріс енгізуге көбірек уақыт жұмсай бастаймыз.
Жақында Gitflow авторы егер сіздің мақсатыңыз Үздіксіз интеграция болса, егер сіздің мақсатыңыз мүмкіндігінше жиі айналдыруды қаласаңыз, Gitflow жаман идея екенін айтты. Ол мақалаға бөлек қосты, егер сізде бұған ұмтылуға болатын сервер болса, онда Gitflow сіз үшін артық, өйткені Gitflow сізді баяулатады, Gitflow сізге интеграцияда қиындықтар тудырады.
Бұл Gitflow нашар және оны пайдаланбау керек дегенді білдірмейді. Бұл басқа жағдайларға арналған. Мысалы, сізге қызметтің немесе қолданбаның бірнеше нұсқасын қолдау қажет болғанда, яғни ұзақ уақыт бойы қолдау қажет болғанда.
Бірақ егер сіз осындай қызметтерді қолдайтын адамдармен сөйлессеңіз, сіз бұл нұсқа 3.2 болғаны туралы көп ауырсынуды естисіз, ол 4 ай бұрын болды, бірақ бұл түзету оған қосылмаған және қазір оны жасау үшін, көптеген өзгерістер енгізу керек. Енді олар қайтадан кептеліп қалды, енді олар бір апта бойы жаңа мүмкіндікті енгізуге тырысты.
Александр Ковалев чатта дұрыс атап өткендей, корреляция себептілікпен бірдей емес. Бұл осылай. Яғни, егер сізде Үздіксіз интеграция болса, онда барлық көрсеткіштер тамаша болады деген тікелей байланыс жоқ. Бірақ егер біреуі біреу болса, екіншісі де болуы мүмкін деген оң корреляция бар. Факт емес, бірақ ең ықтимал. Бұл жай ғана корреляция.
Біз қазірдің өзінде бірдеңе істеп жатқан сияқтымыз, біз қазірдің өзінде біріктіріліп жатқан сияқтымыз, бірақ бізде әлі де Үздіксіз интеграция бар екенін, біз жиі біріктіріліп жатқанымызды қалай түсінуге болады?
Джез Хумбл – анықтамалық, Accelerate, үздіксіз жеткізу веб-сайты және үздіксіз жеткізу кітабының авторы. Ол мына сынақты ұсынады:
- Инженердің коды шеберге күн сайын түседі.
- Әрбір міндеттеме үшін сіз бірлік сынақтарын орындайсыз.
- Мастердегі құрылыс құлады, ол шамамен 10 минутта бекітілді.
Ол жеткілікті тәжірибеңіз бар екеніне көз жеткізу үшін осындай сынақты қолдануды ұсынады.
Мен соңғысын аздап даулы деп санаймын. Яғни, егер сіз оны 10 минут ішінде түзете алсаңыз, онда сізде Үздіксіз интеграция бар, бұл менің ойымша, сәл оғаш естіледі, бірақ мағынасы бар. Неліктен? Өйткені жиі қатып қалсаңыз, бұл сіздің өзгерістеріңіз аз екенін білдіреді. Кішігірім өзгерту сіздің негізгі құрылымыңыздың бұзылғанын білдірсе, онда өзгеріс аз болғандықтан, мысалды тез табуға болады. Мұнда сізде шағын біріктіру болды, ондағы 20-30 жол өзгерді. Және, тиісінше, оның себебін тез түсінуге болады, өйткені өзгерістер кішкентай, сізде мәселені іздеу үшін өте аз аймақ бар.
Шығарылғаннан кейін өніміміз ыдырап кетсе де, егер бізде Үздіксіз интеграция тәжірибесі болса, бізге әрекет ету әлдеқайда оңай, өйткені өзгерістер аз. Иә, бұл жоспарлауға әсер етеді. Бұл ауырады. Және, бәлкім, бұл тәжірибедегі ең қиын нәрсе - тапсырмаларды бөлшектеуге дағдылану, яғни сіз бірдеңені алып, оны бірнеше сағат ішінде орындай аласыз және сонымен бірге шолудан өтуге болады, егер сізде біреуі бар. Қарау - бұл бөлек ауырсыну.
Бірлік сынақтары - бұл интеграция сәтті болғанын және ештеңе бұзылмағанын түсінуге көмектесетін көмекші. Менің ойымша, бұл да толығымен міндетті емес, өйткені бұл тәжірибенің мәні емес.
Бұл Үздіксіз интеграцияға қысқаша кіріспе. Бұл тәжірибеде бар нәрсе бар. Мен сұрақтарға дайынмын.
Мен тағы да қысқаша қорытындылаймын:
- Үздіксіз интеграция Дженкинс емес, Гитлаб емес.
- Бұл құрал емес, бұл біздің кодты шеберге мүмкіндігінше жиі біріктіретін тәжірибе.
- Біз мұны болашақта біріктіру кезінде пайда болатын үлкен ауырсынуды болдырмау үшін жасаймыз, яғни болашақта көп нәрсені сезінбеу үшін қазір аздап ауырсынуды сезінеміз. Мәселе осында.
- Бүйір жағында код арқылы байланыс бар, бірақ мен мұны өте сирек көремін, бірақ бұл да ол үшін жасалған.
Сіздің сұрақтарыңыз
Бөлінбеген тапсырмалармен не істеу керек?
Ыдырау. Мәселе неде? Мысал келтіре аласыз ба, тапсырма бар және ол ыдырамайды?
«Толық» сөзінен ажыратуға болмайтын міндеттер бар, мысалы, өте терең тәжірибені қажет ететін және сіңімді нәтижеге жету үшін бір ай ішінде шынымен шешілетін тапсырмалар.
Егер мен сізді дұрыс түсінсем, нәтижесі бір айдан кейін ғана көрінетін үлкен және күрделі тапсырма бар ма?
Иә дұрыс. Иә, нәтижені бір айдан ерте емес бағалауға болады.
Жақсы. Жалпы бұл проблема емес. Неліктен? Өйткені бұл жағдайда бұтақтар туралы айтқанда, біз ерекшелігі бар бұтақ туралы айтпаймыз. Мүмкіндіктер үлкен және күрделі болуы мүмкін. Олар көптеген компоненттерге әсер етуі мүмкін. Мүмкін, біз оларды бір салада толығымен жасай алмаймыз. Бұл жақсы. Бізге бұл оқиғаны бөлшектеу керек. Егер мүмкіндік толығымен дайын болмаса, бұл оның кодының кейбір бөліктерін біріктіру мүмкін емес дегенді білдірмейді. Сіз, айталық, тасымалдауды қостыңыз және функцияның ішінде кейбір кезеңдері бар. Сізде кезең бар делік - көшіруді жасаңыз, жаңа әдісті қосыңыз. Ал сіз бұл заттарды күн сайын өлшей аласыз.
Жақсы. Сонда оның мәні неде?
Күнделікті кішкентай нәрселерді өлтірудің мәні неде?
Иә.
Егер олар бір нәрсені сындырса, сіз оны бірден көресіз. Сізде бірдеңені сындырған кішкене бөлік бар, оны жөндеу сізге оңайырақ. Мәселе мынада, кішкене бөлікті қазір біріктіру бірнеше аптада үлкен нәрсені біріктіруден әлдеқайда оңай. Ал үшінші мәселе, басқа инженерлер кодтың қазіргі нұсқасымен жұмыс істейтін болады. Олар мұнда кейбір тасымалдаулар қосылғанын көреді, содан кейін олар да пайдаланғысы келетін әдіс пайда болды. Барлығы сіздің кодыңызда не болып жатқанын көреді. Дәл осы үш нәрсе үшін тәжірибе жасалады.
Рахмет, мәселе жабылды!
(Олег Сорока) Мен қосуға болады ма? Барлығын дұрыс айттыңыз, мен бір сөз тіркесін қосқым келеді.
Солай
Үздіксіз интеграцияның көмегімен код мүмкіндік толығымен дайын болғанда емес, құрастыру үзілуін тоқтатқанда ортақ тармаққа біріктіріледі. Және сіз күніне қанша рет қаласаңыз, қауіпсіз түрде меңгеруге міндеттене аласыз. Екінші аспект, егер сіз қандай да бір себептермен айлық тапсырманы кем дегенде үш күн тапсырмаға бөле алмасаңыз, мен үш сағаттай үндемеймін, демек сізде үлкен мәселе бар. Сізде Үздіксіз интеграцияның жоқтығы - бұл проблемалардың ең азы. Бұл сізде сәулет және нөлдік инженерлік тәжірибелермен проблемалар бар екенін білдіреді. Өйткені бұл зерттеу болса да, кез келген жағдайда гипотеза немесе цикл түрінде тұжырымдалуы керек.
Біз табысты компанияларды артта қалған компаниялардан ажырататын 4 көрсеткіш туралы айттық. Осы 4 көрсеткішті көру үшін бізге әлі де өмір сүру керек. Егер сіздің орташа тапсырмаңызды орындауға бір ай қажет болса, мен алдымен осы көрсеткішке назар аударар едім. Алдымен мен оны 3 күнге дейін төмендететін едім. Осыдан кейін мен Continous туралы ойлана бастадым.
Мен сізді дұрыс түсіндім бе, сіз қандай да бір тапсырманы орындауға бір ай қажет болса, инженерлік тәжірибеге ақша салудың қажеті жоқ деп ойлайсыз ба?
Сізде үздіксіз интеграция бар. Сондай тақырып бар, 10 минут ішінде не түзетуге болады, не оны кері айналдыруға болады. Сіз оны шығардыңыз деп елестетіңіз. Сонымен қатар, сізде үздіксіз орналастыру бар, сіз оны өндіру үшін шығардыңыз және содан кейін бірдеңе дұрыс емес екенін байқадыңыз. Сіз оны кері айналдыруыңыз керек, бірақ дерекқорыңызды әлдеқашан тасымалдадыңыз. Сізде келесі нұсқаның дерекқор схемасы бар, сонымен қатар сізде қандай да бір сақтық көшірме бар және деректер де сонда жазылған.
Ал сізде қандай балама бар? Кодты кері қайтарсаңыз, ол енді осы жаңартылған дерекқормен жұмыс істей алмайды.
База тек алға жылжиды, иә.
Инженерлік тәжірибесі нашар адамдар ... туралы қалың кітапты оқымаған шығар. Сақтық көшірмені не істеу керек? Сақтық көшірмеден қалпына келтірсеңіз, бұл сол уақытта жинақталған деректерді жоғалтуды білдіреді. Мысалы, біз сол жерде тіркелген пайдаланушылар базасының жаңа нұсқасымен үш сағат жұмыс жасадық. Сіз ескі сақтық көшірмеден бас тартасыз, себебі схема жаңа нұсқамен жұмыс істемейді, сондықтан сіз бұл пайдаланушыларды жоғалттыңыз. Ал олар қанағаттанбайды, ант береді.
Үздіксіз интеграция мен үздіксіз жеткізуді қолдайтын тәжірибелердің толық спектрін меңгеру үшін жазуды үйрену жеткіліксіз.... Біріншіден, олардың көп болуы мүмкін, бұл мүмкін емес. Сонымен қатар Scientific сияқты басқа да көптеген тәжірибелер бар. Мұндай тәжірибе бар, GitHub оны бір уақытта танымал етті. Бұл сізде бір уақытта ескі код пен жаңа код жұмыс істейтін кезде. Бұл аяқталмаған мүмкіндікті жасаған кезде, бірақ ол кейбір мәнді қайтара алады: функция ретінде немесе Rest API ретінде. Сіз жаңа кодты да, ескі кодты да орындайсыз және олардың арасындағы айырмашылықты салыстырасыз. Егер айырмашылық болса, сіз осы оқиғаны тіркейсіз. Осылайша сізде белгілі бір уақыт ішінде екеуінің арасында сәйкессіздік болмаса, ескі функцияның үстіне шығуға дайын жаңа мүмкіндік бар екенін білесіз.
Мұндай жүздеген тәжірибелер бар. Мен трансбазалық дамудан бастауды ұсынар едім. Ол Үздіксіз интеграцияда 100% емес, бірақ тәжірибелер бірдей, біреуі екіншісінсіз жақсы өмір сүре алмайды.
Тәжірибелерді көруге болатын мысал ретінде трансбазалық дамуды келтірдіңіз бе немесе адамдарға трансбазалық өңдеуді пайдалануды ұсынасыз ба?
Қараңыз, өйткені олар оны пайдалана алмайды. Оларды пайдалану үшін көп оқу керек. Ал адам: «Бір айға созылатын функциямен не істеу керек, бұл оның трансбазды дамыту туралы оқымағанын білдіреді» деп сұрағанда. Мен оны әлі ұсынбаймын. Мен үлкен тапсырмаларды архитектуралық түрде кішіректерге қалай дұрыс бөлуге болатыны туралы тақырыпқа ғана назар аударуды ұсынамын. Бұл ыдыраудың мәні.
Декомпозиция - сәулетшінің құралдарының бірі. Біз алдымен талдау жасаймыз, содан кейін декомпозиция, содан кейін синтез, содан кейін интеграция. Міне, біз үшін бәрі осылай болады. Біз әлі де ыдырау арқылы Үздіксіз интеграцияға жетуіміз керек. Бірінші кезеңде сұрақтар туындайды және біз қазірдің өзінде төртінші кезең туралы айтып отырмыз, яғни интеграцияны неғұрлым жиі жасасақ, соғұрлым жақсы. Мұны істеу әлі ерте, алдымен монолитті кесіп тастаған дұрыс.
Кейбір диаграммада бірнеше көрсеткілер мен шаршыларды салу керек. Енді мен жаңа қолданбаның архитектуралық схемасын көрсетемін және бір шаршыны көрсетемін деп айта алмайсыз, оның ішінде қосымшаның жасыл түймесі бар. Қалай болғанда да, квадраттар мен көрсеткілер көбірек болады. Мен көрген әр диаграммада біреуден көп болды. Ал ыдырау, тіпті графикалық бейнелеу деңгейінде де қазірдің өзінде жүріп жатыр. Сондықтан квадраттарды тәуелсіз жасауға болады. Олай болмаса, сәулетшіге үлкен сұрақтарым бар.
Чаттан сұрақ туындайды: «Егер шолу міндетті болса және ұзақ уақытты қажет етсе, мүмкін бір күн немесе одан да көп уақыт қажет пе?»
Сізде тәжірибеде қиындықтар бар. Қарау бір күнге немесе одан да көп уақытқа созылмауы керек. Бұл алдыңғы сұраққа ұқсас, сәл ғана жұмсақ. Егер шолу бір күнге созылса, бұл шолуда өте үлкен өзгерістер болуы мүмкін. Бұл оны кішірейту керек дегенді білдіреді. Олег ұсынған трансбазалық дамуда үздіксіз шолу деп аталатын оқиға бар. Оның идеясы - біз осындай шағын тарту сұрауын әдейі жасаймыз, өйткені біз үнемі және аздап біріктіруге тырысамыз. Осылайша тарту сұрауы бір абстракцияны немесе 10 жолды өзгертеді. Осы шолудың арқасында бізге бірнеше минут кетеді.
Егер шолуға бір күн немесе одан да көп уақыт кетсе, бірдеңе дұрыс емес. Біріншіден, сізде архитектураға қатысты кейбір мәселелер болуы мүмкін. Немесе бұл кодтың үлкен бөлігі, мысалы, 1 жол. Немесе сіздің архитектураңыздың күрделілігі сонша, оны адам түсіне алмайды. Бұл аздап бүйірлік мәселе, бірақ оны да шешу керек. Мүмкін шолудың қажеті жоқ шығар. Бұл туралы да ойлануымыз керек. Тексеру - сізді баяулататын нәрсе. Жалпы оның артықшылықтары бар, бірақ сіз мұны не үшін істеп жатқаныңызды түсінуіңіз керек. Бұл сізге ақпаратты жылдам жеткізудің жолы ма, бұл ішкі стандарттарды орнатудың тәсілі ме, әлде не? Бұл сізге не үшін керек? Өйткені шолуды не өте тез жасау керек, не мүлде бас тарту керек. Бұл трансбазалық даму сияқты - оқиға өте әдемі, бірақ тек жетілген жігіттерге арналған.
4 көрсеткішке қатысты, мен бұл не әкелетінін түсіну үшін оларды жоюды ұсынамын. Сандарға қараңыз, суретке қараңыз, бәрі қандай жаман.
(Дмитрий) Мен бұл туралы сізбен талқылауға дайынмын. Сандар мен көрсеткіштердің бәрі тамаша, тәжірибелер тамаша. Бірақ бұл бизнеске қажет пе, соны түсіну керек. Мұндай өзгерістер жылдамдығын қажет етпейтін кәсіпорындар бар. Мен әр 15 минут сайын өзгерістер енгізуге болмайтын компанияларды білемін. Және олар соншалықты нашар болғандықтан емес. Бұл өмірлік цикл. Ал бұтақтарды, ауыстырып қосу мүмкіндігін жасау үшін сізге терең білім қажет.
Бұл қиын. Ауыстыру мүмкіндігі туралы әңгімені толығырақ оқығыңыз келсе, мен оны өте ұсынамын . Мартин Фаулердің ауыстырып қосқыш мүмкіндіктері туралы тамаша мақаласы бар: олардың қандай түрлері бар, өмірлік циклдер және т.б. Ауыстыру мүмкіндігі күрделі.
Сіз: «Дженкинс қажет пе, жоқ па?» Деген сұраққа әлі жауап бермедіңіз.
Дженкинс кез келген жағдайда қажет емес. Шынымен де, құралдар: Дженкинс, Gitlab сізге ыңғайлылық әкеледі. Сіз жинақтың жиналғанын немесе жиналмағанын көресіз. Олар сізге көмектесе алады, бірақ олар сізге тәжірибе бермейді. Олар сізге тек шеңбер бере алады - Жарайды, OK емес. Ал содан кейін, егер сіз де тесттер жазсаңыз, өйткені егер тесттер болмаса, бұл мағынасыз. Сондықтан, бұл қажет, өйткені ол ыңғайлырақ, бірақ сіз онсыз өмір сүре аласыз, сіз көп нәрсені жоғалтпайсыз.
Яғни, егер сізде тәжірибе болса, бұл сізге қажет емес дегенді білдіре ме?
Барлығы дұрыс. Мен Jez Humble тестін ұсынамын. Онда мен соңғы нүктеге екіұшты көзқараспен қараймын. Бірақ жалпы алғанда, егер сізде үш нәрсе болса, сіз үнемі біріктіресіз, сіз шебердегі тапсырмалар бойынша сынақтарды жүргізесіз, шебердегі құрастыруды тез түзетесіз, содан кейін сізге басқа ештеңе қажет емес шығар.
Қатысушылардың сұрақтарын күтіп отырғанда, менің сұрағым бар. Біз жай ғана өнім коды туралы айттық. Сіз оны инфрақұрылымдық код үшін пайдаландыңыз ба? Бұл бірдей код па, оның принциптері мен өмірлік циклі бірдей ме, әлде әртүрлі өмірлік циклдар мен принциптер бар ма? Әдетте, бәрі Үздіксіз интеграция және даму туралы айтқанда, барлығы инфрақұрылымдық код бар екенін ұмытады. Ал соңғы кездері ол көбейіп кетті. Және осы ережелердің барлығын сонда әкелу керек пе?
Тіпті солай болуы керек емес, бұл тамаша болар еді, өйткені ол өмірді дәл осылай жеңілдетеді. Біз bash сценарийлерімен емес, кодпен жұмыс істей бастаймыз, бірақ бізде қалыпты код бар.
Тоқта, тоқта, bash сценарийі де код болып табылады. Менің ескі махаббатыма тиіспе.
Жарайды, мен сіздің естеліктеріңізді таптамаймын. Менің bash-ті жеке ұнатпайтыным бар. Ол үнемі жағымсыз және қорқынышты бұзылады. Және ол жиі күтпеген жерден бұзылады, сондықтан маған ұнамайды. Бірақ жақсы, сізде bash коды бар делік. Мүмкін мен шынымен түсінбеймін және ол жерде қалыпты тестілеу құрылымдары бар. Мен жай ғана білмеймін. Және біз де осындай жеңілдіктерге ие боламыз.
Инфрақұрылыммен код ретінде жұмыс істегенде, біз әзірлеушілер сияқты бірдей мәселелерге тап боламыз. Бірнеше ай бұрын мен әріптесім маған bash тілінде 1 жолды тарту сұрауын жіберген жағдайға тап болдым. Ал сіз шолуда 000 сағат отырасыз. Дәл осындай проблемалар туындайды. Бұл әлі де код. Және бұл әлі де ынтымақтастық. Біз тарту сұрауымен тоқтап қаламыз және біз, мысалы, бір bash ішіндегі бірдей біріктіру қайшылықтарын шешіп жатқанымызға тоқталамыз.
Мен қазір ең әдемі инфрабағдарламалауда осының бәрін белсенді түрде қарап жатырмын. Мен қазір Пулумиді инфрақұрылымға әкелдім. Бұл таза түрде бағдарламалау. Бұл жерде бұл одан да жақсы, өйткені менде бағдарламалау тілінің барлық мүмкіндіктері бар, яғни мен бірдей ifs көмегімен әдемі ауыстырып қосқыш жасадым және бәрі жақсы. Яғни, менің өзгерісім шеберде бар. Оны бәрі қазірдің өзінде көре алады. Бұл туралы басқа инженерлер біледі. Ол жерде әлдеқашан әсер етті. Дегенмен, ол барлық инфрақұрылымдар үшін қосылмаған. Ол, мысалы, менің сынақ орындықтарым үшін қосылды. Сондықтан, сіздің сұрағыңызға қайтадан жауап беру қажет. Бұл кодпен жұмыс істейтін инженерлер ретінде біздің өмірімізді жеңілдетеді.
Басқа біреудің сұрақтары болса?
Менде сұрақ бар. Мен Олегпен талқылауды жалғастырғым келеді. Жалпы, дұрыс айтасыз, егер бір тапсырманы орындауға бір ай қажет болса, онда сізде архитектура мәселесі бар, сізде талдау, ыдырау, жоспарлау және т.б. проблемалар бар. Бірақ менде бір сезім бар, егер сіз бастасаңыз. Үздіксіз интеграцияға сәйкес өмір сүруге тырыссаңыз, сіз жоспарлау арқылы ауырсынуды түзете бастайсыз, өйткені сіз одан ешқайда кетпейсіз.
(Олег) Иә, солай. Бұл тәжірибені мәдениетті өзгертетін кез келген басқа маңызды тәжірибемен салыстыруға болады. Ең қиын нәрсе - әдеттер, әсіресе жаман әдеттер. Ал егер бұл тәжірибені жүзеге асыру үшін айналаңыздағы адамдардың әдеттерін түбегейлі өзгерту қажет болса: әзірлеушілер, басшылық, өндіріс менеджері, онда сізді тосын сыйлар күтеді.
Қандай тосынсыйлар болуы мүмкін? Сіз жиі интеграцияланатыныңызды шештіңіз делік. Сізде интеграцияға байланысты басқа да нәрселер бар, мысалы, артефактілер. Сіздің компанияңызда, мысалы, әрбір артефакті қандай да бір түрде артефакті сақтау жүйесінде есепке алынуы керек деген саясат бар. Және бұл біраз уақытты алады. Адам шығарылым менеджері ретінде бұл артефакттың өндірісте шығаруға дайын екеніне көз жеткізу үшін сынаған құсбелгісін қоюы керек. Егер 5-10-15 минут кетсе, бірақ сіз макетті аптасына бір рет жасасаңыз, аптасына бір рет жарты сағат жұмсау - бұл аз салық.
Үздіксіз интеграцияны күніне 10 рет жасасаңыз, 10 рет 30 минутқа көбейту керек. Және бұл осы шығарылым менеджерінің жұмыс уақытынан асып түседі. Ол жай ғана мұны істеуден шаршайды. Кейбір тәжірибелер үшін тұрақты шығындар бар. Болды.
Енді мұндай қоқыспен айналыспау үшін, яғни бір нәрсеге сәйкес келетін дәрежені қолмен тағайындамау үшін бұл ережеден бас тарту керек. Сіз дайындық сынақтарының кейбір автоматтандырылған жиынтығына толығымен сенесіз.
Ал егер сізге біреуден дәлел керек болса, бастық оған қол қояды және сіз Вася рұқсат бердім деп айтпай өндіріске кіріспесеңіз, т.б. - осының бәрі практиктің жолына түседі. Өйткені салыққа байланысты қандай да бір әрекеттер болса, онда барлығы 100 есе өседі. Сондықтан ауысымды көбіне барлығы қуанышпен қарсы алмайды. Өйткені адамдардың әдеттерін өзгерту қиын.
Адам әдеттегі жұмысын істегенде, ол оны ойланбастан жасайды. Оның когнитивтік жүктемесі нөлге тең. Ол жай ғана онымен ойнайды, оның басында бақылау парағы бар, ол мұны мың рет жасады. Сіз келіп: «Дүйсенбіден бастап бұл тәжірибені тоқтатып, жаңасын енгізейік» деп айтқан кезде, ол үшін бұл күшті танымдық жүктемеге айналады. Және ол барлығына бірден келеді.
Сондықтан, ең қарапайым нәрсе, бұл сән-салтанат әркімнің қалтасы көтере алмаса да, мен әрқашан осылай істеймін, бұл келесідей. Егер жаңа жоба басталса, әдетте барлық тексерілмеген тәжірибелер дереу осы жобаға енеді. Жоба жас болса да, біз ештеңеге тәуекел етпейміз. Әзірге Prod жоқ, жойылатын ештеңе жоқ. Сондықтан оны жаттығу ретінде пайдалануға болады. Бұл тәсіл жұмыс істейді. Бірақ мұндай жобаларды жиі бастауға барлық компаниялардың мүмкіндігі бола бермейді. Бұл да біртүрлі болғанымен, қазір толық цифрлық трансформация жүріп жатқандықтан, бәсекелестерге ілесу үшін барлығы эксперименттерді бастауы керек.
Мұнда сіз алдымен не істеу керектігін түсінуіңіз керек деген қорытындыға келесіз. Дүние идеал емес, өнім де идеал емес.
Иә, бұл нәрселер бір-бірімен байланысты.
Кәсіпорындар да осы жолмен жүру керек екенін түсінбейді.
Ешқандай өзгерістер мүлдем мүмкін емес жағдай бар. Бұл командаға көбірек қысым жасайтын жағдай. Команда қазірдің өзінде әбден күйіп кетті. Оның эксперименттерге бос уақыты жоқ. Олар таңертеңнен кешке дейін функциялармен жұмыс істейді. Ал менеджменттің мүмкіндіктері азайып келеді. Барған сайын көбірек талап етіледі. Мұндай жағдайда ешқандай өзгерістер мүмкін емес. Командаға тек ертең біз кешегідей жасаймыз деп айтуға болады, бізге сәл көбірек мүмкіндіктер жасау керек. Бұл мағынада ешқандай тәжірибеге көшу мүмкін емес. Бұл балта қайрауға уақыт болмаған классикалық жағдай, ағаштарды кесу керек, сондықтан олар оны түтіккен балтамен кеседі. Мұнда қарапайым кеңестер жоқ.
(Дмитрий) Мен чаттағы түсініктемені оқимын: «Бірақ бізге әртүрлі деңгейдегі сынақтар көп қажет. Тестілеуге қанша уақыт бөлінеді? Бұл аздап қымбат және көп уақытты алады ».
(Олег) Бұл классикалық қате түсінік. Сізге сенімді болу үшін жеткілікті сынақтар болуы керек. Үздіксіз интеграция - бұл сынақтардың 100% бірінші орындалатын нәрсе емес, содан кейін ғана сіз бұл тәжірибені қолдана бастайсыз. Үздіксіз интеграция сіздің когнитивтік жүктемеңізді азайтады, себебі сіз өз көзіңізбен көрген өзгерістердің әрқайсысы бір нәрсені сындыратыны немесе сындырмайтыны соншалықты айқын, тіпті сынақсыз да түсінесіз. Өзгерістер аз болғандықтан, сіз мұны тез арада сынай аласыз. Сізде тек қолмен тестерлер болса да, олар үшін де оңайырақ. Сіз сыртқа шығып: «Міне, бірдеңе сынған ба?» - дедіңіз. Олар тексеріп: «Жоқ, ештеңе бұзылған жоқ», - деді. Өйткені тестілеуші қайдан іздеу керектігін біледі. Сізде кодтың бір бөлігімен байланыстырылған бір міндеттеме бар. Және бұл белгілі бір мінез-құлық арқылы пайдаланылады.
Мұнда сіз, әрине, безендірілген.
(Дмитрий) Мен бұл жерде келіспеймін. Тәжірибе бар - тестілеуге негізделген әзірлеу, ол сізді одан құтқарады.
(Олег) Мен бұл деңгейге әлі жеткен жоқпын. Бірінші иллюзия тесттердің 100% жазу керек немесе Үздіксіз интеграцияны мүлде жасаудың қажеті жоқ. Бұл өтірік. Бұл екі параллель тәжірибе. Және олар тікелей тәуелді емес. Сіздің сынақ қамтуыңыз оңтайлы болуы керек. Оңтайлы - бұл сіздің шеберіңіз міндеттемеден кейін қалған шебердің сапасы жұма күні мас күйінде кешке «Орналастыру» түймесін сенімді түрде басуға мүмкіндік беретініне сенімді екеніңізді білдіреді. Бұған қалай қол жеткізесіз? Қарау арқылы, қамту арқылы, жақсы бақылау арқылы.
Жақсы бақылау сынақтардан ерекшеленбейді. Егер сіз алдын ала өнімде сынақтарды бір рет орындасаңыз, олар сіздің барлық пайдаланушы сценарийлеріңізді бір рет тексереді және бәрі бірдей. Егер сіз оларды шексіз циклде іске қоссаңыз, онда бұл сіздің орнатылған бақылау жүйеңіз, ол барлығын шексіз сынайды - ол бұзылды ма, жоқ па. Бұл жағдайда жалғыз айырмашылық - бұл бір немесе екі рет жасалды ма. Өте жақсы сынақтар жинағы... шексіз жұмыс істейді, бұл бақылау. Ал дұрыс бақылау осындай болуы керек.
Сондықтан жұма күні кешке дайындалып, үйге қайтқанда бұл күйге қалай жетуге болатыны басқа мәселе. Бәлкім, сен жай ғана батыл ақымақ шығарсың.
Үздіксіз интеграцияға сәл оралайық. Біз сәл басқаша күрделі тәжірибеге қашып кеттік.
Ал екінші иллюзия - MVP, олар айтады, тез жасалуы керек, сондықтан ол жерде сынақтар мүлдем қажет емес. Олай емес. Мәселе мынада, сіз MVP-де қолданушы тарихын жазған кезде оны шарда дамыта аласыз, яғни сіз пайдаланушының қандай да бір оқиғасы бар екенін естіп, оны бірден кодтауға жүгірдіңіз немесе TDD көмегімен жұмыс істей аласыз. TDD мәліметтері бойынша, тәжірибе көрсеткендей, бұл көп уақытты қажет етпейді, яғни сынақтар жанама әсер болып табылады. TDD тәжірибесі тестілеу туралы емес. Тестке негізделген даму деп аталатын нәрсеге қарамастан, бұл мүлдем сынақтар туралы емес. Бұл да сәулеттік тәсіл. Бұл қажет емес нәрсені жазбай, қажет нәрсені дәл жазу тәсілі. Бұл қолданба архитектурасын жасау тұрғысынан ойлаудың келесі итерациясына назар аудару тәжірибесі.
Сондықтан бұл иллюзиялардан арылу оңай емес. MVP және сынақтар бір-біріне қайшы келмейді. Тіпті, керісінше, егер сіз TDD тәжірибесін пайдаланып MVP жасасаңыз, онда сіз мұны мүлдем жаттығусыз, бірақ допта жасағаннан гөрі жақсырақ және жылдамырақ жасайсыз.
Бұл өте айқын емес және күрделі идея. Енді мен көп сынақтар жазатынымды және сонымен бірге жылдамырақ нәрсені жасайтынымды естігенде, бұл мүлдем жеткіліксіз болып көрінеді.
(Дмитрий) Мұнда көптеген адамдар MVP деп атаған кезде, адамдар қалыпты нәрсе жазуға тым жалқау. Және бұл әлі де әртүрлі нәрселер. MVP-ті жұмыс істемейтін жаман нәрсеге айналдырудың қажеті жоқ.
Иә, иә, дұрыс айтасыз.
Содан кейін кенеттен өнімдегі MVP.
Мәңгі.
Тесттер жазып, көбірек жұмыс істеп жатқаныңызды естігенде, TDD өте ерекше естіледі. Бұл өте оғаш естіледі, бірақ шын мәнінде ол осылайша тезірек және әдемірек шығады. Тест жазған кезде сіз қандай код және қалай шақырылатыны, сондай-ақ одан қандай мінез-құлық күтетіні туралы көп ойлайсыз. Сіз жай ғана мен қандай да бір функция жаздым деп айтпайсыз және ол бірдеңе жасайды. Алғашында оның мынадай жағдайы бар, анау-мынау шақырады деп ойладың. Сіз мұны сынақтармен қамтысыз және осыдан интерфейстеріңіз кодтың ішінде қалай көрінетінін түсінесіз. Бұл сәулет өнеріне үлкен әсер етеді. Сіздің кодыңыз автоматты түрде модульді болады, өйткені сіз алдымен оны қалай сынайтыныңызды түсінуге тырысасыз, содан кейін ғана жазасыз.
TDD-мен маған не болды, мен әлі де Ruby бағдарламашысы болған кезімде Ruby тәлімгерін жалдадым. Және ол: «Бұны TDD бойынша жасайық» дейді. Мен ойладым: «Бәрекелді, енді қосымша бірдеңе жазуым керек». Біз екі апта ішінде TDD арқылы Python-да барлық жұмыс кодын жазамын деп келістік. Екі аптадан кейін мен қайтып оралғым келмейтінімді түсіндім. Екі апта бойы мұны барлық жерде қолдануға тырысқаннан кейін, сіз тіпті жай ғана ойлаудың қаншалықты оңай болғанын түсінесіз. Бірақ бұл анық емес, сондықтан мен барлығына TDD қиын, уақытты қажет ететін және қажет емес деп ойласаңыз, оны екі апта бойы ұстануға кеңес беремін. Маған екеуі жеткілікті болды.
(Дмитрий) Біз бұл идеяны инфрақұрылымдық жұмыс тұрғысынан кеңейте аламыз. Жаңа нәрсені бастамас бұрын біз мониторинг жасаймыз, содан кейін іске қосамыз. Бұл жағдайда бақылау біз үшін қалыпты сынаққа айналады. Ал мониторинг арқылы даму бар. Бірақ бәрі дерлік бұл ұзақ, мен жалқаумын, мен уақытша нобай жасадым дейді. Егер біз қалыпты бақылау жасасақ, біз CI жүйесінің күйін түсінеміз. Ал CI жүйесінде бақылау көп. Біз жүйенің жағдайын түсінеміз, оның ішінде не бар екенін түсінеміз. Ал әзірлеу кезінде біз жүйені қалаған күйге жететіндей етіп жасаймыз.
Бұл тәжірибелер бұрыннан белгілі. Біз бұл туралы 4 жыл бұрын талқыладық. Бірақ 4 жыл ішінде іс жүзінде ештеңе өзгерген жоқ.
Бірақ осы жазба бойынша мен ресми талқылауды аяқтауды ұсынамын.
Бейне (медиа элементі ретінде енгізілген, бірақ қандай да бір себептермен жұмыс істемейді):
Ақпарат көзі: www.habr.com