Бүгінгі таңда бағдарламалық өнімдердің көпшілігі командаларда жасалады. Ұжымның табысты дамуының шарттарын қарапайым диаграмма түрінде көрсетуге болады.

Кодты жазғаннан кейін оған көз жеткізу керек:

1. Жұмыс істейді.
2. Ол ештеңені бұзбайды, оның ішінде әріптестеріңіз жазған код.

Егер екі шарт орындалса, онда сіз сәттілік жолындасыз. Осы шарттарды оңай тексеріп, пайдалы жолдан ауытқымау үшін біз Үздіксіз интеграцияны ойлап таптық.

CI - кодты жалпы өнім кодына мүмкіндігінше жиі біріктіретін жұмыс процесі. Сіз тек біріктіріп қана қоймайсыз, сонымен қатар барлығы жұмыс істеп тұрғанын үнемі тексеріп отырасыз. Сізге көп және жиі тексеру қажет болғандықтан, автоматтандыру туралы ойлануға тұрарлық. Сіз барлығын қолмен тексере аласыз, бірақ бұл мүмкін емес, сондықтан да.

• Құрметті адамдар. Кез келген бағдарламашының бір сағат жұмысы кез келген сервердің бір сағат жұмысынан қымбат.
• Адамдар қателеседі. Сондықтан сынақтар қате тармақта орындалғанда немесе тестерлер үшін қате тапсырма құрастырылғанда жағдайлар туындауы мүмкін.
• Адамдар жалқау. Анда-санда бір тапсырманы аяқтаған кезде ой туындайды: «Тексеретін не бар? Мен екі жолды жаздым - бәрі жұмыс істейді! Менің ойымша, сіздердің кейбіреулеріңізде кейде осындай ойлар болады. Бірақ сіз әрқашан тексеруіңіз керек.

Avito мобильді әзірлеу тобында Үздіксіз интеграция қалай жүзеге асырылды және дамыды, олар күніне 0-ден 450 құрастыруға дейін қалай жүрді және құрастыру машиналары күніне 200 сағат жиналады, дейді Николай Нестеров (Нестеров) CI/CD Android қолданбасының барлық эволюциялық өзгерістеріне қатысушы.

Әңгіме Android пәрменінің мысалына негізделген, бірақ әдістердің көпшілігі iOS жүйесінде де қолданылады.

Кезінде Avito Android командасында бір адам жұмыс істеді. Анықтау бойынша, оған Үздіксіз интеграциядан ештеңе қажет болмады: біріктіретін ешкім болмады.

Бірақ қолданба өсті, көбірек жаңа тапсырмалар пайда болды және сәйкесінше команда өсті. Бір сәтте кодты біріктіру процесін ресми түрде орнатудың уақыты келді. Git ағынын пайдалану туралы шешім қабылданды.

Git ағынының тұжырымдамасы жақсы белгілі: жобаның бір жалпы әзірлеу тармағы бар және әрбір жаңа мүмкіндік үшін әзірлеушілер бөлек тармақты кесіп, оған міндеттенеді, итереді және өздерінің кодын әзірлеу тармағына біріктіргісі келгенде, сұрауды тарту. Біліммен бөлісу және тәсілдерді талқылау үшін біз кодты шолуды енгіздік, яғни әріптестер бір-бірінің кодын тексеріп, растауы керек.

Тексерулер

Кодты көзбен көру керемет, бірақ жеткіліксіз. Сондықтан автоматты тексерулер енгізілуде.

• Ең алдымен біз тексереміз ARK жинағы.
• Көп нәрсе Junit сынақтары.
• Біз кодты қамтуды қарастырамыз, өйткені біз сынақтарды жүргізіп жатырмыз.

Бұл тексерулерді қалай орындау керектігін түсіну үшін Avito бағдарламасындағы әзірлеу процесін қарастырайық.

Оны схемалық түрде келесідей көрсетуге болады:

• Әзірлеуші ​​өзінің ноутбугында код жазады. Интеграциялық тексерулерді дәл осы жерде орындауға болады - орындау ілгегі арқылы немесе тек фондық режимде тексерулерді орындау.
• Әзірлеуші ​​кодты басқаннан кейін ол тарту сұрауын ашады. Оның кодын әзірлеу бөліміне қосу үшін кодты тексеруден өтіп, растаулардың қажетті санын жинау қажет. Мұнда тексерулер мен құрастыруларды қосуға болады: барлық құрастырулар сәтті болғанша, тарту сұрауын біріктіру мүмкін емес.
• Тарту сұрауы біріктірілгеннен кейін және код әзірлеуге енгізілгеннен кейін ыңғайлы уақытты таңдауға болады: мысалы, түнде, барлық серверлер бос болғанда және қалағаныңызша көптеген тексерулерді орындаңыз.

