Бүгүнкү күндө көпчүлүк программалык продуктылар командаларда иштелип чыккан. Команданы ийгиликтүү өнүктүрүү үчүн шарттар жөнөкөй диаграмма түрүндө көрсөтүлүшү мүмкүн.

Кодуңузду жазгандан кийин, аны текшеришиңиз керек:

1. Works.
2. Ал эч нерсени, анын ичинде кесиптештериңиз жазган кодду бузбайт.

Эгер эки шарт тең аткарылса, анда сиз ийгиликтин жолундасыз. Бул шарттарды оңой текшерүү жана пайдалуу жолдон тайбоо үчүн биз Үзгүлтүксүз интеграцияны ойлоп таптык.

CI - бул сиздин кодуңузду жалпы продукт кодуна мүмкүн болушунча тез-тез киргизген иш процесси. Жана сиз жөн гана интеграцияланбастан, бардыгы иштеп жатканын дайыма текшерип турасыз. Сиз көп жана тез-тез текшерүү керек болгондуктан, автоматташтыруу жөнүндө ойлонуу керек. Баарын кол менен текшере аласыз, бирок андай кылбашыңыз керек, бул жерде эмне үчүн.

• Урматтуу элим. Ар бир программисттин бир сааттык иши ар кандай сервердин бир сааттык ишинен кымбатыраак.
• Адамдар ката кетиришет. Ошондуктан, сыноолор туура эмес тармакта иштетилгенде же тестирлөөчүлөр үчүн туура эмес тапшырма түзүлгөндө пайда болушу мүмкүн.
• Адамдар жалкоо. Маал-маалы менен бир ишти бүтүргөндө “Текшере турган эмне бар? Мен эки сап жаздым - баары иштейт! Менимче, араңарда да кээде ушундай ойлор болот. Бирок сиз дайыма текшеришиңиз керек.

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

Окуя Android буйругунун мисалына негизделген, бирок ыкмалардын көбү iOS үчүн да колдонулат.

Бир жолу Avito Android командасында бир адам иштеген. Аныктама боюнча, ал Үзгүлтүксүз интеграциядан эч нерсеге муктаж эмес болчу: интеграциялана турган эч ким жок болчу.

Бирок колдонмо өсүп, барган сайын жаңы тапшырмалар пайда болуп, команда ошого жараша өстү. Кайсы бир учурда, кодду интеграциялоо процессин расмий түрдө орнотууга убакыт келди. Git агымын колдонуу чечими кабыл алынды.

Git агымынын концепциясы белгилүү: долбоордун бир жалпы иштеп чыгуу бутагы бар жана ар бир жаңы функция үчүн иштеп чыгуучулар өзүнчө бутагын кесип, ага милдеттенип, түртүп, кодун иштеп чыгуу тармагына бириктирүүнү каалашканда, тартуу жөнүндө арыз. Билимди бөлүшүү жана ыкмаларды талкуулоо үчүн биз кодду карап чыгууну киргиздик, башкача айтканда, кесиптештер бири-биринин кодун текшерип, ырасташы керек.

Текшерүүлөр

Кодду көзүңүз менен көрүү сонун, бирок жетиштүү эмес. Ошондуктан автоматтык текшерүүлөр киргизилүүдө.

• Биринчиден, биз текшеребиз ARK жыйыны.
• көп Junit тесттери.
• Биз коддун камтылышын карап чыгабыз, анткени биз тесттерди өткөрүп жатабыз.

Бул текшерүүлөрдү кантип жүргүзүү керек экенин түшүнүү үчүн, келгиле, Avitoдогу иштеп чыгуу процессин карап көрөлү.

Бул схемалык түрдө төмөнкүчө чагылдырууга болот:

