CodeMagic налаштування: де ламається збірка мобільного застосунку
Ручна збірка мобільного застосунку майже завжди ламається в одному й тому самому місці: локальна машина розробника та складальний сервер розходяться за версіями залежностей, змінними середовища й налаштуваннями підпису.
Поки застосунок збирає одна людина на своєму ноутбуці, це непомітно, але варто підключити другого розробника або випустити реліз у п'ятницю ввечері — і збірка мобільного застосунку падає на кроці, який учора проходив без змін.
CodeMagic налаштування якраз прибирає цю лотерею: збірка переноситься у відтворюване середовище, де кожен крок описаний конфігурацією, а не пам'яттю конкретного інженера.
Найдорожче обходяться не завалені збірки, а тихі збої. Ключі підпису зберігаються в чиємусь профілі, сертифікат спливає в момент релізу, зібраний артефакт залишається на локальному диску й не доїжджає до магазину застосунків.
Автоматизація релізів закриває це: підпис підставляється із захищеного сховища, версія й номер збірки піднімаються за правилом, готовий пакет вирушає в тестовий контур і в магазини однією командою.
CI/CD для мобільних застосунків перетворює випуск із події на півдня на регулярну дію, яка не залежить від того, хто сьогодні на зв'язку.
Окрема стаття витрат — затримки викату. Поки збірка йде вручну, між готовим кодом і оновленням у користувача минає доба, а то й тиждень: потрібно знайти вікно, зібрати, перевірити, завантажити.
За потоку релізів щотижня це накопичується у відставання, через яке виправлення критичних помилок приїжджають до користувачів із запізненням. Конвеєр скорочує шлях від коміту до збірки в тестовому контурі до хвилин, а не днів.
Нижче розбираємо, як це закривається: які кроки конвеєра обов'язкові, де найчастіше помиляються під час перенесення підпису й як вибудувати процес так, щоб реліз не залежав від однієї людини.
Що дає налаштування CodeMagic: конвеєр збірки та релізу
Налаштування CodeMagic перетворює ручну збірку на передбачуваний конвеєр: інженер надсилає зміни у гілку, а далі збірка, підпис і викладка відбуваються без його участі.
Автоматизація підпису прибирає найчастіше джерело зривів релізу — розсинхронізацію сертифікатів і профілів між машинами розробників. Замість «у мене збирається, у тебе ні» команда отримує відтворюваний результат на кожному запуску.
Що змінюється в цифрах
Час збірки перестає залежати від машини розробника: конвеєр виконується на виділених агентах, кеш залежностей перевикористовується між запусками, тому повторна збірка йде помітно швидше за першу.
Частка успішних релізів зростає завдяки тому, що перевірки та підпис виконуються в одному й тому самому порядку щоразу — людський фактор із процесу зникає.
Режими збірки під задачу
Налагоджувальні збірки йдуть за кожною зміною в гілці та роздаються тестувальникам автоматично — не потрібно вручну збирати й передавати файл. Релізні збірки запускаються за тегом або вручну, з підписом і публікацією в стор.
Розділення режимів прибирає клас відмов, коли в продакшн випадково потрапляє збірка з налагоджувальною конфігурацією.
Порівняння підходів CI/CD
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| CodeMagic | Потрібен готовий конвеєр під мобільні платформи без власної інфраструктури | Менше гнучкості в нестандартних кроках |
| Власний раннер | Складні вимоги до оточення та приватності | Потрібна підтримка серверів і оновлень |
| Локальна збірка | Разові задачі, прототипи | Не масштабується, ручний підпис |
Ми налаштовуємо конвеєр під ваш процес: гілки, оточення, правила публікації. CodeMagic закриває збірку та підпис з коробки, а нестандартні кроки дописуємо самі.
Етапи впровадження: від аудиту репозиторію до передачі конвеєра
Впровадження CI/CD починається не з налаштування CodeMagic, а з аудиту репозиторію: дивимося розгалуження, наявність lock-файлів, ручні кроки в поточній збірці, роботу з секретами та підписами.
На цьому етапі видно, де конвеєр зламається на першому ж релізі — зазвичай це розбіжності в залежностях між машинами розробників і відсутність відтворюваної збірки. Далі фіксуємо схему: які гілки запускають збірку, де публікується артефакт, як розділяються середовища.
- Аудит репозиторію та поточного релізного циклу. Розбираємо історію гілок, скрипти збірки, ручні операції при викладці в магазини, точки відмови. Результат — карта процесів із вузькими місцями.
- Проєктування схеми конвеєра. Визначаємо тригери (push, pull request, тег), набір кроків, кешування залежностей і правила версіонування збірок. Схема узгоджується до початку робіт.
- Налаштування CodeMagic під проєкт. Підключаємо репозиторій, описуємо workflow у конфігураційному файлі, налаштовуємо середовища, змінні та сховище секретів — ключі підпису не потрапляють у код.
- Автоматизація збірки та тестів. Збірка, статичний аналіз, модульні та UI-тести запускаються на кожен коміт; падіння перевірок блокує злиття.
- Публікація артефактів і доставка. Збірки йдуть у внутрішнє тестування та в магазини за тегами, з автоматичним підвищенням номера версії та зрозумілою історією релізів.
- Перевірка на реальних релізах. Проганяємо кілька циклів, включно з відкатом і випуском виправлення, заміряємо час збірки та відновлення після збою.
- Передача конвеєра та документації. Команда замовника отримує опис схеми, інструкції щодо правок, доступи та порядок дій при інциденті.
Кожен етап закінчується артефактом: карта процесів, схема конвеєра, робочий конфіг, звіт за прогонами, документація. Такий порядок прибирає головний ризик — конвеєр, який працює лише в одного інженера і ламається при першій зміні в проєкті.
Чим відрізняється хмарна збірка від локальної і коли що вибирати
Локальна збірка виконується на машині розробника або на виділеному сервері всередині вашого контуру: код, ключі підпису та артефакти не залишають периметр.
Хмарна збірка переносить той самий процес на керовані потужності провайдера — вихідні коди забираються з репозиторію, залежності підтягуються з кешу, готовий артефакт повертається у сховище або магазин.
Різниця не в тому, де компілюється код, а в тому, хто відповідає за відтворюваність оточення та його доступність у момент релізу.
За швидкістю виграє хмара, але не завжди. Холодний запуск програє прогрітій локальній машині, зате паралельні задачі та кеш залежностей дають стабільні 5-10 хвилин на збірку проти 20-40 хвилин на перевантаженому ноутбуці.
Локальна збірка прискорюється тільки разом із залізом, а хмарна масштабується під навантаження: десять релізів на день і один реліз на тиждень коштують однаково за часом очікування.
Відтворюваність — головний аргумент проти локальної збірки. Поки оточення живе на машині інженера, «у мене збирається, у тебе ні» залишається нормою: версії інструментів, змінні середовища та сертифікати розходяться.
Хмарна збірка описується конфігураційним файлом у репозиторії, тому однаковий результат відтворюється на будь-якій гілці та в будь-якого члена команди.
Налаштування CodeMagic якраз будується навколо такого опису — конфігурація версіонується разом із кодом, а не зберігається в чиїйсь пам'яті.
Вимоги до інфраструктури розходяться ще сильніше. Локальний підхід вимагає тримати сервер збірки, стежити за його оновленнями, чистити диски та оновлювати сертифікати підпису вручну.
Хмара знімає цю роботу, але додає свої обмеження: ліміти на час задачі, доступність зовнішніх сервісів і правила зберігання ключів. Для проєктів із жорсткими вимогами до ізоляції коду локальний контур залишається безальтернативним.
Вартість володіння рахують не за тарифом, а за сукупністю: години інженерів на підтримку сервера, простої в момент релізу, час на розбір розходжень оточень.
Локальна збірка здається дешевшою, поки сервер один і команда невелика; при зростанні числа платформ і частоти релізів підтримка з'їдає більше, ніж керована збірка.
Гібридний варіант — хмарна збірка для регулярних релізів і локальна для налагодження та роботи із закритими модулями — закриває обидві задачі без компромісів.
Кейс: як автоматизація збірки скоротила релізний цикл утричі
До впровадження автоматизації реліз тривав 9–12 днів: збірка виконувалася на двох інженерних машинах, підпис і завантаження в магазини — вручну, а регрес запускався лише після того, як збірка «дістанеться» до тестувальників.
Кожен другий реліз випускався з ручними правками конфігурації, і ніхто не міг сказати, з якого коміту зібрано конкретний артефакт.
Що змінили
Перевели збірку в керований конвеєр: тригер на тег і на злиття в основну гілку, кеш залежностей між запусками, паралельні кроки для iOS і Android. Підпис винесли в захищене сховище — ключі більше не лежать на машинах розробників, а збірка отримує їх лише на етапі підпису.
Додали обов'язкові перевірки перед публікацією: статичний аналіз, прогін автотестів і збірку підписаного артефакту в одному прогоні. Якщо хоча б один крок падає — реліз не виходить у магазини, а команда одразу бачить, на якому саме етапі.
Метрики до і після
| Показник | До | Після |
|---|---|---|
| Повний цикл релізу | 9–12 днів | 3–4 дні |
| Збірка підписаного артефакту | 40–60 хвилин вручну | 12–15 хвилин автоматично |
| Частка релізів без ручних правок | ~50% | 95%+ |
| Час на відкат до попередньої версії | години | хвилини |
Окремо закрили відтворюваність: кожна збірка прив'язана до коміту і зберігає артефакт, тому відкат — це перемикання на попередній перевірений образ, а не повторна ручна збірка.
Релізний цикл скоротився утричі, а частка успішних релізів зросла завдяки тому, що перевірки перестали бути опціональними.
Конвеєр побудовано на CodeMagic: конфігурація описана декларативно і лежить у репозиторії поруч із кодом, тому зміни проходять рев'ю як звичайні правки.
Сумніви перед впровадженням: сумісність, міграція, відкат
Перед стартом замовники зазвичай ставлять три запитання: чи не зламає новий конвеєр поточні збірки, як перенести проєкт без простою і що робити, якщо реліз у стор пішов з помилкою.
Відповідаємо по суті: CodeMagic налаштування ведеться на окремій гілці конфігурації, тому чинний процес збірки продовжує працювати, поки новий не пройде перевірку на тестовому каналі.
Міграція збірки йде по кроках — спочатку переноситься один продукт, звіряються артефакти й підписи, і тільки потім на новий конвеєр переводяться решта.
Що якщо потрібен буде відкат релізу?
Відкат релізу закладається заздалегідь: кожна збірка отримує незмінний номер і зберігається в реєстрі артефактів, а правило зберігання тримає останні збірки на кожен канал.
Повернути попередню версію в стор або на тестовий контур — це перемикання вказівника на потрібний артефакт, а не повторна збірка з нуля. Окремо описуємо процедуру відкликання, якщо проблема знайшлася вже після публікації.
Що якщо у нас нестандартний стек? Сумісність CI/CD перевіряємо до початку робіт: дивимося, як проєкт збирається локально, які є нативні залежності й як підписуються збірки. Якщо щось не підтримується з коробки, це фіксується в плані заздалегідь, а не з'ясовується в день релізу.
Що якщо команда не працювала з таким конвеєром? Передаємо не лише робоче налаштування, а й документацію по конвеєру — щоб розробник міг сам змінити крок збірки, не розбираючи чужу конфігурацію.
На руки замовник отримує:
- конфігурації збірки й підпису по кожному каналу — тест, бета, продакшн;
- схему конвеєра з точками розгалуження й умовами запуску;
- політики зберігання артефактів і правила відкату релізу;
- налаштовані сповіщення про падіння збірки й публікації;
- документацію по конвеєру з прикладами типових правок;
- інструкцію з додавання нових продуктів і середовищ.
Опишіть вашу задачу — повернемося з оцінкою та планом перенесення збірки на новий конвеєр.
Терміни впровадження: етапи та орієнтовна тривалість
Впровадження збірки та доставки мобільного застосунку розкладається на етапи з передбачуваною тривалістю. Нижче — орієнтовний план робіт: терміни залежать від кількості платформ, числа середовищ і того, наскільки занедбані поточні процеси підпису та релізу.
Етапи йдуть не строго послідовно: підпис і тести часто налаштовуються паралельно з базовою збіркою, тому загальний термін впровадження зазвичай коротший за суму рядків.
Для одного застосунку на одній платформі реально вкластися в два тижні; мультиплатформенний продукт із кількома середовищами займає помітно більше.
Окремо варто закласти час на стабілізацію: перші прогони викривають нестабільні тести, застарілі залежності та розбіжності між локальною збіркою і серверною. Цей етап не можна пропустити — саме він визначає, чи буде конвеєр викликати довіру в команди.
CodeMagic