Ешкім ноутбукта сканерлеуді ұнатпады. Әзірлеуші ​​функцияны аяқтаған кезде, ол оны жылдам басып, тарту сұрауын ашқысы келеді. Егер осы сәтте кейбір ұзақ тексерулер іске қосылса, бұл өте жағымды емес, сонымен қатар дамуды баяулатады: ноутбук бір нәрсені тексеріп жатқанда, онымен қалыпты жұмыс істеу мүмкін емес.

Бізге түнде тексерулерді жүргізу өте ұнады, өйткені уақыт пен серверлер көп, сіз айнала аласыз. Бірақ, өкінішке орай, мүмкіндік коды әзірлеуге кіріскенде, әзірлеушінің CI тапқан қателерді түзетуге мотивациясы әлдеқайда аз болады. Таңертеңгілік есепте табылған барлық қателерді қарап отырып, мен оларды бір күні кейін түзетемін деп ойлайтынмын, өйткені қазір Jira-да мен жай ғана орындағым келетін керемет жаңа тапсырма бар.

Егер тексерулер тарту сұрауын бұғаттаса, онда мотивация жеткілікті, өйткені конструкциялар жасыл түске айналғанша, код әзірлеуге енбейді, яғни тапсырма орындалмайды.

Нәтижесінде біз келесі стратегияны таңдадық: біз түнде мүмкін болатын тексерулердің максималды жиынтығын жүргіземіз және олардың ең маңыздыларын және ең бастысы, тарту сұрауы бойынша ең жылдамдарын іске қосамыз. Бірақ біз мұнымен тоқтап қалмаймыз — параллельді түрде біз түнгі режимнен сұрауды тексеруге көшіру үшін тексеру жылдамдығын оңтайландырамыз.

Ол кезде біздің барлық құрастыруларымыз өте жылдам аяқталды, сондықтан біз жай ғана ARK құрастыруын, Junit сынақтарын және кодты қамтуды есептеулерді тарту сұрауы үшін блокатор ретінде қостық. Біз оны қостық, бұл туралы ойладық және кодты қамтудан бас тарттық, өйткені біз оны қажет емес деп ойладық.

Негізгі CI-ны толығымен орнатуға екі күн қажет болды (бұдан әрі уақытты бағалау шамамен берілген, масштабтау үшін қажет).

Осыдан кейін біз әрі қарай ойлана бастадық - біз тіпті дұрыс тексеріп жатырмыз ба? Біз тарту сұраулары бойынша құрастыруларды дұрыс орындаймыз ба?

Біз құрылысты тарту сұрауы ашылған филиалдың соңғы тапсырмасы бойынша бастадық. Бірақ бұл міндеттеменің сынақтары әзірлеуші ​​жазған код жұмыс істейтінін ғана көрсете алады. Бірақ олар оның ештеңені бұзбағанын дәлелдемейді. Шын мәнінде, мүмкіндік біріктірілгеннен кейін әзірлеу тармағының күйін тексеру керек.

Ол үшін біз қарапайым bash сценарийін жаздық premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

Мұнда әзірлеудегі барлық соңғы өзгерістер жай ғана көтеріліп, ағымдағы филиалға біріктіріледі. Біз premerge.sh сценарийін барлық құрастырылымдардың бірінші қадамы ретінде қостық және дәл біз не қалайтынымызды тексере бастадық, яғни интеграция.

Мәселені локализациялау, шешімін табу және осы сценарийді жазу үшін үш күн қажет болды.

Қолданба әзірленді, көбірек тапсырмалар пайда болды, команда өсті және premerge.sh кейде бізді ренжіте бастады. Әзірлеуде құрылымды бұзған қарама-қайшы өзгерістер болды.

Мұның қалай болатынының мысалы:

Екі әзірлеуші ​​бір уақытта A және B мүмкіндіктерімен жұмыс істей бастайды. A мүмкіндігінің әзірлеушісі жобада пайдаланылмаған мүмкіндікті табады. answer() және жақсы бала барлаушы сияқты оны жояды. Сонымен қатар, B мүмкіндігінің әзірлеушісі өз филиалында осы функцияға жаңа шақыруды қосады.