• Иштеп чыгуучу өзүнүн ноутбукуна код жазат. Сиз интеграциялык текшерүүлөрдү ушул жерден жүргүзсөңүз болот - же Commit илгич менен, же жөн эле фондо текшерүүлөрдү жүргүзсөңүз болот.
• Иштеп чыгуучу кодду түрткөндөн кийин, ал тартуу өтүнүчүн ачат. Анын кодун иштеп чыгуу тармагына киргизүү үчүн кодду карап чыгуу жана керектүү сандагы ырастоолорду чогултуу керек. Сиз текшерүүлөрдү жана курууларды бул жерден иштетсеңиз болот: бардык түзүүлөр ийгиликтүү болмоюнча, тартуу өтүнүчүн бириктирүү мүмкүн эмес.
• Тартуу өтүнүчү бириктирилгенден жана код иштеп чыгууга киргизилгенден кийин, сиз ыңгайлуу убакытты тандай аласыз: мисалы, түн ичинде, бардык серверлер бош болгондо жана каалагандай текшерүүлөрдү жүргүзүңүз.

Эч ким ноутбукта сканерлөө иштерин жактырган жок. Иштеп чыгуучу функцияны аяктагандан кийин, ал аны тез түртүп, тартуу өтүнүчүн ачкысы келет. Эгерде ушул учурда кээ бир узак текшерүүлөр башталса, бул абдан жагымдуу эмес, ошондой эле өнүгүүнү басаңдатат: ноутбук бир нерсени текшерип жатканда, анда кадимкидей иштөө мүмкүн эмес.

Бизге түн ичинде текшерүүлөрдү жүргүзүү абдан жакты, анткени убакыт жана серверлер көп, сиз кыдыра аласыз. Бирок, тилекке каршы, өзгөчөлүк коду иштеп баштаганда, иштеп чыгуучунун CI тапкан каталарды оңдоого мотивациясы азыраак болот. Мен мезгил-мезгили менен эртең мененки отчетто табылган бардык каталарды карап отуруп, аларды качандыр бир күнү оңдойм деп ойлочумун, анткени азыр Жирада мен жөн гана жасай баштагым келген сонун жаңы тапшырма бар.

Эгерде текшерүүлөр тартуу өтүнүчүн бөгөттөсө, анда жетиштүү мотивация бар, анткени конструкциялар жашыл түскө айланмайынча, код иштеп чыгууга кирбейт, демек, тапшырма аткарылбайт.

Натыйжада, биз төмөнкү стратегияны тандап алдык: биз түн ичинде максималдуу мүмкүн болгон текшерүүлөрдү жүргүзөбүз жана алардын эң критиктерин жана эң негизгиси, тартуу өтүнүчү боюнча эң ылдамдарын ишке киргизебиз. Бирок биз муну менен эле токтоп калбайбыз - параллелдүү түрдө биз текшерүүлөрдүн ылдамдыгын оптималдаштырып, аларды түнкү режимден суроо-талаптарды текшерүү үчүн өткөрүп беребиз.

Ошол учурда биздин бардык курулуштарыбыз абдан тез бүттү, ошондуктан биз жөн гана ARK түзүмүн, Junit тесттерин жана коддун камтуу эсептөөлөрүн тартуу өтүнүчү үчүн блокатор катары киргиздик. Биз аны күйгүзүп, ойлонуп, коддун камтылышынан баш тарттык, анткени биз мунун кереги жок деп ойлогонбуз.

Негизги CIди толугу менен орнотууга эки күн талап кылынды (мындан ары убакыт болжолу болжолдуу, масштаб үчүн керек).

Ошондон кийин биз дагы ойлоно баштадык - биз туура текшерип жатабызбы? Тартуу сурамдары боюнча түзүмдөрдү туура иштетип жатабызбы?

Биз курууну тартуу өтүнүчү ачылган филиалдын акыркы тапшырмасы боюнча баштадык. Бирок бул милдеттенменин тесттери иштеп чыгуучу жазган код иштегенин гана көрсөтө алат. Бирок алар эч нерсе сындырбаганын далилдешпейт. Чындыгында, функция ага кошулгандан кийин иштеп чыгуу бутагынын абалын текшерүү керек.

Бул үчүн биз жөнөкөй bash сценарийин жаздык premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

