Налаштування CI/CD для мобільних застосунків (iOS/Android)

CI/CD мобільних застосунків: де ламається випуск

Поки реліз мобільного застосунку збирається на машині одного інженера, випуск тримається на його оточенні. Версії залежностей, змінні середовища, сертифікати й профілі підпису живуть локально — на іншому комп’ютері та сама гілка коду збирається інакше або не збирається взагалі. Відтворюваність збірки в такій схемі існує рівно до першої відпустки або зміни робочої машини.

Помилки підпису збірки — найдорожче місце. Ключ підпису лежить у зв’язці ключів розробника, термін дії сертифіката ніхто не відстежує, профіль прив’язаний до конкретного ідентифікатора застосунку та типу розповсюдження.

Загублений ключ або прострочений сертифікат не відновлюється з пам’яті: доводиться заново випускати сертифікати й перезбирати вже протестований реліз.

Ручна збірка релізу розтягує випуск: збірка, підпис, завантаження в магазин і роздача тестових версій — окремі кроки, кожен запускає людина.

Довгий випуск застосунку означає, що зворотний зв’язок від тестувальників надходить через дні, а термінове виправлення потребує тих самих ручних операцій, що й плановий реліз.

CI/CD мобільних застосунків закриває саме ці точки: конфігурація та ключі виносяться в кероване сховище, збірка запускається в чистому середовищі за кожною зміною в коді, а тестова версія вирушає команді автоматично. Нижче — як це влаштовано на практиці.

Що змінюється після переведення збірок на конвеєр

Поки збірка живе на машині розробника, час від правки до перевірюваного артефакту залежить від того, у кого саме вона запускається: в одного прогрітий локальний кеш, налаштовані профілі підпису, збігаються залежності — в іншого той самий код падає.

Конвеєр прибирає цю лотерею: збірка йде в незмінному середовищі, залежності кешуються, незалежні кроки розпаралелюються, і релізний цикл замість годин укладається в десятки хвилин.

Скрипти автоматизації на кшталт Fastlane переводять підпис, збірку та вивантаження артефактів у версіонований опис — процес перестає триматися на людині, яка «знає, як треба».

Коли випуск займає не півдня, а пів години, команда переходить з місячних релізів на тижневі, а виправлення доїжджає до користувачів у день виявлення, а не в наступному циклі.

Автоматична перевірка коду вмикається тим самим запуском: статичний аналіз, лінтери, модульні та інтерфейсні тести на реальних пристроях, контроль розміру збірки.

Збірка з червоним статусом фізично не доходить до тестувальників — дефект ловиться на коміті, коли ціна правки — один рядок, а не термінове виправлення з прискореним рев’ю магазину.

Стабільність збірки стає вимірюваною: частка успішних запусків, час до зеленого статусу, кількість повторних прогонів через нестабільні тести.

Далі — раннє виявлення дефектів за класами: регресії підпису, падіння на старті, витоки пам’яті, просідання відмальовування на слабких пристроях. Кожен такий клас закривається до релізу, і в стор іде версія, яку не потрібно наздоганяти патчами.

Варіанти збірки мобільних релізів: хмара, власні агенти, гібрид

Вибір схеми збірки визначають два фактори: де фізично лежать ключі підпису та наскільки передбачувана черга збірок. Хмарна ферма дає готові машини під обидві платформи й не потребує чергування інженера, але складальні секрети йдуть на чужий бік.

Власні агенти тримають ключі всередині периметра й кешують залежності між запусками, зате парк машин потрібно оновлювати й масштабувати самостійно.

Гібридний контур розділяє завдання: тести та статичні перевірки йдуть у хмарі, а фінальна збірка й підпис — на ізольованому агенті без зовнішнього доступу. Так ізоляція підпису стає властивістю мережі, а не обіцянкою: ключ не покидає контур на жодному кроці.

Практичний критерій простий: ключ не можна винести за периметр — гібрид, релізи рідкісні й команда невелика — хмара, перевірок багато й вони важкі — власні агенти із спільним кешем.

Обсяг підтримки контуру зростає з кількістю середовищ, а не проєктів, тому змішану схему вводять одразу разом із регламентом доступу до складальних секретів.

Етапи впровадження: від аудиту збірок до передачі регламентів

Збірка мобільного застосунку — це не один крок, а ланцюжок: залежності, підпис, тести, відправлення в канали тестування й у магазини. Якщо хоч на одній ланці процес тримається на людині, реліз стає подією з ручною підготовкою, а не рутинною операцією. Тому роботи йдуть послідовно, від інвентаризації до передачі документів.