Әзірлеушілер жұмысын аяқтап, бір уақытта тарту сұрауын ашады. Құрылымдар іске қосылды, premerge.sh соңғы әзірлеу күйіне қатысты тарту сұрауларының екеуін де тексереді - барлық тексерулер жасыл. Осыдан кейін A мүмкіндігінің тарту сұрауы біріктіріледі, B мүмкіндігінің тарту сұрауы біріктіріледі... Бум! Әзірлеу үзілістері, себебі әзірлеу кодында жоқ функцияға шақыру бар.

Ол дамымайтын кезде, ол жергілікті апат. Бүкіл команда ештеңе жинап, оны тестілеуге жібере алмайды.

Мен көбінесе инфрақұрылымдық тапсырмалармен жұмыс істедім: аналитика, желі, дерекқорлар. Яғни, мен басқа әзірлеушілер қолданатын функциялар мен сыныптарды жаздым. Осыған байланысты мен өзімді жиі осындай жағдайларға тап болдым. Тіпті бұл суретті біраз уақыт ілулі тұрдым.

Бұл бізге сәйкес келмегендіктен, біз мұның алдын алудың нұсқаларын зерттей бастадық.

Дамуды қалай бұзбауға болады

Бірінші нұсқа: әзірлеуді жаңарту кезінде барлық тарту сұрауларын қайта жасаңыз. Егер біздің мысалда A мүмкіндігі бар тарту сұрауы әзірлеуге бірінші болып қосылса, B мүмкіндігінің тарту сұрауы қайта құрылады және сәйкесінше компиляция қатесіне байланысты тексерулер сәтсіз болады.

Бұған қанша уақыт кететінін түсіну үшін екі PR бар мысалды қарастырыңыз. Біз екі PR ашамыз: екі құрастыру, екі тексеру. Бірінші PR әзірлеуге біріктірілгеннен кейін, екіншісін қайта құру қажет. Барлығы екі PR үш тексеруді қажет етеді: 2 + 1 = 3.

Негізінде бәрі жақсы. Бірақ біз статистиканы қарадық, ал біздің командадағы типтік жағдай 10 ашық PR болды, содан кейін тексерулер саны прогрессияның қосындысы болып табылады: 10 + 9 +... + 1 = 55. Яғни, 10-ды қабылдау PR, сізге 55 рет қайта құру керек. Және бұл тамаша жағдайда, барлық тексерулер бірінші рет өткенде, осы ондағандар өңделіп жатқанда, ешкім қосымша тарту сұрауын ашпайды.

Өзіңізді «біріктіру» түймесін бірінші басатын әзірлеуші ​​ретінде елестетіңіз, өйткені көршіңіз мұны жасаса, онда сіз барлық құрастырулар қайтадан өткенше күтуіңіз керек... Жоқ, бұл жұмыс істемейді. , ол дамуды айтарлықтай бәсеңдетеді.

Екінші ықтимал жол: кодты қарап шыққаннан кейін тарту сұрауларын жинаңыз. Яғни, сіз тарту сұрауын ашасыз, әріптестерден рұқсаттардың қажетті санын жинайсыз, қажет нәрсені түзетесіз, содан кейін құрастыруларды іске қосасыз. Егер олар сәтті болса, тарту сұрауы әзірлеуге біріктіріледі. Бұл жағдайда қосымша қайта қосулар болмайды, бірақ кері байланыс айтарлықтай баяулайды. Әзірлеуші ​​ретінде мен тарту сұрауын ашқанда, оның жұмыс істейтінін бірден көргім келеді. Мысалы, егер сынақ сәтсіз болса, оны тез түзету керек. Кешіктірілген құрылыс жағдайында кері байланыс баяулайды, демек, бүкіл даму. Бұл да бізге жараспады.

Нәтижесінде үшінші нұсқа ғана қалды - велосипед. Біздің барлық кодымыз, барлық көздеріміз Bitbucket серверіндегі репозиторийде сақталады. Тиісінше, Bitbucket плагинін әзірлеуге тура келді.

