Өнөөдөр ихэнх програм хангамжийн бүтээгдэхүүнийг багаар боловсруулдаг. Багийг амжилттай хөгжүүлэх нөхцөлийг энгийн диаграм хэлбэрээр дүрсэлж болно.

Кодоо бичсэний дараа та үүнийг баталгаажуулах хэрэгтэй:

1. Работает.
2. Энэ нь таны хамт ажиллагсдын бичсэн кодыг оруулаад юу ч эвддэггүй.

Хэрэв хоёр нөхцөл хангагдсан бол та амжилтанд хүрэх зам дээр байна. Эдгээр нөхцлүүдийг хялбархан шалгаж, ашигтай замаасаа хазайхгүйн тулд бид тасралтгүй интеграцийг санаачилсан.

CI бол таны кодыг бүтээгдэхүүний ерөнхий кодтой аль болох олон удаа нэгтгэдэг ажлын урсгал юм. Та зөвхөн нэгтгээд зогсохгүй бүх зүйл ажиллаж байгаа эсэхийг байнга шалгадаг. Та маш олон удаа шалгах шаардлагатай байдаг тул автоматжуулалтын талаар бодох нь зүйтэй. Та бүх зүйлийг гараар шалгаж болно, гэхдээ хийх ёсгүй, яагаад гэвэл энд байна.

• Эрхэм хүндэт хүмүүсээ. Аливаа програмистын нэг цаг ажиллах нь ямар ч серверийн нэг цаг ажиллахаас илүү үнэтэй байдаг.
• Хүмүүс алдаа гаргадаг. Тиймээс туршилтыг буруу салбар дээр явуулсан эсвэл шалгагчдад зориулж буруу амлалт хийсэн тохиолдолд нөхцөл байдал үүсч болно.
• Хүмүүс залхуу. Хааяа нэг ажлыг дуусгаад ирэхээр “Шалгах зүйл юу байна? Би хоёр мөр бичсэн - бүх зүйл ажилладаг! Та нарын заримд бас заримдаа ийм бодол төрдөг гэж би бодож байна. Гэхдээ та үргэлж шалгаж байх хэрэгтэй.

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

Энэ түүх нь Андройдын командын жишээн дээр үндэслэсэн боловч ихэнх арга барилууд iOS дээр ч хэрэгждэг.

Нэгэн удаа Avito Android багт нэг хүн ажиллаж байсан. Тодорхойлолтоор түүнд Тасралтгүй интеграцчлалаас юу ч хэрэггүй байсан: нэгтгэх хүн байсангүй.

Гэвч програм өргөжиж, улам олон шинэ даалгавар гарч ирэн, баг нь үүний дагуу өсч байв. Хэзээ нэгэн цагт кодыг нэгтгэх үйл явцыг илүү албан ёсоор бий болгох цаг болжээ. Git урсгалыг ашиглахаар шийдсэн.

Git flow-ийн тухай ойлголтыг сайн мэддэг: төсөл нь нэг нийтлэг хөгжүүлэлтийн салбартай байдаг бөгөөд шинэ функц бүрийн хувьд хөгжүүлэгчид тусдаа салбарыг хайчилж, түүнд үүрэг өгч, түлхэж, кодоо хөгжүүлэлтийн салбар руу нэгтгэхийг хүсвэл татах хүсэлт. Мэдлэгээ хуваалцах, арга барилаа хэлэлцэхийн тулд бид кодын хяналтыг нэвтрүүлсэн, өөрөөр хэлбэл хамт олон бие биенийхээ кодыг шалгаж баталгаажуулах ёстой.

Шалгалтууд

Кодыг нүдээрээ харах нь сайхан боловч хангалттай биш. Тиймээс автомат шалгалтыг нэвтрүүлж байна.

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

Эдгээр шалгалтыг хэрхэн хийх ёстойг ойлгохын тулд Avito дахь хөгжүүлэлтийн процессыг харцгаая.

Үүнийг схемийн дагуу дараах байдлаар илэрхийлж болно.

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

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