Бул жерде иштеп чыгуунун бардык акыркы өзгөрүүлөрү жөн гана көтөрүлүп, учурдагы бутагына бириктирилет. Биз premerge.sh сценарийин бардык түзүмдөрдүн биринчи кадамы катары кошуп, биз каалаган нерсени текшере баштадык, башкача айтканда интеграция.

Көйгөйдү локалдаштыруу, чечүү жолун табуу жана бул сценарийди жазуу үчүн үч күн кетти.

Тиркеме иштелип чыкты, барган сайын көп тапшырмалар пайда болду, команда өсүп, premerge.sh кээде бизди капа кыла баштады. Иштеп чыгууда курулушту бузган карама-каршы өзгөрүүлөр болгон.

Мунун кандайча болоруна бир мисал:

Эки иштеп чыгуучу бир эле учурда А жана В функцияларынын үстүндө иштей баштайт. А өзгөчөлүгүн иштеп чыгуучу долбоордо колдонулбаган функцияны табат. answer() жана, жакшы бала скаут сыяктуу, аны жок кылат. Ошол эле учурда, B функциясын иштеп чыгуучу өзүнүн филиалында бул функцияга жаңы чалууларды кошот.

Иштеп чыгуучулар өз иштерин бүтүрүп, ошол эле учурда тартуу өтүнүчүн ачышат. Түзүүлөр ишке киргизилди, premerge.sh акыркы иштеп чыгуу абалына байланыштуу эки тартуу сурамдарын текшерет - бардык текшерүүлөр жашыл. Андан кийин, А өзгөчөлүгүнүн тартуу сурамы бириктирилет, В өзгөчөлүгүнүн тартуу сурамы бириктирилет... Бум! Иштеп чыгуу тыныгуулары, анткени иштеп чыгуу коду жок функцияга чакырууну камтыйт.

Ал өнүкпөй турганда, ал жергиликтүү кырсык. Бүт команда эч нерсе чогултуп, аны сыноого бере албайт.

Ошентип, мен көбүнчө инфраструктуралык тапшырмалардын үстүндө иштечүмүн: аналитика, тармак, маалымат базалары. Башкача айтканда, башка иштеп чыгуучулар колдонгон функцияларды жана класстарды жазган мен болчумун. Ушундан улам мен да ушундай жагдайларга көп кабылдым. Ал тургай, бул сүрөт менде бир азга илинип турду.

Бул бизге туура келбегендиктен, биз муну алдын алуу жолдорун изилдей баштадык.

Кантип өнүкпөш керек

Биринчи тандоо: иштеп чыгууну жаңыртууда бардык тартуу сурамдарын кайра түзүңүз. Эгерде биздин мисалда А өзгөчөлүгү бар тартуу өтүнүчү иштеп чыгууга биринчи кошулса, В өзгөчөлүгүнүн тартуу сурамы кайра түзүлөт жана, демек, компиляция катасынан улам текшерүүлөр ишке ашпай калат.

Бул канча убакытка созуларын түшүнүү үчүн эки PR менен мисалды карап көрөлү. Биз эки PR ачабыз: эки куруу, эки текшерүү. Биринчи PR иштеп чыгууга бириктирилгенден кийин, экинчисин кайра куруу керек. Жалпысынан эки PR үч текшерүүнү талап кылат: 2 + 1 = 3.

Негизи, баары жакшы. Бирок биз статистиканы карап көрдүк, биздин командадагы типтүү кырдаал 10 ачык PR болду, андан кийин текшерүүлөрдүн саны прогрессиянын суммасы болуп саналат: 10 + 9 +... + 1 = 55. Башкача айтканда, 10 кабыл алуу PRs, 55 жолу кайра куруу керек. Жана бул идеалдуу кырдаалда, бардык текшерүүлөр биринчи жолу өткөндө, бул ондогондор иштетилип жатканда, эч ким кошумча тартуу өтүнүчүн ачпайт.

Өзүңүздү биринчилерден болуп “бириктирүү” баскычын басышы керек болгон иштеп чыгуучу катары элестетиңиз, анткени кошунаңыз муну кылса, анда бардык курулуштар кайра өткүчө күтүшүңүз керек болот... Жок, бул иштебейт. , бул өнүгүүнү олуттуу түрдө жайлатат.