Бұл плагин тарту сұрауын біріктіру механизмін қайта анықтайды. Бастауы стандартты: PR ашылады, барлық жинақтар іске қосылды, кодты қарау аяқталды. Бірақ кодты тексеру аяқталғаннан кейін және әзірлеуші ​​​​"біріктіру" түймесін басу туралы шешім қабылдағаннан кейін, плагин тексерулер орындалған даму күйін тексереді. Егер әзірлеу құрастырудан кейін жаңартылса, плагин мұндай тарту сұрауын негізгі тармаққа біріктіруге рұқсат бермейді. Ол салыстырмалы түрде жақында жасалған құрылыстарды қайта іске қосады.

Біздің мысалда қайшылықты өзгерістер бар, мұндай құрастырулар компиляция қатесіне байланысты сәтсіз болады. Тиісінше, B мүмкіндігінің әзірлеушісі кодты түзетіп, тексерулерді қайта бастауы керек, содан кейін плагин автоматты түрде тарту сұрауын қолданады.

Бұл плагинді іске қоспас бұрын біз бір тарту сұрауына орташа есеппен 2,7 шолу жүгірісін алдық. Плагинмен 3,6 іске қосылды. Бұл бізге ұнады.

Айта кетейік, бұл плагиннің кемшілігі бар: ол құрастыруды тек бір рет қайта бастайды. Яғни, қарама-қайшы өзгерістердің дамуы мүмкін шағын терезе бар. Бірақ мұның ықтималдығы төмен, және біз бұл бастамалар саны мен сәтсіздікке ұшырау ықтималдылығы арасында айырбас жасадық. Екі жылда бір-ақ рет атса керек, бекер емес шығар.

Bitbucket плагинінің бірінші нұсқасын жазуға екі апта уақыт кетті.

Жаңа чектер

Осы уақытта біздің команда өсуді жалғастырды. Жаңа чектер қосылды.

Біз ойладық: егер олардың алдын алуға болатын болса, неге қателесу керек? Міне, сондықтан олар іске асырды статикалық кодты талдау. Біз Android SDK құрамына кіретін линттен бастадық. Бірақ ол кезде ол Котлин кодымен қалай жұмыс істеу керектігін мүлде білмейтін және бізде Котлин тілінде жазылған қосымшаның 75% болды. Сондықтан линтке кіріктірілгендер қосылды Android Studio тексереді.

Мұны істеу үшін бізге көптеген бұрмалау әрекеттерін жасау керек болды: Android Studio-ны алыңыз, оны Docker-ге жинаңыз және виртуалды монитормен CI-де іске қосыңыз, сонда ол нақты ноутбукта жұмыс істейді деп ойлайды. Бірақ ол жұмыс істеді.

Біз де осы уақытта көп жаза бастадық аспаптық сынақтар және іске асырылды скриншотты сынау. Бұл жеке шағын көрініс үшін анықтамалық скриншот жасалған кезде және сынақ көріністен скриншот алудан және оны стандартты пиксель бойынша пиксельмен салыстырудан тұрады. Егер сәйкессіздік болса, бұл орналасудың бір жерде дұрыс емес екенін немесе стильдерде бірдеңе дұрыс емес екенін білдіреді.

Бірақ аспаптық сынақтар мен скриншот сынақтары құрылғыларда орындалуы керек: эмуляторларда немесе нақты құрылғыларда. Сынақтардың көп екенін және олардың жиі жүргізілетінін ескерсек, тұтас бір ферма қажет. Жеке фермаңызды бастау тым көп еңбекті қажет етеді, сондықтан біз дайын нұсқаны таптық - Firebase Test Lab.

Firebase сынақ зертханасы

Ол таңдалды, себебі Firebase Google өнімі болып табылады, яғни ол сенімді және ешқашан өлуі екіталай болуы керек. Бағалар қолайлы: нақты құрылғының сағатына 5 доллар, эмулятордың сағатына 1 доллар.

Firebase сынақ зертханасын CI жүйесіне енгізуге шамамен үш апта қажет болды.

Бірақ команда өсуді жалғастырды, ал Firebase, өкінішке орай, бізді ренжіте бастады. Ол кезде оның ешқандай SLA құжаты болған жоқ. Кейде Firebase бізді сынақтар үшін қажетті құрылғылар саны бос болғанша күтуге мәжбүр етті және біз қалағандай оларды бірден орындауды бастамады. Кезекте тұру жарты сағатқа дейін созылды, бұл өте ұзақ уақыт. Әрбір PR-да аспаптық сынақтар жүргізілді, кідіріс шынымен дамуды баяулатады, содан кейін ай сайынғы есепшот дөңгелек сомамен келді. Жалпы, команда жеткілікті өскендіктен, Firebase-тен бас тартып, үйде жұмыс істеу туралы шешім қабылданды.