Бид шөнийн цагаар шалгалт хийх дуртай байсан, учир нь маш их цаг хугацаа, серверүүд байдаг тул та эргэн тойрон тэнүүчилж болно. Гэвч харамсалтай нь функцын кодыг хөгжүүлж эхлэхэд хөгжүүлэгчид 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 заримдаа биднийг урам хугарах болсон. Devel-д зөрчилдөөнтэй өөрчлөлтүүд гарч, уг бүтээцийг эвдсэн.

Энэ нь хэрхэн болдог тухай жишээ:

Хоёр хөгжүүлэгчид нэгэн зэрэг А болон В функцууд дээр ажиллаж эхэлдэг. А функцийг хөгжүүлэгчид төсөлд ашиглагдаагүй функцийг илрүүлсэн. answer() тэгээд сайн скаут шиг түүнийг арилгадаг. Үүний зэрэгцээ В функцийг хөгжүүлэгч өөрийн салбар дахь энэ функцэд шинэ дуудлага нэмдэг.

Хөгжүүлэгчид ажлаа дуусгаад татах хүсэлтийг нэгэн зэрэг нээдэг. Бүтээлүүд эхэлсэн, premerge.sh хамгийн сүүлийн үеийн хөгжүүлэлтийн төлөвтэй холбоотой татах хүсэлтийг хоёуланг нь шалгадаг - бүх шалгалт ногоон өнгөтэй байна. Үүний дараа A функцийн татах хүсэлтийг нэгтгэж, В функцийн татах хүсэлтийг нэгтгэнэ ... Boom! Хөгжүүлэх код нь байхгүй функцийн дуудлагыг агуулж байгаа тул хөгжүүлэлтийн завсарлага.

Энэ нь хөгжихгүй байх үед энэ нь орон нутгийн гамшиг. Бүхэл бүтэн баг юу ч цуглуулж, шинжилгээнд өгөх боломжгүй.

Би ихэвчлэн дэд бүтцийн ажлууд дээр ажилладаг байсан: аналитик, сүлжээ, мэдээллийн сан. Өөрөөр хэлбэл, бусад хөгжүүлэгчдийн ашигладаг эдгээр функц, ангиудыг би бичсэн. Үүнээс болж би үүнтэй төстэй нөхцөл байдалд байнга ордог байсан. Би бүр энэ зургийг хэсэг хугацаанд өлгөж байсан.

Энэ нь бидэнд тохирохгүй байсан тул бид үүнээс хэрхэн урьдчилан сэргийлэх хувилбаруудыг судалж эхэлсэн.

Хэрхэн хөгжихгүй байх вэ

Эхний хувилбар: хөгжүүлэлтийг шинэчлэх үед бүх татах хүсэлтийг дахин бүтээх. Хэрэв бидний жишээн дээр А функцтэй татах хүсэлт нь хөгжүүлэлтэд хамгийн түрүүнд орсон бол В функцийн татах хүсэлт дахин бүтээгдэх ба үүний дагуу эмхэтгэлийн алдааны улмаас шалгалт амжилтгүй болно.

Энэ нь хэр удаан үргэлжлэхийг ойлгохын тулд хоёр PR-тай жишээг авч үзье. Бид хоёр PR нээдэг: хоёр бүтээц, хоёр шалгалт. Эхний PR-ийг хөгжүүлэлт болгон нэгтгэсний дараа хоёр дахь нь дахин бүтээх шаардлагатай. Нийтдээ хоёр PR-д гурван удаагийн шалгалт шаардлагатай: 2 + 1 = 3.

Зарчмын хувьд бол зүгээр. Гэхдээ бид статистикийг харсан бөгөөд манай багийн ердийн нөхцөл байдал нь 10 нээлттэй PR байсан бөгөөд дараа нь шалгалтын тоо нь ахиц дэвшлийн нийлбэр юм: 10 + 9 +... + 1 = 55. Энэ нь 10-ыг хүлээн зөвшөөрөх явдал юм. PR, та 55 удаа дахин бүтээх хэрэгтэй. Энэ нь бүх шалгалтыг анх удаа давах, эдгээр хэдэн арван шалгалтыг боловсруулж байх үед хэн ч нэмэлт татах хүсэлтийг нээхгүй байх хамгийн тохиромжтой нөхцөл юм.

