С нарастващия мобилен екип и седмичните пускания на нови версии е от съществено значение да разполагаме с надежден CI канал. Трябва да можем да създаваме и тестваме нашите приложения и да ги пускаме в App Store и Google Play Store. Поддържаме и вътрешни предварителни версии, за да тестваме най-новите функции.
Научете как използваме ClickUp, Fastlane и GitHub Actions за автоматизиране на непрекъснатата интеграция (CI) и непрекъснатата доставка (CD).
Животът на един бъг 🐜
Нека започнем с кратък преглед на процеса ни за управление и отстраняване на бъгове.
- Докладва се бъг (или заявка за функция) и се създава задача в ClickUp.
- Задачата се възлага на разработчик и се фиксира в PR спрямо стадийния клон.
- CI изпълнява всички тестове, създава приложението, разгръща уеб преглед и качва всичко в задачата на ClickUp.
- Нашият QA екип проверява поправката и ако тя е добра, задачата се маркира като изпълнена.
- PR се обединява автоматично в стадията на подготовка.
- Сценичният клон се изгражда и разгръща в нашата вътрешна TestFlight.
- Всяка сряда се създава, изгражда и тества клон за пускане на версии.
- В петък създаваме версия в GitHub, а CI я разпространява в App Store и Play Store.
Задачата в ClickUp съдържа всичко, свързано с бъга. Използваме персонализирани статуси като „В процес“ или „Преглед на кода“, за да следим бъга. Работните процеси на CI променят статуса автоматично. Персонализираните полета съдържат допълнителна информация като кой е докладвал бъга, кой работи по него, кога ще бъде пуснат и т.н.
PR работни процеси 📜
Първите две стъпки, описани по-горе, не са свързани с CI, но третата е интересна...
Нашият работен процес по разработката се изпълнява за всеки PR. Той проверява линтите, форматирането и изпълнява всички тестове, преди да започне да изгражда артефактите за Android и iOS.
Когато изграждането е успешно, CI ще публикува съобщение в свързаната задача. Инженерите по QA могат да отидат в PR, да изтеглят артефактите от изграждането или да използват уеб прегледа.
Автоматизирано CI съобщение, публикувано в свързаната задача в ClickUp след успешно изграждане
Настройка на Flutter на CI runner 🛠
Използваме добре известната GitHub action subosito/flutter-action, за да настроим Flutter на CI. По подразбиране тя ще инсталира най-новата стабилна версия на Flutter. За да избегнете прекъсване на CI работните процеси при излизането на нова версия на Flutter, трябва да зададете версията ръчно.
Ако имате няколко работни потока, е по-добре да съхранявате версията на Flutter във файл. Ние използваме FLUTTER_VERSION в кореновата директория на хранилището.
Друго лесно решение е да съхраните версията на Flutter като GitHub secret и да я достъпите чрез {{ secrets. FLUTER_VERSION }}.
Преглед в уеб 🕸
Благодарение на възможността на Flutter да работи в уеб, можем да създадем напълно функционален уеб преглед на pull заявките. С помощта на пакета device_preview размерът и настройките на устройството могат да бъдат регулирани.
Прегледът се оказа много полезен и се използва не само от нашия QA екип. Дизайнерите и продуктовите мениджъри също го харесват, защото им позволява бързо да тестват нови функции.
чрез Flutter
Как да създадете уеб преглед 🐶
За да започнете, уверете се, че приложението ви е съвместимо с Flutter web – не всички API са поддържани.
В нашето приложение, например, трябваше да деактивираме push уведомленията и уеб сокетите.
Този пример за работен процес създава уеб преглед на вашето Flutter приложение и го качва в S3 bucket. Използваме променлива на средата ENABLE_DEVICE_PREVIEW, за да деактивираме device_preview в производството.
Стъпката Fix base href е необходима, защото прегледът няма да бъде в корена на букета.
И малко код за условно активиране на device_preview.
Променливите на средата са мощен инструмент и позволяват на алгоритъма за разклащане на дърво на Flutter да премахне дебъг кода за версиите за пускане.
Fastlane 💨
Fastlane значително опростява създаването, подписването и внедряването на Flutter приложения. Той управлява нашите сертификати, профили за предоставяне и други настройки. Използваме GitHub secrets за сигурно съхранение на пароли и токени.
Полезни действия на Fastlane:
- fastlane match за създаване и съхранение на iOS ключове и профили в GitHub хранилище
- build_app за създаване на приложения за iOS и Android
- upload_to_testflight и доставка за разгръщане на iOS версии
- upload_to_play_store за разгръщане на Android версии
Примерна версия за iOS разработчици 🍏
Не забравяйте setup_ci, той ще ви спести странни грешки 👾. Научете повече за Fastlane за Flutter приложения.
Подписване на Android 🔒
Най-лесният начин да подпишете версиите за Android по сигурен начин е да съхраните токените като GitHub тайни и да използвате променливи на средата и временен ключ. jks, създаден от CI:
Съхраняваме ключа jks като base64 кодиран низ в Github Secrets и го декодираме в работния процес:
Работен процес за пускане и производство 🚀
Работният процес преди пускането на продукта се изпълнява за клонове, които започват с release/v. Той премахва всички отстранявания на грешки и вътрешен код, за да се гарантира, че тестваме същия код, който ще бъде пуснат.
Освен това, работният процес преди пускането на продукта публикува в различни Slack канали, за да уведоми екипите за качество и маркетинг за новото пускане на продукта, използвайки входящи уебхукове.
След като всичко е тествано задълбочено, създаваме версия в GitHub, която задейства производствения работен процес. Тя създава и подписва приложението с производствени сертификати и го изпраща в App Store.
Още трикове за вашата CI 🦾
Ако използвате тригера за push за GitHub Actions, вероятно ще срещнете проблеми, ако има няколко push-а към един и същи клон в бърза последователност. Ще се стартират повече от един инстанции на работния процес, което ще отнеме минути за изграждане или ще доведе до други проблеми.
- Препоръчваме да използвате действието „Отмяна на работния процес“, за да отмените всички предишни инстанции на работния процес.
- Ако търсите лесно и поддържаемо решение за генериране на последователни номера на сборки, опитайте Build Number Generator. Можете да използвате и GITHUB_RUN_ID, но той не може да бъде персонализиран.
- Разгледайте приложението ClickUp GitHub, за да видите клонове, потвърждения и статус на GitHub директно във вашите задачи в ClickUp. Използвайте ClickUp Automations или публичния API на ClickUp за разширени автоматизации.
Резюме 🍩
Изграждането на CI е забавен процес. Лесно е да започнете и можете да го развивате постепенно. Нашата CI се основава на една от основните ценности на ClickUp: Напредък към съвършенство. Непрекъснато работим върху подобренията на CI за нашите екипи по QA и инженеринг.
Комбинацията от ClickUp, GitHub Actions и Fastlane е много мощна и позволява изграждането на гъвкав и напълно автоматизиран CI/CD пайплайн за по-малко от час. Опитайте го!
Имаме много интересни теми в процес на подготовка, така че продължавайте да следите блога на ClickUp Engineering! 🦄