Docker + Python + bash

Біз Docker-ді алдық, оған эмуляторларды толтырдық, Python-да қарапайым бағдарламаны жаздық, ол қажетті уақытта қажетті нұсқада эмуляторлардың қажетті санын іске қосады және қажет болғанда оларды тоқтатады. Және, әрине, бірнеше bash сценарийі - оларсыз біз қайда болар едік?

Жеке сынақ ортасын құруға бес апта қажет болды.

Нәтижесінде, әрбір тарту сұрауы үшін тексерулердің ауқымды біріктіруді бұғаттау тізімі болды:

• ARK құрастыру;
• Junit сынақтары;
• линт;
• Android Studio тексерулері;
• Аспаптық сынақтар;
• Скриншот сынақтары.

Бұл көптеген ықтимал бұзылулардың алдын алды. Техникалық тұрғыдан бәрі жұмыс істеді, бірақ әзірлеушілер нәтижелерді күту тым ұзақ болды деп шағымданды.

Қанша уақыт тым ұзақ? Біз Bitbucket және TeamCity деректерін талдау жүйесіне жүктеп, оны түсіндік орташа күту уақыты 45 минут. Яғни, әзірлеуші ​​тарту сұрауын ашқан кезде құрастыру нәтижелерін орта есеппен 45 минут күтеді. Менің ойымша, бұл өте көп және сіз бұлай жұмыс істей алмайсыз.

Әрине, біз барлық құрылыстарымызды тездетуді шештік.

Тездетейік

Ғимараттардың жиі кезекте тұратынын көргенде, біз бірінші орындаймыз көбірек аппараттық құрал сатып алды — экстенсивті даму – ең қарапайым. Құрылыстар кезекке тұруды тоқтатты, бірақ күту уақыты шамалы ғана қысқарды, өйткені кейбір тексерулердің өзі өте ұзақ уақытқа созылды.

Тым ұзақ уақыт алатын тексерулерді жою

Біздің Үздіксіз Интеграциямыз осындай қателер мен мәселелердің түрлерін анықтай алады.

• Бармайды. Қайшылықты өзгерістерге байланысты бірдеңе құрылмаса, CI компиляция қатесін ұстай алады. Жоғарыда айтқанымдай, ешкім ештеңе жинай алмайды, даму тоқтап, бәрі қобалжиды.
• Мінездегі қате. Мысалы, қолданба құрастырылған кезде, бірақ түймені басқан кезде бұзылады немесе түйме мүлде басылмаса. Бұл жаман, себебі мұндай қате пайдаланушыға жетуі мүмкін.
• Орналасудағы қате. Мысалы, түйме басылды, бірақ солға 10 пиксель жылжытты.
• Техникалық қарыздың өсуі.

Бұл тізімді қарап шыққаннан кейін біз тек алғашқы екі тармақтың маңызды екенін түсіндік. Біз бірінші кезекте осындай проблемаларды қолға алғымыз келеді. Орналасудағы қателер дизайн-қарау сатысында анықталады және содан кейін оңай түзетілуі мүмкін. Техникалық қарызды өңдеу бөлек процесс пен жоспарлауды талап етеді, сондықтан біз оны тарту сұрауында сынамауды шештік.

Осы классификацияға сүйене отырып, біз тексерулердің барлық тізімін сілкіп тастадық. сызылған линт және оның іске қосылуын бір түнге кейінге қалдырды: ол жобада қанша проблемалар бар екендігі туралы есеп беру үшін. Техникалық қарызбен бөлек жұмыс істеуге келістік, және Android Studio тексерулерінен толығымен бас тартылды. Тексерулерді жүргізуге арналған Docker жүйесіндегі Android Studio қызықты болып көрінеді, бірақ қолдау көрсетуде көптеген қиындықтар туғызады. Android Studio нұсқаларының кез келген жаңартуы түсініксіз қателермен күресуді білдіреді. Сондай-ақ скриншот сынақтарын қолдау қиын болды, өйткені кітапхана өте тұрақты емес және жалған позитивтер болды. Скриншот сынақтары тексеру тізімінен жойылды.

Нәтижесінде біз қалдық:

• ARK құрастыру;
• Junit сынақтары;
• Аспаптық сынақтар.

Gradle қашықтағы кэш

Қатты тексерулерсіз бәрі жақсы болды. Бірақ кемелдікке шек жоқ!