Өөрийгөө "нийтэх" товчийг хамгийн түрүүнд дарах шаардлагатай хөгжүүлэгч гэж төсөөлөөд үз дээ, учир нь хөрш нь үүнийг хийвэл та бүх бүтээн байгуулалтыг дахин хийх хүртэл хүлээх хэрэгтэй болно ... Үгүй ээ, энэ нь ажиллахгүй. , энэ нь хөгжлийг ноцтой удаашруулна.

Хоёрдахь боломжит арга: кодыг шалгасны дараа татах хүсэлтийг цуглуулах. Өөрөөр хэлбэл, та татах хүсэлтийг нээж, хамт ажиллагсдаас шаардлагатай тооны зөвшөөрлийг цуглуулж, шаардлагатай зүйлийг засч, дараа нь бүтээцийг эхлүүлнэ. Хэрэв тэд амжилттай бол татах хүсэлтийг хөгжүүлэлт болгон нэгтгэнэ. Энэ тохиолдолд нэмэлт дахин асаалт байхгүй ч санал хүсэлт ихээхэн удааширдаг. Хөгжүүлэгчийн хувьд би татах хүсэлтийг нээхэд энэ нь ажиллах эсэхийг шууд харахыг хүсдэг. Жишээлбэл, хэрэв шалгалт амжилтгүй болвол хурдан засах хэрэгтэй. Барилга саатсан тохиолдолд санал хүсэлт удааширч, улмаар бүхэл бүтэн хөгжил удааширдаг. Энэ нь бас бидэнд тохирохгүй байсан.

Үүний үр дүнд зөвхөн гурав дахь сонголт үлдсэн - дугуйн. Бидний бүх код, бүх эх сурвалжууд Bitbucket сервер дээрх репозиторид хадгалагддаг. Үүний дагуу бид Bitbucket-д зориулсан залгаас боловсруулах шаардлагатай болсон.

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

Зөрчилтэй өөрчлөлт бүхий бидний жишээн дээр эмхэтгэлийн алдааны улмаас ийм бүтээц амжилтгүй болно. Үүний дагуу В функцийг хөгжүүлэгчид кодыг засч, шалгалтыг дахин эхлүүлэх шаардлагатай бөгөөд залгаас нь татах хүсэлтийг автоматаар хэрэгжүүлэх болно.

Энэ залгаасыг хэрэгжүүлэхээс өмнө бид татах хүсэлт бүрт дунджаар 2,7 хянан шалгасан. Plugin-ийн тусламжтайгаар 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 дээр энгийн програм бичсэн бөгөөд энэ нь зөв цагт шаардлагатай тооны эмуляторуудыг шаардлагатай хувилбарт оруулж, шаардлагатай үед зогсоодог. Мэдээжийн хэрэг, хэд хэдэн баш скриптүүд - тэдэнгүйгээр бид хаана байх байсан бэ?

Бид өөрсдийн туршилтын орчинг бий болгоход таван долоо хоног зарцуулсан.

Үүний үр дүнд татах хүсэлт болгонд нэгдэхийг хориглох өргөн хүрээтэй шалгалтын жагсаалт гарсан:

• ARK угсралт;
• Junit тестүүд;
• хөвөн;
• Android Studio шалгалт;
• багаж хэрэгслийн туршилт;
• Дэлгэцийн зургийн тестүүд.

Энэ нь олон болзошгүй эвдрэлээс сэргийлсэн. Техникийн хувьд бүх зүйл үр дүнтэй байсан ч хөгжүүлэгчид үр дүнг хүлээх нь хэтэрхий удаан байна гэж гомдолложээ.