Экинчи мүмкүн болгон жол: кодду карап чыккандан кийин тартуу сурамдарын чогултуу. Башкача айтканда, сиз тартуу өтүнүчүн ачасыз, кесиптештерден керектүү сандагы макулдуктарды чогултуп, керектүү нерсени оңдоп, анан түзүүнү ишке киргизесиз. Эгер алар ийгиликтүү болсо, тартуу өтүнүчү иштеп чыгууга бириктирилет. Бул учурда, эч кандай кошумча кайра бар, бирок пикир абдан жайлатат. Иштеп чыгуучу катары, мен тартуу өтүнүчүн ачканда, анын иштейби же жокпу, дароо көргүм келет. Мисалы, эгер тест өтпөй калса, аны тез арада оңдоо керек. Кечигип куруу учурда, пикир басаңдайт, демек, бүт өнүгүү. Бул бизге да туура келбеди.

Натыйжада, үчүнчү гана вариант калды - велосипед. Биздин бардык кодубуз, бардык булактарыбыз Bitbucket сервериндеги репозиторийде сакталат. Демек, биз Bitbucket үчүн плагинди иштеп чыгышыбыз керек болчу.

Бул плагин тартуу өтүнүчүн бириктирүү механизмин жокко чыгарат. Башталыш стандарттуу: PR ачылат, бардык ассамблеялар ишке киргизилет, кодду карап чыгуу аяктады. Бирок кодду карап чыгуу аяктагандан кийин жана иштеп чыгуучу "бириктирүү" баскычын чыкылдатууну чечкенден кийин, плагин текшерүүлөр кайсы иштеп чыгуу абалына каршы жүргүзүлгөнүн текшерет. Эгерде иштеп чыгуу түзүүдөн кийин жаңыртылган болсо, плагин мындай тартуу өтүнүчүн негизги бутакка бириктирүүгө жол бербейт. Бул жөн гана салыштырмалуу жакында эле иштеп чыгууларды кайра баштайт.

Биздин мисалда карама-каршы өзгөрүүлөр менен, мындай түзүлүштөр компиляция катасынан улам ишке ашпай калат. Демек, B функциясын иштеп чыгуучу кодду оңдоп, текшерүүлөрдү кайра башташы керек, андан кийин плагин автоматтык түрдө тартуу өтүнүчүн колдонот.

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

Бул плагиндин кемчилиги бар экенин белгилей кетүү керек: ал курууну бир жолу гана кайра баштайт. Башкача айтканда, карама-каршы өзгөрүүлөрдүн өнүгүшүнө кире турган кичинекей терезе бар. Бирок мунун ыктымалдыгы төмөн жана биз бул старттардын саны менен ийгиликсиз болуу ыктымалынын ортосунда соодалаштык. Эки жылда бир эле жолу атты, демек, бекер болбосо керек.

Bitbucket плагининин биринчи версиясын жазууга эки жума убакыт кетти.

Жаңы текшерүүлөр

Ошол эле учурда биздин команда дагы өсө берди. Жаңы чектер кошулду.

Биз ойлодук: эгер каталарды болтурбай коюуга мүмкүн болсо, эмне үчүн? Ошондон улам алар ишке ашырышты статикалык кодду талдоо. Биз Android SDK камтылган Lint менен баштадык. Бирок ал кезде Котлин коду менен иштөөнү такыр билчү эмес жана бизде 75% арыз Котлинде жазылган. Ошондуктан, линтке курулгандары кошулган Android Studio текшерет.

Бул үчүн, биз көп бузукулук кылышыбыз керек болчу: Android Studio'ну алып, аны Dockerде топтоп, виртуалдык монитор менен CIде иштетиңиз, ал чыныгы ноутбукта иштеп жатат деп ойлойт. Бирок ал иштеди.

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

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

Firebase сыноо лабораториясы