Біздің қосымшамыз 150-ге жуық модульдерге бөлінген. Gradle қашықтағы кэш әдетте бұл жағдайда жақсы жұмыс істейді, сондықтан біз оны қолданып көруді шештік.

Gradle қашықтағы кэш - жеке модульдердегі жеке тапсырмалар үшін құрастыру артефактілерін кэштей алатын қызмет. Gradle кодты нақты құрастырудың орнына қашықтағы кэшті қағып, біреудің бұл тапсырманы орындағанын сұрау үшін HTTP пайдаланады. Егер иә болса, ол жай ғана нәтижені жүктеп алады.

Gradle қашықтағы кэшін іске қосу оңай, себебі Gradle Docker кескінін береді. Біз мұны үш сағатта орындадық.

Сізге Docker бағдарламасын іске қосып, жобаға бір жолды жазу жеткілікті болды. Бірақ оны тез іске қосуға болатынына қарамастан, бәрі жақсы жұмыс істеуі үшін көп уақыт қажет.

Төменде кэшті жіберіп алу графигі берілген.

Бастапқыда кэшті жіберіп алу пайызы шамамен 65 болды. Үш аптадан кейін біз бұл мәнді 20% дейін арттыра алдық. Android қолданбасы жинайтын тапсырмалардың біртүрлі транзиттік тәуелділіктерге ие екендігі анықталды, соның салдарынан Gradle кэшті өткізіп алды.

Кэшті қосу арқылы біз құрастыруды айтарлықтай жылдамдаттық. Бірақ құрастырудан басқа, аспаптық сынақтар да бар және олар көп уақытты алады. Әрбір тарту сұрауы үшін барлық сынақтарды орындау қажет болмауы мүмкін. Мұны білу үшін әсер талдауын қолданамыз.

Әсерді талдау

Тарту сұрауы бойынша біз git diff жинаймыз және өзгертілген Gradle модульдерін табамыз.

Өзгертілген модульдерді және оларға тәуелді барлық модульдерді тексеретін аспаптық сынақтарды ғана орындау мағынасы бар. Көрші модульдер үшін сынақтарды жүргізудің қажеті жоқ: ондағы код өзгерген жоқ және ештеңе бұза алмайды.

Аспаптық сынақтар соншалықты қарапайым емес, өйткені олар жоғарғы деңгейдегі Қолданба модулінде орналасуы керек. Біз әрбір тесттің қай модульге жататынын түсіну үшін байт-кодты талдау арқылы эвристиканы қолдандық.

Қатысқан модульдерді ғана сынайтындай аспаптық сынақтардың жұмысын жаңарту шамамен сегіз аптаға созылды.

Тексеруді жеделдету шаралары сәтті нәтиже берді. 45 минуттан 15-ке дейін көтерілдік. Құрылысты ширек сағат күту қалыпты жағдай.

Бірақ қазір әзірлеушілер қандай құрылымдар іске қосылып жатқанын, журналды қайдан көруге болатынын, құрастырудың неге қызыл екенін, қандай сынақ сәтсіз болғанын және т.б. түсінбейтініне шағымдана бастады.

Кері байланыс проблемалары дамуды баяулатады, сондықтан біз әрбір PR туралы барынша нақты және егжей-тегжейлі ақпарат беруге және мүмкіндігінше құруға тырыстық. Біз Bitbucket-тегі PR-ға түсініктемелерден бастадық, қай құрастыру сәтсіз болғанын және неліктен екенін көрсетіп, Slack-те мақсатты хабарламалар жаздық. Соңында біз қазір жұмыс істеп тұрған барлық құрастырулардың тізімі және олардың күйі бар бет үшін PR бақылау тақтасын жасадық: кезекте тұрған, іске қосылған, бұзылған немесе аяқталған. Сіз құрастыруды басып, оның журналына кіре аласыз.

Алты апта егжей-тегжейлі кері байланысқа жұмсалды.

жоспарлары

Жаңа тарихқа көшейік. Кері байланыс мәселесін шешіп, біз жаңа деңгейге жеттік - біз өз эмулятор фермасын құруды шештік. Көптеген сынақтар мен эмуляторлар болған кезде оларды басқару қиын. Нәтижесінде біздің барлық эмуляторлар икемді ресурстарды басқарумен k8s кластеріне көшті.

Сонымен қатар, басқа да жоспарлар бар.