1. Аудит збірки й доступів. Дивимося, де і на якій машині збирається застосунок, які сертифікати й профілі використовуються, у кого зберігаються ключі та облікові записи магазинів.

   Вимірюємо поточний час від коміту до збірки, яку можна поставити на тестовий пристрій, — це точка відліку для перевірки результату.

2. Проєктування схеми складального контуру. Визначаємо, які сценарії потрібні команді: збірка на кожен коміт, регулярні збірки з тестами, релізні збірки за тегом. Фіксуємо, де живуть артефакти, як розділяються середовища, хто і на що має право, як зберігаються секрети підпису.

3. Налаштування складальних сценаріїв. Налаштовуємо збірку й тести, кеш залежностей, нумерацію версій, автоматичне підписування та формування файлів, готових до встановлення. Окремо перевіряємо, що підпис не ламається при зміні середовища й що збірка відтворювана з чистого стану.

4. Автоматизація постачання. Прив’язуємо публікацію в канали тестування та відправлення збірок у магазини до сценаріїв, повідомлення про результат — до робочих каналів команди. З’являється можливість викотити версію без ручних кроків і так само швидко відкотитися на попередню.

5. Перевірка на реальному випуску. Прогоняємо новий контур на живому релізі: від першої збірки до появи версії в тестувальників і в магазині. Дивимося час етапів, розбираємо збої, прибираємо ручні підпорки, що залишилися після перенесення.

6. Передача регламентів і навчання. Віддаємо команді документацію за сценаріями, інструкції з доступів, сертифікатів і відновлення збірки, проводимо розбір із розробниками та тими, хто випускає. Далі релізи йдуть за описаним процесом без нашої участі.

Складальний контур, ключі підпису та регламенти випуску

Передаємо не «скрипт, який збирає застосунок», а комплект налаштувань і документів, за яким ваша команда випускає релізи сама. Усе лежить у вашому репозиторії та сховищі секретів — новий інженер проходить шлях від зміни коду до публікації без листування з нами.

• Конфігурація збірки під iOS і Android: кроки, залежності, змінні середовищ. Збірка відтворюється однією командою на чистій машині.
• Схема складального контуру: де живуть агенти, як кешуються залежності, що запускається на кожну зміну гілки, а що — лише на релізний тег.
• Зберігання ключів підпису: закриті ключі та сертифікати розміщені в захищеному сховищі, доступ виданий за ролями, до репозиторію й артефактів збірки вони не потрапляють.
• Політики доступу до середовища: зафіксовано, хто запускає збірки, хто публікує в магазини застосунків, хто бачить секрети й хто їх ротує.
• Регламент випуску: нумерація версій, порядок підвищення номера збірки, чек-лист перед публікацією та список підтверджень, без яких реліз не виходить.
• Інструкція з відкату: як повернути попередню збірку, зупинити поетапне розгортання й відкликати випуск із магазину.
• Карта супроводу: точки розширення контуру, відомі обмеження, контакти й розклад планових оновлень.

Регламенти описані мовою процесів, а не конкретного інструмента: змінити збирач або середовище можна, не переписуючи правила. Під час передачі проходимо кожен пункт разом із вашим інженером і відповідаємо на запитання по ходу.

Як випуск перестав залежати від одного інженера

До змін випуск мобільного застосунку тримався на одному інженері: він єдиний знав порядок кроків — зібрати збірку під потрібну конфігурацію, підписати, відправити на розповсюдження.

Реліз займав півтора дня, частка успішних збірок трималася близько 55%, а перед кожним випуском вручну виконувалося понад тридцять операцій. Відпустка або лікарняний цієї людини зупиняли випуск повністю.

Що змінили

Ми перенесли збірку в декларативний конвеєр усередині репозиторію: конфігурації середовищ описані кодом, ключі підпису лежать у захищеному сховищі й підставляються на етапі збірки через fastlane, залежності кешуються між запусками.

Один і той самий набір кроків виконується для налагоджувальної та релізної збірки — різниця лише в профілі конфігурації. Ручним залишилося підтвердження відправлення в магазин застосунків.

Випуск укладається в 40 хвилин замість півтора дня, частка успішних збірок зросла до 92%, ручних операцій стало чотири.

Окремо зник клас відмов через незбіг середовищ: збірка, що пройшла перевірку, більше не ламається на боці розповсюджувача через іншу версію інструментів або відсутній сертифікат. Відкат до попереднього релізу — перезапуск конвеєра на потрібній мітці.

Знання перестали жити в голові однієї людини: порядок випуску описаний у репозиторії та короткому регламенті, новий інженер проводить перший реліз самостійно на другому тижні.

Стійкість випуску більше не залежить від того, хто на зв’язку: конвеєр відтворюваний і запускається з інтерфейсу, без доступу до чужої робочої машини.

Чим складальний конвеєр відрізняється від автотестів на пристроях