Хэр их урт вэ? Бид Bitbucket болон TeamCity-ийн өгөгдлийг шинжилгээний системд байршуулж, үүнийг ойлгосон дундаж хүлээх хугацаа 45 минут. Өөрөөр хэлбэл, хөгжүүлэгч татах хүсэлтийг нээхдээ бүтээх үр дүнг дунджаар 45 минут хүлээдэг. Миний бодлоор энэ бол маш их зүйл бөгөөд та ингэж ажиллах боломжгүй.

Мэдээжийн хэрэг, бид бүх бүтээн байгуулалтаа хурдасгахаар шийдсэн.

Хурд хийцгээе

Барилга нь ихэвчлэн дараалалд зогсдогийг хараад бидний хийх хамгийн эхний зүйл илүү техник хангамж худалдаж авсан - өргөн хүрээтэй хөгжүүлэлт бол хамгийн энгийн зүйл юм. Барилгад дараалал зогссон боловч зарим шалгалт өөрөө маш удаан үргэлжилдэг тул хүлээх хугацаа бага зэрэг буурсан.

Хэт удаан хугацаа шаардсан чекийг устгаж байна

Бидний тасралтгүй интеграци нь ийм төрлийн алдаа, асуудлуудыг барьж чадна.

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

Энэ жагсаалтыг харсны дараа бид зөвхөн эхний хоёр зүйл чухал гэдгийг ойлгосон. Ийм асуудлуудыг бид эхлээд барьж авмаар байна. Байршлын алдаа нь дизайныг хянах үе шатанд илэрсэн бөгөөд дараа нь амархан засч залруулж болно. Техникийн өрийг шийдвэрлэх нь тусдаа үйл явц, төлөвлөлт шаарддаг тул бид үүнийг татах хүсэлт дээр туршихгүй байхаар шийдсэн.

Энэ ангилалд үндэслэн бид шалгалтын жагсаалтыг бүхэлд нь сэгсэрлээ. Загалмайлсан Lint Төсөлд хичнээн асуудал байгаа талаар тайлан гаргахын тулд нэг шөнийн дотор нээлтээ хойшлуулав. Техникийн өртэй тус тусдаа ажиллахаар тохиролцсон, мөн Android Studio шалгалтыг бүрэн орхисон. Шалгалт явуулахад зориулагдсан Docker дахь Android Studio нь сонирхолтой мэт санагдаж байгаа ч дэмжлэг үзүүлэхэд ихээхэн бэрхшээл учруулдаг. Android Studio хувилбаруудын аливаа шинэчлэлт нь үл ойлгогдох алдаатай тэмцэнэ гэсэн үг. Номын сан тийм ч тогтвортой биш, худал эерэг гарсан тул дэлгэцийн агшинг шалгах тестийг дэмжихэд хэцүү байсан. Дэлгэцийн агшин тестийг шалгах жагсаалтаас хассан.

Үүний үр дүнд бид дараахь зүйлийг үлдээсэн.

• ARK угсралт;
• Junit тестүүд;
• Багаж хэрэгслийн туршилтууд.

Gradle алсын кэш

Хүнд шалгалтгүйгээр бүх зүйл сайжирсан. Гэхдээ төгс төгөлдөрт хязгаар гэж үгүй!

Манай програм аль хэдийн 150 орчим градиент модулиудад хуваагдсан. Gradle remote cache ихэвчлэн энэ тохиолдолд сайн ажилладаг тул бид үүнийг туршиж үзэхээр шийдсэн.

Gradle remote cache нь тусдаа модулиудад бие даасан даалгаварт зориулж бүтээх олдворуудыг кэшлэх үйлчилгээ юм. Gradle кодыг хөрвүүлэхийн оронд HTTP ашиглан алсын санах ойг тогшиж, хэн нэгэн энэ ажлыг аль хэдийн гүйцэтгэсэн эсэхийг асууна. Хэрэв тийм бол үр дүнг нь татаж авна.

Gradle нь Docker дүрсээр хангадаг тул Gradle-н алсын кэшийг ажиллуулахад хялбар байдаг. Бид үүнийг гурван цагийн дотор хийж чадсан.