• Линтті қайтару (және басқа статикалық талдау). Біз қазірдің өзінде бұл бағытта жұмыс істеп жатырмыз.
• Барлығын PR блокаторында іске қосыңыз ақырғы сынақтар барлық SDK нұсқаларында.

Сонымен, біз Авитодағы Үздіксіз интеграцияның даму тарихын қадағаладық. Енді мен тәжірибелі көзқараспен біраз кеңес бергім келеді.

Кеңестер

Егер мен бір ғана кеңес бере алатын болсам, бұл:

Қабық сценарийлерімен абай болыңыз!

Bash - өте икемді және қуатты құрал, ол сценарийлерді жазуға өте ыңғайлы және жылдам. Бірақ сіз онымен тұзаққа түсе аласыз, өкінішке орай, біз оған түстік.

Барлығы біздің құрастыру машиналарында жұмыс істейтін қарапайым сценарийлерден басталды:

#!/usr/bin/env bash
./gradlew assembleDebug

Бірақ, өзіңіз білетіндей, уақыт өте келе бәрі дамып, күрделене түседі - бір сценарийді екіншісінен іске қосайық, кейбір параметрлерді сол жерге жіберейік - соңында бізге bash ұяшықтарының қандай деңгейде реттелгенін анықтайтын функция жазуға тура келді. қажетті тырнақшаларды енгізу, барлығын бастау үшін.

Мұндай сценарийлерді әзірлеуге кететін еңбек шығындарын елестете аласыз. Сізге бұл тұзаққа түспеуге кеңес беремін.

Ауыстыруға болады ма?

• Кез келген сценарий тілі. -ге жазыңыз Python немесе Kotlin сценарийі ыңғайлырақ, себебі бұл сценарийлер емес, бағдарламалау.
• Немесе пішіндегі барлық құрастыру логикасын сипаттаңыз Теңшелетін дәреже тапсырмалары сіздің жобаңыз үшін.

Біз екінші опцияны таңдауды шештік, енді біз барлық bash сценарийлерін жүйелі түрде жоямыз және көптеген реттелетін gradle тапсырмаларын жазамыз.

№2 кеңес: Инфрақұрылымды кодта сақтаңыз.

Үздіксіз интеграция параметрі Jenkins немесе TeamCity және т.б. UI интерфейсінде емес, мәтіндік файлдар түрінде тікелей жоба репозиторийінде сақталған кезде ыңғайлы. Бұл нұсқалық мүмкіндік береді. Басқа филиалда кодты қайтару немесе құру қиын болмайды.

Сценарийлерді жобада сақтауға болады. Қоршаған ортамен не істеу керек?

№3 кеңес: Докер қоршаған ортаға көмектесе алады.

Бұл Android әзірлеушілеріне міндетті түрде көмектеседі; Өкінішке орай, iOS-та әлі жоқ.

Бұл jdk және android-sdk бар қарапайым докер файлының мысалы:

FROM openjdk:8

ENV SDK_URL="https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip" 
    ANDROID_HOME="/usr/local/android-sdk" 
    ANDROID_VERSION=26 
    ANDROID_BUILD_TOOLS_VERSION=26.0.2

# Download Android SDK
RUN mkdir "$ANDROID_HOME" .android 
    && cd "$ANDROID_HOME" 
    && curl -o sdk.zip $SDK_URL 
    && unzip sdk.zip 
    && rm sdk.zip 
    && yes | $ANDROID_HOME/tools/bin/sdkmanager --licenses

# Install Android Build Tool and Libraries
RUN $ANDROID_HOME/tools/bin/sdkmanager --update
RUN $ANDROID_HOME/tools/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS_VERSION}" 
    "platforms;android-${ANDROID_VERSION}" 
    "platform-tools"

RUN mkdir /application
WORKDIR /application

Осы Docker файлын жазғаннан кейін (мен сізге құпияны айтамын, оны жазудың қажеті жоқ, оны GitHub-тан дайын түрде тартыңыз) және суретті жинап, сіз қосымшаны құра алатын виртуалды машинаны аласыз. және Junit сынақтарын іске қосыңыз.

Мұның мәнді болуының екі негізгі себебі - масштабтау және қайталану. Доккерді пайдалану арқылы сіз алдыңғы ортамен бірдей ортаға ие болатын ондаған құрастыру агенттерін жылдам көтере аласыз. Бұл CI инженерлерінің өмірін айтарлықтай жеңілдетеді. Android-sdk файлын докерге итеру өте оңай, бірақ эмуляторлармен бұл біршама қиынырақ: сізге біраз жұмыс істеу керек (немесе дайынды GitHub-тан қайтадан жүктеп алу).