Firebase Google продуктусу болгондуктан, ал ишенимдүү жана эч качан өлбөй калышы керек дегенди билдирет. Баалар акылга сыярлык: реалдуу аппараттын саатына 5 доллар, эмулятордун саатына 1 доллар.

Firebase Test Lab программасын биздин CIге киргизүүгө болжол менен үч жума кетти.

Бирок команда өсө берди жана Firebase, тилекке каршы, бизди кетире баштады. Ошол учурда анын эч кандай SLAсы болгон эмес. Кээде Firebase бизди тесттер үчүн керектүү сандагы түзмөктөр бош болгуча күтүүгө мажбур кылды жана биз каалагандай дароо ишке киргизе албады. Кезек күтүү жарым саатка чейин созулду, бул абдан көп убакыт. Ар бир PR боюнча инструменталдык тесттер жүргүзүлдү, кечигүү чындыгында өнүгүүнү жайлады, анан айлык эсеп тегерек сумма менен келди. Жалпысынан, команда жетиштүү өскөндүктөн, Firebaseтен баш тартып, үйдө иштөө чечими кабыл алынды.

Docker + Python + bash

Биз Докерди алдык, ага эмуляторлорду толтурдук, Python тилинде жөнөкөй программа жаздык, ал керектүү учурда керектүү версиядагы эмуляторлордун керектүү санын алып келип, керек болгондо аларды токтотот. Анан, албетте, бир нече баш сценарийлер - аларсыз биз кайда болмокпуз?

Өзүбүздүн тест чөйрөбүздү түзүүгө беш жума кетти.

Натыйжада, ар бир тартуу өтүнүчү үчүн текшерүүлөрдүн кеңири бириктирүү-бөгөттөөчү тизмеси бар болчу:

• ARK жыйыны;
• Junit тесттери;
• линт;
• Android Studio текшерүүлөрү;
• Инструменталдык тесттер;
• Скриншот тесттери.

Бул көптөгөн мүмкүн болгон бузулуулардын алдын алды. Техникалык жактан баары иштеди, бирок иштеп чыгуучулар жыйынтыктарды күтүү өтө көпкө созулганына нааразы болушту.

Канча убакыт өтө узун болуп саналат? Биз Bitbucket жана TeamCityден маалыматтарды талдоо тутумуна жүктөдүк жана муну түшүндүк орточо күтүү убактысы 45 мүнөт. Башкача айтканда, иштеп чыгуучу, тартуу өтүнүчүн ачып жатканда, куруу натыйжаларын орточо 45 мүнөт күтөт. Менин оюмча, бул көп, сен мындай иштей албайсың.

Албетте, биз бардык курулуштарыбызды тездетүүнү чечтик.

Келгиле, тездетели

Курулуштар көп учурда кезекте турганын көрүп, биринчи кезекте биз жасайбыз дагы аппаратура сатып алды — экстенсивдүү өнүгүү эң жөнөкөй. Курулуштар кезекке турууну токтотту, бирок күтүү убактысы бир аз гана кыскарды, анткени кээ бир текшерүүлөрдүн өзү абдан көп убакытты талап кылды.

Өтө көп убакытты талап кылган текшерүүлөрдү алып салуу

Биздин Үзгүлтүксүз Интеграциябыз мындай каталарды жана көйгөйлөрдү чече алат.

• Барбайт. Бир нерсе карама-каршы келген өзгөрүүлөрдөн улам түзүлбөй калганда, CI компиляция катасын байкай алат. Мен жогоруда айткандай, анда эч ким эч нерсе чогулта албайт, өнүгүү токтоп, баары толкунданып кетет.
• Жүрүм-турумундагы ката. Мисалы, тиркеме курулуп жатканда, бирок баскычты басканда бузулуп калат же баскыч такыр басылбай калат. Бул жаман, анткени мындай ката колдонуучуга жетиши мүмкүн.
• Калыбында ката. Мисалы, баскыч басылды, бирок 10 пиксел солго жылдырылды.
• Техникалык карыздын көбөйүшү.