Таны хийх ёстой зүйл бол Docker програмыг ажиллуулж, төсөлд нэг мөр бичих явдал байв. Гэхдээ үүнийг хурдан эхлүүлэх боломжтой ч бүх зүйл сайн ажиллахын тулд маш их цаг хугацаа шаардагдана.

Доорх нь кэш алдах график юм.

Анхандаа кэш алдааны хувь 65 орчим байсан. Гурван долоо хоногийн дараа бид энэ утгыг 20% хүртэл өсгөж чадсан. Андройд програмын цуглуулдаг даалгаврууд нь хачирхалтай шилжилтийн хамааралтай байсан тул Градл кэшийг алдсан байна.

Кэшийг холбосноор бид бүтээх ажлыг ихээхэн хурдасгасан. Гэхдээ угсрахаас гадна багаж хэрэгслийн туршилтууд байдаг бөгөөд тэдгээр нь удаан хугацаа шаарддаг. Татаж авах хүсэлт бүрт бүх туршилтыг явуулах шаардлагагүй байж магадгүй юм. Үүнийг мэдэхийн тулд бид нөлөөллийн шинжилгээг ашигладаг.

Нөлөөллийн шинжилгээ

Татах хүсэлтээр бид git diff цуглуулж, өөрчлөгдсөн Gradle модулиудыг олдог.

Зөвхөн өөрчилсөн модулиуд болон тэдгээрээс хамаарах бүх модулиудыг шалгадаг багаж хэрэгслийн туршилтыг явуулах нь утга учиртай. Хөрш зэргэлдээ модулиудын туршилтыг явуулах нь утгагүй юм: тэнд байгаа код өөрчлөгдөөгүй бөгөөд юу ч эвдэрч чадахгүй.

Багаж хэрэгслийн туршилт нь тийм ч хялбар биш, учир нь тэдгээр нь дээд түвшний Хэрэглээний модульд байрлах ёстой. Бид тест бүр аль модульд хамаарахыг ойлгохын тулд байт кодын шинжилгээ бүхий эвристикийг ашигласан.

Багаж хэрэгслийн туршилтын ажиллагааг сайжруулахад зөвхөн холбогдох модулиудыг туршихад найман долоо хоног зарцуулсан.

Хяналт шалгалтыг шуурхай болгох арга хэмжээ амжилттай хэрэгжсэн. 45 минутаас бид ойролцоогоор 15 цаг хүртэл өссөн. Барилга барихын тулд дөрөвний нэг цаг хүлээх нь аль хэдийн хэвийн байна.

Харин одоо хөгжүүлэгчид аль бүтээн байгуулалтыг эхлүүлж байгаа, логыг хаанаас харах, яагаад бүтэц нь улаан болсон, ямар туршилт амжилтгүй болсон гэх мэтийг ойлгохгүй байна гэж гомдоллож эхэлсэн.

Санал хүсэлтийн асуудал нь хөгжлийг удаашруулдаг тул бид PR бүрийн талаар тодорхой, дэлгэрэнгүй мэдээлэл өгөх, бүтээхийг хичээсэн. Бид Bitbucket-д PR-д ямар бүтээц амжилтгүй болсон, яагаад бүтэлгүйтсэн талаар тайлбар хийж, Slack дээр зорилтот мессеж бичсэн. Төгсгөлд нь бид одоо ажиллаж байгаа бүх бүтээц, тэдгээрийн статус: дараалалд орсон, ажиллаж байгаа, эвдэрсэн эсвэл дууссан гэсэн жагсаалт бүхий PR хяналтын самбарыг тухайн хуудсанд зориулж бүтээсэн. Та бүтээц дээр товшоод түүний бүртгэл рүү орж болно.

Нарийвчилсан санал хүсэлтэд зургаан долоо хоног зарцуулсан.

Төлөвлөгөө

Ойрын түүх рүү шилжье. Санал хүсэлтийн асуудлыг шийдэж, бид шинэ түвшинд хүрсэн - бид өөрийн эмулятор ферм байгуулахаар шийдсэн. Олон тест, эмулятор байгаа тохиолдолд тэдгээрийг удирдахад хэцүү байдаг. Үүний үр дүнд манай бүх эмуляторууд нөөцийн уян хатан удирдлагатай k8s кластер руу шилжсэн.