№4 кеңес: тексеру тек тексеру үшін емес, адамдар үшін жасалатынын ұмытпаңыз.

Жылдам және ең бастысы, нақты кері байланыс әзірлеушілер үшін өте маңызды: не бұзылды, қандай сынақ сәтсіз аяқталды, құрастыру журналын қайдан көруге болады.

№5 кеңес: Үздіксіз интеграцияны әзірлеу кезінде прагматикалық болыңыз.

Қателердің қандай түрлерін алдын алғыңыз келетінін, қанша ресурстарды, уақытты және компьютер уақытын жұмсауға дайын екеніңізді анық түсініңіз. Тым ұзаққа созылатын тексерулер, мысалы, бір түнге кейінге қалдырылуы мүмкін. Ал олардан өте маңызды емес қателерді ұстанатындардан толығымен бас тарту керек.

Кеңес №6: Дайын құралдарды пайдаланыңыз.

Қазір бұлтты CI қамтамасыз ететін көптеген компаниялар бар.

Бұл шағын командалар үшін жақсы шешім. Сізге ештеңені қолдаудың қажеті жоқ, аз ғана ақша төлеңіз, қолданбаңызды жасаңыз және тіпті аспаптық сынақтарды орындаңыз.

№7 кеңес: Үлкен командада ішкі шешімдер тиімдірек.

Бірақ ерте ме, кеш пе, команда өскен сайын, ішкі шешімдер тиімдірек болады. Бұл шешімдерде бір мәселе бар. Экономикада табыстың азаю заңы бар: кез келген жобада әрбір кейінгі жақсарту барған сайын қиынырақ және көбірек инвестицияны қажет етеді.

Экономика біздің бүкіл өмірімізді, соның ішінде Үздіксіз интеграцияны сипаттайды. Мен Үздіксіз интеграцияның дамуының әрбір кезеңі үшін еңбек шығындарының кестесін құрастырдым.

Кез келген жақсарту барған сайын қиындай түсетіні анық. Бұл графикке қарап, сіз үздіксіз интеграцияны команда мөлшерінің өсуіне сәйкес дамыту керектігін түсінуге болады. Екі адамнан тұратын команда үшін ішкі эмулятор фермасын дамытуға 50 күн жұмсау - орташа идея. Бірақ сонымен бірге үлкен команда үшін Үздіксіз интеграцияны мүлдем жасамау да жаман идея, өйткені интеграция проблемалары, байланысты түзету және т.б. ол одан да көп уақытты алады.

Біз автоматтандыру қажет, өйткені адамдар қымбат, қателеседі және жалқау деген ойдан бастадық. Бірақ адамдар автоматтандырады. Сондықтан барлық бірдей мәселелер автоматтандыруға қатысты.

• Автоматтандыру қымбат. Еңбек тәртібін есте сақтаңыз.
• Автоматтандыруға келгенде адамдар қателеседі.
• Кейде автоматтандыру өте жалқау, өйткені бәрі осылай жұмыс істейді. Неліктен басқа нәрсені жақсарту керек, неге бұл үздіксіз интеграция?

Бірақ менде статистика бар: қателер жиналыстардың 20% -ында кездеседі. Бұл біздің әзірлеушілеріміз кодты нашар жазғандықтан емес. Себебі әзірлеушілер қандай да бір қателік жіберсе, ол әзірлеуге түспейді, оны автоматтандырылған тексерулер ұстайды деп сенімді. Тиісінше, әзірлеушілер бір нәрсені жергілікті түрде іске қосып, сынаудан гөрі код пен қызықты нәрселерді жазуға көбірек уақыт жұмсай алады.

Үздіксіз интеграцияға машықтандыру. Бірақ қалыпты жағдайда.

Айтпақшы, Николай Нестеров тамаша баяндамалар жасап қана қоймайды, сонымен қатар бағдарлама комитетінің мүшесі. AppsConf және басқаларға сіз үшін мағыналы баяндамалар дайындауға көмектеседі. Келесі конференция бағдарламасының толықтығы мен пайдалылығын келесі тақырыптар бойынша бағалауға болады кестесі. Толық ақпарат алу үшін 22-23 сәуірде Infospace сайтына келіңіз.

Ақпарат көзі: www.habr.com