Бул тизмени карап чыккандан кийин, биз биринчи эки пункттун гана маанилүү экенин түшүндүк. Мындай көйгөйлөрдү биринчи кармагыбыз келет. Макеттеги мүчүлүштүктөр долбоорлоо-карап чыгуу стадиясында табылып, андан кийин оңой оңдоого болот. Техникалык карыз менен күрөшүү өзүнчө процессти жана пландоону талап кылат, ошондуктан биз аны тартуу өтүнүчү боюнча сынап көрбөүүнү чечтик.

Бул классификациянын негизинде биз текшерүүлөрдүн толук тизмесин чайкап алдык. Чыгылган Линт жана аны ишке киргизүүнү бир түнгө кийинкиге калтырды: ал долбоордо канча көйгөйлөр бар экендиги жөнүндө отчет чыгарышы үчүн. Техникалык карыз менен өзүнчө иштөөгө макул болдук, жана Android Studio текшерүүлөрү толугу менен ташталды. Докердеги Android Studio текшерүүлөрдү жүргүзүү үчүн кызыктуу угулат, бирок колдоодо көп кыйынчылыктарды жаратат. Android Studio версияларына ар кандай жаңыртуу түшүнүксүз мүчүлүштүктөр менен күрөшүүнү билдирет. Скриншот тесттерин колдоо да кыйынга турду, анткени китепкана өтө туруктуу эмес жана жалган позитивдер бар болчу. Скриншот тесттери текшерүү тизмесинен алынып салынды.

Натыйжада, биз менен калды:

• ARK жыйыны;
• Junit тесттери;
• Инструменталдык тесттер.

Gradle алыскы кэш

Катуу текшерүүлөрсүз, баары жакшы болуп калды. Бирок кемчиликсиздиктин чеги жок!

Биздин тиркеме буга чейин 150гө жакын класстык модулдарга бөлүнгөн. Gradle алыскы кэш, адатта, бул учурда жакшы иштейт, ошондуктан биз аны сынап көрүүнү чечтик.

Gradle алыскы кэш - бул жеке модулдардагы жеке тапшырмалар үчүн куруу артефакттарын кэштей турган кызмат. Gradle, чындыгында кодду түзүүнүн ордуна, алыскы кэшти кагуу үчүн HTTP колдонот жана кимдир бирөө бул тапшырманы аткардыбы деп сурайт. Ооба болсо, ал жөн гана натыйжаны жүктөп алат.

Gradle алыскы кэшин иштетүү оңой, анткени Gradle Docker сүрөтүн берет. Муну үч сааттын ичинде бүтүрдүк.

Болгону Докерди ишке киргизип, долбоорго бир сап жазуу керек болчу. Бирок аны тез эле ишке киргизсе да, баары жакшы иштеши үчүн бир топ убакыт талап кылынат.

Төмөндө кэш сагынуу графиги.

Башында, кэш сагынуу пайызы болжол менен 65 болчу. Үч жумадан кийин биз бул көрсөткүчтү 20% га чейин көтөрө алдык. Көрсө, Android тиркемеси чогулткан тапшырмалар кызыктай транзиттик көз карандылыктарга ээ экен, андыктан Градл кэшти өткөрүп жиберген.

Кэшти туташтыруу менен биз курууну абдан тездеттик. Бирок монтаждоодон тышкары приборлорду сыноо да бар жана алар көп убакытты талап кылат. Балким, ар бир тартуу өтүнүчү үчүн бардык сыноолорду жүргүзүү керек эмес. Аны билүү үчүн биз таасир анализин колдонобуз.

Таасир анализи

Тартуу өтүнүчү боюнча биз git diff чогултабыз жана өзгөртүлгөн Gradle модулдарын табабыз.

Өзгөрүлгөн модулдарды жана аларга көз каранды болгон бардык модулдарды текшерген аспаптык тесттерди гана жүргүзүү мааниси бар. Коңшу модулдар үчүн тесттерди жүргүзүүнүн мааниси жок: ал жердеги код өзгөргөн жок жана эч нерсе бузулбайт.