Үүнээс гадна өөр төлөвлөгөө бий.

• Линтийг буцаана (болон бусад статик шинжилгээ). Бид энэ чиглэлээр аль хэдийн ажиллаж байна.
• Бүгдийг PR хориглогч дээр ажиллуул төгсгөл хүртэлх туршилтууд бүх SDK хувилбарууд дээр.

Тиймээс бид Avito дахь тасралтгүй интеграцийн хөгжлийн түүхийг судалж үзсэн. Одоо би туршлагатай хүнээс зөвлөгөө өгөхийг хүсч байна.

Зөвлөмж

Хэрэв би ганцхан зөвлөгөө өгвөл энэ нь дараах байх болно.

Бүрхүүлийн скриптүүдтэй болгоомжтой байгаарай!

Bash бол маш уян хатан, хүчирхэг хэрэгсэл бөгөөд скрипт бичихэд маш тохиромжтой бөгөөд хурдан юм. Гэхдээ та үүнтэй хамт урхинд орж болно, харамсалтай нь бид үүнд унасан.

Энэ бүхэн бидний бүтээх машинууд дээр ажилладаг энгийн скриптүүдээс эхэлсэн:

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

Гэхдээ та бүхний мэдэж байгаагаар цаг хугацаа өнгөрөх тусам бүх зүйл хөгжиж, илүү төвөгтэй болдог - нэг скриптийг нөгөөгөөс нь ажиллуулж, зарим параметрүүдийг тэнд дамжуулъя - эцэст нь бид одоо bash үүрлэх ямар түвшинд байгааг тодорхойлох функц бичих шаардлагатай болсон. шаардлагатай ишлэлүүдийг оруулах, бүгдийг эхлүүлэх.

Ийм скриптийг боловсруулахад шаардагдах хөдөлмөрийн зардлыг та төсөөлж болно. Энэ урхинд битгий ороорой гэж зөвлөж байна.

Юуг сольж болох вэ?

• Ямар ч скрипт хэл. Бичих Python эсвэл Kotlin скрипт Энэ нь скрипт биш програмчлал учраас илүү тохиромжтой.
• Эсвэл бүх бүтээх логикийг маягт дээр тайлбарлана уу Захиалгат gradle даалгавар таны төслийн хувьд.

Бид хоёр дахь сонголтыг сонгохоор шийдсэн бөгөөд одоо бид бүх 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 тестүүдийг ажиллуул.

Үүнийг утга учиртай болгож буй хоёр гол шалтгаан нь өргөтгөх чадвар, давтагдах чадвар юм. Docker-ийг ашигласнаар та өмнөхтэй яг ижил орчинтой байх хэдэн арван бүтээх агентуудыг хурдан босгож чадна. Энэ нь CI инженерүүдийн амьдралыг ихээхэн хөнгөвчилдөг. Android-sdk-г докер руу түлхэх нь маш амархан, гэхдээ эмуляторуудын хувьд энэ нь арай илүү хэцүү байдаг: та бага зэрэг шаргуу ажиллах хэрэгтэй болно (эсвэл GitHub-аас дууссан хувилбарыг дахин татаж авах).

Зөвлөгөө No4: Хяналт шалгалтыг шалгахын тулд биш, харин хүмүүсийн төлөө хийдэг гэдгийг мартаж болохгүй.

Хөгжүүлэгчдийн хувьд хурдан бөгөөд хамгийн чухал нь тодорхой санал хүсэлт нь маш чухал юм: юу эвдэрсэн, ямар туршилт амжилтгүй болсон, барилгын бүртгэлийг хаанаас харж болох вэ.

Зөвлөмж №5: Тасралтгүй интеграцийг хөгжүүлэхдээ прагматик бай.

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

Зөвлөмж №6: Бэлэн багаж хэрэглээрэй.

Одоо үүлэн CI үйлчилгээ үзүүлдэг олон компани бий.

