Ден на издаване в разработката на приложения: същност, етапи и подготовка
Ден на издаване (release day) — планирана дата за пускане на нова версия на мобилно приложение, включваща подготовка на билд, ревю от магазина, staged rollout и мониторинг. За iOS приложения процесът започва с качване на билд в App Store Connect 24-48 часа преди планираната дата на издаване поради задължителното ревю на Apple. За Android — изграждане и качване в Google Play Console, където процесът на ревю обикновено отнема 1-4 часа. Според Apple Developer Guidelines (2025), 90% от билдовете преминават ревю за 24 часа. Staged rollout позволява минимизиране на въздействието при откриване на грешки след публикуване.
Основни точки
- Release day — комплекс от мерки от изграждане на билд до мониторинг след rollout
- Staged rollout — постепенно разпространение: 1%, 10%, 50%, 100%
- Smoke testing — окончателна проверка на билда преди изпращане в магазина
- Rollback plan — предварително подготвен сценарий за връщане при критични грешки
- Release retrospective — анализ на процеса след завършване на rollout на 100%
Какво е ден на издаване и как да се подготвим
Ден на издаване — не е просто моментът на натискане на бутона Publish. Това е координиран процес, в който участват разработчици, QA, девопси, продукт мениджъри и понякога поддръжка. Подготовката започва 2-3 седмици преди деня на издаване: съгласуване на обхвата, code freeze, регресионно тестване, подготовка на release notes и маркетингови материали. Колкото по-щателна е подготовката, толкова по-спокойно преминава самият ден на издаване.
Контролният списък за подготовка за деня на издаване включва: финален QA прогон (regression + smoke suite) на билда за издаване; проверка на метаданните в магазините (име, описание, екранни снимки, keywords); съгласуване на процента staged rollout с продукт мениджъра; подготовка на план за rollback (кой маркер да бъде предеплойнат, колко време ще отнеме); уведомяване на екипа и свързаните услуги за предстоящото издаване. Release checklist трябва да бъде автоматизиран чрез CI/CD — например под формата на GitHub Actions workflow, който проверява всички точки преди създаване на маркера за издаване.
Важен елемент от подготовката — blackout период (период, в който деплойванията в продукция са забранени). Обикновено blackout се въвежда 48 часа преди деня на издаване и се премахва 24 часа след успешен rollout на 100%. Това предотвратява случайни деплойвания, които биха могли да нарушат издаването. Change freeze в периода на blackout се прилага за всички услуги, свързани с издаването.
Подготовка на билд: code freeze, маркиране и изграждане
24-48 часа преди деня на издаване се въвежда code freeze — пълно спиране на промените в кода. Разработчиците преминават към подготовка на документация и release notes. DevOps изгражда билда за издаване от фиксиран маркер (напр. v2.6.0-rc1). Билдът преминава пълен regression suite (автоматични + ръчни тестове). Ако бъдат открити критични грешки — те се поправят преди code freeze или издаването се отлага. Release candidate (RC) — билд, преминал QA и готов за изпращане до магазина.
Маркиране в Git: създава се анотиран маркер (git tag -a v2.6.0 -m "Release v2.6.0"). CI/CD pipeline изгражда AAB (Android App Bundle) за Google Play и IPA (iOS App Store Package) за Apple App Store. Към билда се прилага: файл с контролни суми (SHA256), changelog и списък с известни проблеми (known issues). Reproducible builds — идеална практика, при която повторното изграждане от същия маркер дава бинарно идентичен резултат.
bash
# Пайплайн за издаване — създаване на маркер и изграждане
# Предполага, че code freeze вече е активен
# Създайте клон за издаване от develop
git checkout develop
git pull origin develop
git checkout -b release/v2.6.0
git push origin release/v2.6.0
# Code freeze: правилата за защита на клона блокират нови PR
# Пуснете регресионния пакет в CI/CD
./gradlew clean testReleaseUnitTest connectedReleaseTest
# Създайте маркер за издаване след успешна QA
git tag -a v2.6.0 -m "Release v2.6.0: payment module, dark mode"
git push origin v2.6.0
# Изградете двоичния файл за издаване чрез CI/CD
# fastlane build_release произвежда AAB + универсален APK
fastlane build_releaseВажно: version bump (актуализиране на version code и version name) се прави преди code freeze. След code freeze версията не се променя. За Android: versionCode — монотонно нарастващо цяло число; versionName — семантична версия (2.6.0). За iOS: CFBundleVersion (build number) и CFBundleShortVersionString (семантична версия). Versioning трябва да бъде автоматизиран в gradle/xcconfig.
Качване в магазина и преминаване на ревю
За iOS: билдът се качва чрез Xcode, Transporter или fastlane в App Store Connect. След качване билдът преминава автоматична проверка на Apple (processing), след което се изпраща за ръчно ревю. Средно време за ревю — 24 часа, но може да варира от 1 час до 7 дни в зависимост от натоварването на рецензентите на Apple и изискванията за съответствие. Expedited review — заявка за ускорено ревю за критични корекции на грешки (достъпна не повече от веднъж месечно, не е гарантирана).
За Android: билдът се качва чрез Google Play Console. Google използва комбиниран подход: автоматично тестване (accessibility, malware, policy compliance) + селективно ръчно ревю. Средно време за ревю — 1-4 часа. Internal test track и Closed track позволяват финално тестване преди публикуване в Production track. Препоръчва се: 1-2 дни за Internal test → 1 ден за Closed beta → постепенен Production rollout.
И за двете платформи проверката на метаданните преди качване на билда е критично важна: име на приложението, описание (short + full), екранни снимки за всяко поддържано устройство (iPhone 6.5", 5.5", iPad, Android phone, tablet), keywords (iOS) или store listing experiments (Android). Грешка в метаданните може да забави ревюто с допълнителен ден. App metadata трябва да бъде локализирана на всички поддържани езици.
Staged rollout: как да разпространяваме изданието без риск
Staged rollout (gradual rollout, staged deployment) — стратегия, при която новата версия става достъпна за потребителите не веднага, а на етапи. Типична схема за зрял екип: 1% от потребителите (първите 2-4 часа) → 10% (24 часа) → 25% (24 часа) → 50% (24 часа) → 100%. Всеки етап включва мониторинг на метрики и проверка за липса на критични грешки. Staged rollout — основният инструмент за минимизиране на риска при издавания.
Google Play Console предоставя вграден staged rollout: можете да посочите процент потребители и да планирате постепенно увеличаване. За iOS App Store Connect няма такава вградена възможност — staged rollout се реализира чрез Phased Release (автоматично увеличаване на обхвата за 7 дни с възможност за пауза) или чрез server-side feature flags с географско разпределение. Phased release в App Store Connect дава възможност за Pause Release (паузиране на издаването) при откриване на проблеми.
Ключови метрики за преминаване към следващия етап: crash-free rate (≥99.9% за новото издание), ANR rate (Android, ≤0.1%), error rate на backend API (≤0.5% 5xx), потребителски оценки (не по-ниски от предишната версия), apdex score (≥0.94). Ако някоя метрика надхвърли прага — rollout се спира до изясняване на причините. Go/no-go gate на всеки етап — отговорност на release manager или на on-call инженер.
Мониторинг след издаване: на какво да обърнем внимание в първите часове
Първите 4 часа след издаване — най-критичното време. Екипът следи crash rate (Sentry, Firebase Crashlytics, App Center), error rate 5xx на backend, custom events (успешни плащания, влизания, регистрации), потребителски оценки в App Store и Google Play, споменавания в социалните медии (Twitter, Reddit). Таблото за мониторинг трябва да бъде подготвено предварително и достъпно на голям екран в офиса или в специален Slack канал. Release dashboard — единен прозорец за всички метрики на изданието.
Специално внимание — регресионни метрики: сравнение на crash rate с предишната версия за аналогичен период. Ако crash rate се е увеличил с повече от 0.1% — това е червен флаг, изискващ незабавен анализ. Също така е важно да се сравни медианната и p95 латентност на ключови API крайни точки: дори без сривове, забавяне на времето за отговор с 200ms може да сигнализира за проблем. Metric comparison (baseline vs current) се автоматизира в Datadog или Grafana.
Обратната връзка от потребители — не по-малко важна от числовите метрики. В първите часове след издаване потребителите активно оставят отзиви в магазините и пишат на поддръжката. Грешките, неуловени от тестовете, бързо изплуват в отзивите. Team lead или определеният QA инженер следи отзивите на всеки 30 минути в първите 4 часа и ги класифицира: false positive, known issue (вече в списъка с известни проблеми), new bug. New bugs P0/P1 — тригер за спиране на rollout.
Rollback: кога и как да върнем изданието назад
Rollback — връщане към предишната стабилна версия при откриване на критични проблеми. Решението за rollback се взема от release manager съвместно с tech lead, ако: crash-free rate на новото издание падне под 99%, бъде открито изтичане на данни, критична функционалност (плащания, оторизация) не работи за >5% от потребителите или магазинът (App Store Review) отхвърли билда след публикуване. Rollback trigger трябва да бъде определен преди издаването, така че решението да се взема на базата на факти, а не на емоции.
За Android: rollback в Google Play Console — спиране на staged rollout и превключване към предишната версия. Ако текущият билд вече е на 100% от потребителите — публикуване на предишната версия като ново издание. За iOS: чрез App Store Connect — Phased Release → Pause Release → пускане на нова версия с корекция (App Store не позволява връщане към предишна версия). iOS rollback е по-сложен: разработчикът трябва да изгради нов билд с revert commit-и и да премине отново през ревю.
След rollback екипът преминава в режим на инцидент: root cause analysis, hotfix или следващо издание с корекция, post-mortem. Rollback — не е провал, а стандартна процедура. Екипите, които никога не са правили rollback, вероятно не забелязват проблема, а не че пускат безгрешни издания. Rollback rate — един от DORA метриките: високоефективните екипи правят rollback при <10% от изданията и се възстановяват за <1 час.
Често задавани въпроси
Кой ден е най-подходящ за пускане на мобилно приложение?
Най-добрите дни — вторник, сряда или четвъртък. Понеделник — висок трафик от уикенда, петък — риск да влезем в уикенда с проблемно издание. Избягвайте петък: ако след деплойване се открие проблем, екипът ще го поправя през уикенда или ще чака до понеделник.
Какво да направим, ако App Store Review отхвърли билда?
Прочетете причината за отхвърляне в Resolution Center, поправете и качете отново билда. Чести причини: неработещи връзки, непопълнени полета, съдържание без абонамент (ако се изисква), остарели екранни снимки. App Review rejection забавя издаването с 24-48 часа, затова първото качване на билд трябва да бъде 3-5 дни преди планираната дата на издаване.
Какъв процент staged rollout е оптимален за начало?
За големи издания (major changes) — 1%. За patch издания — 5-10%. Първият етап трябва да бъде достатъчно малък, така че в случай на грешка въздействието да е минимално, но достатъчно голям, за да се получат статистически значими метрики. 1% за приложение с 10 милиона потребители — 100 хиляди души, достатъчно за откриване на критични проблеми.
Трябва ли да правим release party?
Release party (екипно празнуване) — опционално, но полезно за морала. По-добре да се проведе след успешен rollout на 100%, а не в момента на качване на билда. Release celebration може да се комбинира с release retrospective, за да се обсъди какво е минало добре и какво може да се подобри.
Кой носи отговорност за решението „издаване или отлагане”?
Отговорността е на release manager (обикновено senior engineer или tech lead). Решението се взема на базата на данни от release dashboard, а не на базата на краен срок. Release manager има правомощието да отложи издаването, ако метриките не преминат go/no-go gate.
Резюме
- Ден на издаване — координиран процес от code freeze до мониторинг след rollout
- Подготовка — release candidate, QA прогон, проверка на метаданни, план за rollback
- Staged rollout — 1% → 10% → 25% → 50% → 100% с go/no-go gate на всеки етап
- Мониторинг — crash-free rate, ANR, error rate 5xx, потребителски оценки в първите 4 часа
- Rollback — стандартна процедура при падане на crash-free rate под 99%
- Комуникация — уведомяване на екипа и заинтересованите страни преди и след издаване
- Release retrospective — анализ на процеса след завършване на rollout на 100%
Ще разработим мобилно приложение под ключ
IT Sectr създава iOS и Android приложения за стартъпи и бизнеси от 2017 г. Ще ви консултираме и ще предложим най-доброто решение.
Прочетете също