Це два різних шари, і змішувати їх в одному визначенні не варто. Складальний конвеєр відповідає за те, щоб із коміту вийшов підписаний артефакт: розв’язання залежностей, компіляція, підпис релізної конфігурації, проставляння номера збірки та викладка у сховище.

Автотести на пристроях починаються там, де артефакт уже зібрано, — їхнє завдання перевірити поведінку застосунку на конкретній платформі.

Усередині складального конвеєра важливий не факт запуску, а передбачуваність: однаковий результат при повторній збірці того самого коміту, кеш залежностей, окремі профілі підпису для внутрішніх і релізних збірок, зрозуміла нумерація версій.

Тоді час від відправлення коду до готового артефакту вимірюється хвилинами, а не листуванням «у кого збірка зібралася».

Автотести на пристроях — це окремий шар зі своєю ціною. Емулятори та реальні пристрої ловлять різне: емулятор швидкий і дешевий у паралельному прогоні, але не відтворює камеру, датчики, біометрію та особливості вендорних оболонок.

Тому критичні сценарії йдуть на ферму пристроїв — набір реальних моделей, де перевіряються встановлення, оновлення поверх попередньої версії, робота у фоні та поведінка за слабкої мережі.

Розділення шарів перевірки виглядає так: на кожен коміт — збірка та швидкі перевірки на емуляторах, на релізну гілку й перед публікацією — повний прогін на фермі пристроїв. Так дорогий машинний час не витрачається на те, що ловиться за секунди. Що потрібно саме вам, залежить від кількості платформ і моделей у підтримці.

Часті сумніви: підписи, ключі та тестові збірки

Підпис збірки, ключі та доступи до магазинів застосунків — три місця, де автоматизація зазвичай стопориться: без них складальний конвеєр або не проходить валідацію, або залишається ручною операцією однієї людини. Нижче — запитання, які ставлять до старту, і те, як ми їх закриваємо.

Чи обов’язково тримати власні сервери?

Ні. Збірка йде на керованих складальних агентах, які масштабуються під пікове навантаження перед релізом, — власне залізо не потрібне. Якщо внутрішня політика вимагає ізольованого контуру, розгортаємо збірку у вашій інфраструктурі з тими самими кроками.

У нас усе збирається вручну — чи доведеться переробляти процес?

Спочатку описуємо те, що вже працює, і переносимо кроки по одному, не зупиняючи випуск. Паралельно вмикаємо автоматизацію тестових збірок і перевірку критичних дефектів, а ручний випуск залишається як відкат, поки новий процес не підтвердить стабільність на кількох релізах.

Чи потрібна своя ферма пристроїв?

Для базового набору — встановлення, оновлення, вхід, оплата, повідомлення — вистачає емуляторів і хмарних пристроїв. Своя ферма виправдана, якщо є вимоги до конкретних моделей, старих версій системи або роботи в закритій мережі.

Обговоримо задачу: що уточнимо за вашою схемою випуску

Щоб повернутися з оцінкою та планом робіт за вашим контуром збірки й випуску, а не із загальними міркуваннями, нам потрібен короткий набір вхідних даних.

Готувати нічого заздалегідь не потрібно — достатньо того, що вже є в репозиторії, на складальних машинах і в кабінетах магазинів застосунків. За цими даними ми опишемо цільову схему, оцінимо обсяг робіт і покажемо, де в поточному процесі втрачається час.

• Схема розгалуження та релізний цикл: як часто виходять збірки, хто ставить тег, що вважається релізною гілкою, чи є окремий контур для термінових виправлень.
• Складальні середовища: де проєкт збирається зараз — на робочих машинах інженерів чи на виділених агентах, чи потрібні збірки під обидві платформи паралельно.
• Підпис і ключі: як зберігаються ключі підпису та профілі пристроїв, хто має до них доступ, як передаються в складальне середовище. Це найчастіша точка відмови при автоматизації, і її розбираємо насамперед.
• Канали доставки: тестові збірки для внутрішньої команди та зовнішніх тестувальників, публікація в магазини, поетапне розгортання й можливість відкотити випущену версію.
• Середовища та параметри: скільки середовищ, чим вони відрізняються, як зараз задаються адреси сервісів і ключі сторонніх інтеграцій, що вже винесено в змінні.
• Ручні кроки: що саме досі робиться руками — версіонування, складання нотаток до випуску, склеювання артефактів, відправлення на перевірку.

Окремо назвіть вимоги, які з’явилися з практики: термін зберігання артефактів, обмеження щодо доступів, обов’язкові перевірки перед викочуванням. Опишіть задачу та надішліть посилання на репозиторій — повернемося з оцінкою та планом робіт за вашим контуром збірки й випуску.