Энэ бол жижиг багуудын хувьд сайн шийдэл юм. Та юуг ч дэмжих шаардлагагүй, зүгээр л бага зэрэг мөнгө төлж, програмаа боловсруулж, багаж хэрэгслийн туршилтыг хүртэл ажиллуулаарай.

Зөвлөмж №7: Том багтай бол дотооддоо шийдлүүд илүү ашигтай байдаг.

Гэхдээ эрт орой хэзээ нэгэн цагт баг томрох тусам дотоод шийдэл нь илүү ашигтай байх болно. Эдгээр шийдвэрүүдэд нэг асуудал бий. Эдийн засагт өгөөж буурах хууль байдаг: аливаа төсөлд дараагийн сайжруулалт бүр улам бүр хэцүү бөгөөд илүү их хөрөнгө оруулалт шаарддаг.

Эдийн засаг нь бидний бүхий л амьдралыг, тэр дундаа Тасралтгүй интеграцийг тодорхойлдог. Би тасралтгүй интеграцийн хөгжлийн үе шат бүрийн хөдөлмөрийн зардлын хуваарийг гаргасан.

Аливаа сайжруулалт улам бүр хэцүү болж байгаа нь ойлгомжтой. Энэ графикийг харахад та багийн цар хүрээний өсөлттэй уялдуулан Тасралтгүй интеграцчлалыг хөгжүүлэх шаардлагатай байгааг ойлгож болно. Хоёр хүний ​​бүрэлдэхүүнтэй багийн хувьд дотоод эмуляторын фермийг хөгжүүлэхэд 50 хоног зарцуулах нь дундаж санаа юм. Гэхдээ үүнтэй зэрэгцэн том багийн хувьд Continuous Integration хийхгүй байх нь бас муу санаа юм, учир нь интеграцийн асуудал, харилцаа холбоог засах гэх мэт. энэ нь бүр илүү их цаг хугацаа шаардах болно.

Хүмүүс үнэтэй, алдаа гаргадаг, залхуу байдаг учраас автоматжуулалт хэрэгтэй гэсэн санааг бид эхлүүлсэн. Гэхдээ хүмүүс бас автоматжуулдаг. Тиймээс автоматжуулалтад ижил асуудлууд хамаатай.

• Автоматжуулалт нь үнэтэй байдаг. Хөдөлмөрийн хуваарийг санаарай.
• Автоматжуулалтын тухайд хүмүүс алдаа гаргадаг.
• Заримдаа автоматжуулахад залхуу байдаг, учир нь бүх зүйл ийм байдлаар ажилладаг. Яагаад өөр зүйлийг сайжруулах вэ, яагаад энэ бүх тасралтгүй интеграци гэж?

Гэхдээ надад статистик байна: угсралтын 20% -д алдаа гардаг. Энэ нь манай хөгжүүлэгчид код муу бичдэгтэй холбоотой биш юм. Учир нь хөгжүүлэгчид ямар нэгэн алдаа гаргавал хөгжүүлэлтэд орохгүй, автомат шалгалтанд баригдана гэдэгт итгэлтэй байдаг. Үүний дагуу хөгжүүлэгчид ямар нэг зүйлийг орон нутагт ажиллуулж, туршихын оронд код бичих, сонирхолтой зүйл бичихэд илүү их цаг зарцуулах боломжтой.

Тасралтгүй интеграцийн дадлага хийх. Гэхдээ дунд зэрэг.

Дашрамд хэлэхэд, Николай Нестеров өөрөө гайхалтай илтгэл тавьдаг төдийгүй хөтөлбөрийн хорооны гишүүн юм. AppsConf мөн бусдад утга учиртай илтгэл бэлтгэхэд тусална. Дараагийн хурлын хөтөлбөрийн бүрэн бүтэн байдал, ашиг тусыг дараахь сэдвүүдээр үнэлж болно хуваарь. Дэлгэрэнгүй мэдээллийг 22-р сарын 23-XNUMX-ны хооронд Infospace дээр ирээрэй.

Эх сурвалж: www.habr.com