Инструменталдык тесттер өтө жөнөкөй эмес, анткени алар жогорку деңгээлдеги Колдонмо модулунда жайгашуусу керек. Ар бир тест кайсы модулга таандык экенин түшүнүү үчүн байт-код анализи менен эвристиканы колдондук.

Приборлор сыноолорунун иштешин өркүндөтүү, алар тартылган модулдарды гана сынап көрүү үчүн сегиз жумага жакын убакытты алды.

Текшерүүнү тездетүү боюнча чаралар ийгиликтүү натыйжа берди. 45 мүнөттөн биз болжол менен 15ке чейин чыктык. Бул куруу үчүн чейрек саат күтүү кадимки эле көрүнүш.

Бирок азыр иштеп чыгуучулар кайсы курулуштар ишке киргизилип жатканын, журналды кайдан көрүүнү, эмне үчүн куруу кызыл, кайсы сыноодон өтпөй калганын, ж.

Пикир менен байланышкан көйгөйлөр өнүгүүнү жайлатат, ошондуктан биз ар бир PR жөнүндө так жана толук маалымат берүүгө жана мүмкүн болушунча курууга аракет кылдык. Биз Bitbucket'те пиарга комментарий берүү менен баштадык, кайсы курулуш ишке ашпай калганын жана эмне үчүн экенин көрсөтүп, Slack'те максаттуу билдирүүлөрдү жаздык. Акыр-аягы, биз учурда иштеп жаткан бардык түзүмдөрдүн тизмеси жана алардын статусу бар баракча үчүн PR тактасын түздүк: кезекте турган, иштеп жаткан, бузулган же аяктаган. Сиз курууну басып, анын журналына кире аласыз.

Алты жума деталдуу пикирлерге жумшалды.

пландар

Келгиле, жакынкы тарыхка кайрылалы. Пикир маселесин чечип, биз жаңы деңгээлге чыктык - өзүбүздүн эмулятор фермабызды курууну чечтик. Көптөгөн тесттер жана эмуляторлор болгондо, аларды башкаруу кыйын. Натыйжада, биздин бардык эмуляторлор ийкемдүү ресурстарды башкаруу менен k8s кластерине өттү.

Мындан тышкары дагы башка пландар бар.

• Кайтаруу Lint (жана башка статикалык талдоо). Биз азыртан эле бул багытта иштеп жатабыз.
• Баарын PR блокатордо иштетиңиз аягына чейин сыноолор бардык SDK версияларында.

Ошентип, биз Avitoдо Үзгүлтүксүз интеграциянын өнүгүү тарыхына көз салдык. Эми мен тажрыйбалуу көз караштан бир нече кеңеш бергим келет.

шарттары

Эгер мен бир гана кеңеш бере турган болсом, бул мындай болмок:

Сураныч, кабык скрипттери менен сак болуңуз!

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

Мунун баары биздин куруу машиналарында иштеген жөнөкөй скрипттерден башталды:

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

Бирок, өзүңүздөр билгендей, убакыттын өтүшү менен баары өнүгүп, татаалдашат - келгиле, бир скриптти экинчисинен иштетели, ал жерге кээ бир параметрлерди өткөрүп берели - аягында биз азыр баш уясынын кандай деңгээлинде экенибизди аныктаган функцияны жазууга туура келди. зарыл болгон тырмакчаларды киргизүү, баарын баштоо үчүн.

Мындай сценарийлерди иштеп чыгуу үчүн эмгек чыгымдарын элестете аласыз. Бул тузакка түшпөгүлө деп кеңеш берем.

Эмнени алмаштырса болот?

• Ар кандай скрипт тили. Жазуу Python же Котлин Скрипти ыңгайлуураак, анткени ал скрипттер эмес, программалоо.
• Же формадагы бардык куруу логикасын сүрөттөп бериңиз Ыңгайлаштырылган класстык тапшырмалар сиздин долбоор үчүн.

Биз экинчи вариантты тандоону чечтик, эми биз бардык 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ке келиңиз.

Source: www.habr.com