Ziua lansării în dezvoltarea aplicațiilor: esența, etapele și pregătirea
Ziua lansării (release day) — data planificată pentru lansarea unei noi versiuni a aplicației mobile, care include pregătirea build-ului, review-ul în magazin, staged rollout și monitorizare. Pentru aplicațiile iOS, procesul începe cu încărcarea build-ului în App Store Connect cu 24-48 de ore înainte de data planificată a lansării din cauza review-ului obligatoriu Apple. Pentru Android — construirea și încărcarea în Google Play Console, unde procesul de review durează de obicei 1-4 ore. Conform Apple Developer Guidelines (2025), 90% dintre build-uri trec de review în 24 de ore. Staged rollout permite minimizarea impactului în cazul depistării erorilor după publicare.
Principalele puncte
- Release day — ansamblu de măsuri de la construirea build-ului până la monitorizarea după rollout
- Staged rollout — implementare treptată: 1%, 10%, 50%, 100%
- Smoke testing — verificarea finală a build-ului înainte de trimiterea în magazin
- Rollback plan — scenariu de revenire pregătit în avans pentru erori critice
- Release retrospective — analiza procesului după finalizarea rollout la 100%
Ce este ziua lansării și cum să te pregătești
Ziua lansării — nu este doar momentul apăsării butonului Publish. Este un proces coordonat la care participă dezvoltatori, QA, devops, product manageri și, uneori, suportul. Pregătirea începe cu 2-3 săptămâni înainte de ziua lansării: stabilirea scope-ului, code freeze, testare de regresie, pregătirea release notes și a materialelor de marketing. Cu cât pregătirea este mai minuțioasă, cu atât ziua lansării decurge mai liniștit.
Checklist-ul de pregătire pentru ziua lansării include: rularea finală QA (regression + smoke suite) pe build-ul de lansare; verificarea metadatelor în magazine (nume, descriere, capturi de ecran, keywords); stabilirea procentului de staged rollout cu product managerul; pregătirea planului de rollback (ce tag să fie redeployat, cât timp va dura); notificarea echipei și a serviciilor conexe despre lansarea iminentă. Release checklist ar trebui automatizat prin CI/CD — de exemplu, sub forma unui GitHub Actions workflow care verifică toate punctele înainte de crearea tag-ului de lansare.
Un element important al pregătirii — blackout period (perioada în care deploy-urile în producție sunt interzise). De obicei, blackout se introduce cu 48 de ore înainte de ziua lansării și se ridică la 24 de ore după rollout-ul reușit la 100%. Acest lucru previne deploy-urile accidentale care ar putea perturba lansarea. Change freeze în perioada de blackout se aplică tuturor serviciilor legate de lansare.
Pregătirea build-ului: code freeze, etichetare și construire
Cu 24-48 de ore înainte de ziua lansării se introduce code freeze — oprirea completă a modificărilor în cod. Dezvoltatorii trec la pregătirea documentației și a release notes. DevOps construiește build-ul de lansare dintr-un tag fixat (de exemplu, v2.6.0-rc1). Build-ul trece printr-un regression suite complet (teste automate + manuale). Dacă se găsesc critical bugs — acestea se repară înainte de code freeze sau lansarea se amână. Release candidate (RC) — build-ul care a trecut de QA și este gata de trimitere în magazin.
Etichetarea în Git: se creează un tag adnotat (git tag -a v2.6.0 -m "Release v2.6.0"). Pipeline-ul CI/CD construiește AAB (Android App Bundle) pentru Google Play și IPA (iOS App Store Package) pentru Apple App Store. Build-ului i se atașează: fișierul cu sume de control (SHA256), changelog și lista problemelor cunoscute (known issues). Reproducible builds — practica ideală prin care reconstruirea din același tag oferă un rezultat binar identic.
bash
# Pipeline de lansare — creare tag și construire
# Presupune că code freeze este deja activ
# Creează ramura de lansare din develop
git checkout develop
git pull origin develop
git checkout -b release/v2.6.0
git push origin release/v2.6.0
# Code freeze: regulile de protecție a ramurii blochează PR-urile noi
# Rulează suita de regresie în CI/CD
./gradlew clean testReleaseUnitTest connectedReleaseTest
# Creează tag-ul de lansare după QA reușit
git tag -a v2.6.0 -m "Release v2.6.0: payment module, dark mode"
git push origin v2.6.0
# Construiește binarul de lansare prin CI/CD
# fastlane build_release produce AAB + APK universal
fastlane build_releaseImportant: version bump (actualizarea version code și version name) se face înainte de code freeze. După code freeze, versiunea nu se schimbă. Pentru Android: versionCode — număr întreg monoton crescător; versionName — versiune semantică (2.6.0). Pentru iOS: CFBundleVersion (build number) și CFBundleShortVersionString (versiune semantică). Versioning ar trebui automatizat în gradle/xcconfig.
Încărcarea în magazin și parcurgerea review-ului
Pentru iOS: build-ul se încarcă prin Xcode, Transporter sau fastlane în App Store Connect. După încărcare, build-ul trece de verificarea automată Apple (processing), apoi este trimis la review manual. Timpul mediu de review — 24 de ore, dar poate varia de la 1 oră la 7 zile în funcție de încărcarea reviewerilor Apple și de cerințele de compliance. Expedited review — cerere de review accelerat pentru remedieri critice de bug-uri (disponibilă cel mult o dată pe lună, nu este garantată).
Pentru Android: build-ul se încarcă prin Google Play Console. Google utilizează o abordare combinată: testare automată (accessibility, malware, policy compliance) + review manual selectiv. Timpul mediu de review — 1-4 ore. Internal test track și Closed track permit efectuarea testării finale înainte de publicarea în Production track. Se recomandă: 1-2 zile pentru Internal test → 1 zi pentru Closed beta → rollout treptat Production.
Pentru ambele platforme, verificarea metadatelor înainte de încărcarea build-ului este crucială: numele aplicației, descrierea (short + full), capturile de ecran pentru fiecare supported device (iPhone 6.5", 5.5", iPad, Android phone, tablet), keywords (iOS) sau store listing experiments (Android). O eroare în metadate poate întârzia review-ul cu încă o zi. App metadata trebuie localizată în toate limbile suportate.
Staged rollout: cum să lansezi fără riscuri
Staged rollout (gradual rollout, staged deployment) — strategia prin care noua versiune devine disponibilă utilizatorilor nu imediat, ci treptat. Schema tipică pentru o echipă matură: 1% dintre utilizatori (primele 2-4 ore) → 10% (24 de ore) → 25% (24 de ore) → 50% (24 de ore) → 100%. Fiecare etapă include monitorizarea metricilor și verificarea absenței erorilor critice. Staged rollout — instrumentul principal de minimizare a riscului la lansări.
Google Play Console oferă staged rollout încorporat: se poate specifica procentul de utilizatori și planifica creșterea treptată. Pentru iOS App Store Connect nu există o astfel de funcționalitate încorporată — staged rollout se realizează prin Phased Release (creșterea automată a acoperirii în 7 zile, cu posibilitatea de întrerupere) sau prin server-side feature flags cu geodistribuire. Phased release în App Store Connect oferă posibilitatea de Pause Release în cazul depistării problemelor.
Metricile cheie pentru trecerea la etapa următoare: crash-free rate (≥99.9% pentru lansarea nouă), ANR rate (Android, ≤0.1%), error rate la backend API (≤0.5% 5xx), evaluările utilizatorilor (nu mai mici decât versiunea anterioară), apdex score (≥0.94). Dacă orice metrică depășește pragul — rollout este întrerupt până la clarificarea cauzelor. Go/no-go gate la fiecare etapă — responsabilitatea release managerului sau a inginerului on-call.
Monitorizarea după lansare: la ce să te uiți în primele ore
Primele 4 ore după lansare — cel mai critic timp. Echipa monitorizează crash rate (Sentry, Firebase Crashlytics, App Center), error rate 5xx pe backend, custom events (plăți reușite, autentificări, înregistrări), evaluările utilizatorilor în App Store și Google Play, mențiunile în social media (Twitter, Reddit). Dashboard-ul de monitorizare trebuie pregătit în avans și disponibil pe un ecran mare în birou sau pe un canal Slack dedicat. Release dashboard — o singură fereastră pentru toate metricile lansării.
O atenție deosebită — metricile de regresie: compararea crash rate cu versiunea anterioară pe o perioadă similară. Dacă crash rate a crescut cu mai mult de 0.1% — acesta este un semnal roșu care necesită analiză imediată. De asemenea, este importantă compararea latenței mediane și p95 a endpoint-urilor API cheie: chiar și fără crash-uri, o încetinire a timpului de răspuns cu 200ms poate semnala o problemă. Metric comparison (baseline vs current) se automatizează în Datadog sau Grafana.
Feedback-ul utilizatorilor — la fel de important ca metricile numerice. În primele ore după lansare, utilizatorii lasă activ recenzii în magazine și scriu la suport. Bug-urile neprinse de teste apar rapid în recenzii. Team lead-ul sau inginerul QA desemnat monitorizează recenziile la fiecare 30 de minute în primele 4 ore și le clasifică: false positive, known issue (deja în lista known issues), new bug. New bugs P0/P1 — declanșator pentru întreruperea rollout-ului.
Rollback: când și cum să revii la o versiune anterioară
Rollback — revenirea la versiunea stabilă anterioară în cazul depistării problemelor critice. Decizia de rollback este luată de release manager împreună cu tech lead-ul, dacă: crash-free rate al noii lansări scade sub 99%, este depistată o scurgere de date, funcționalitatea critică (plăți, autorizare) nu funcționează pentru >5% dintre utilizatori sau magazinul (App Store Review) a respins build-ul după publicare. Rollback trigger trebuie definit înainte de lansare, astfel încât decizia să se bazeze pe fapte, nu pe emoții.
Pentru Android: rollback în Google Play Console — oprirea staged rollout și comutarea la versiunea anterioară. Dacă build-ul actual este deja la 100% dintre utilizatori — publicarea versiunii anterioare ca o nouă lansare. Pentru iOS: prin App Store Connect — Phased Release → Pause Release → lansarea unei noi versiuni cu remedierea (App Store nu permite revenirea la versiunea anterioară). iOS rollback este mai complex: dezvoltatorul trebuie să construiască un nou build cu revert-commit-uri și să treacă din nou de review.
După rollback, echipa trece în modul de incident: root cause analysis, hotfix sau următoarea lansare cu remediere, post-mortem. Rollback — nu este un eșec, ci o procedură standard. Echipele care nu au făcut niciodată rollback, cel mai probabil nu observă problema, nu că lansează fără bug-uri. Rollback rate — una dintre DORA metrics: echipele de înaltă performanță fac rollback la <10% dintre lansări și se recuperează în <1 oră.
Întrebări frecvente
În ce zi este mai bine să lansezi o aplicație mobilă?
Cele mai bune zile — marți, miercuri sau joi. Luni — trafic ridicat de peste weekend, vineri — riscul de a intra în weekend cu o lansare problematică. Evită vinerea: dacă după deploy se descoperă o problemă, echipa o va repara în weekend sau va aștepta până luni.
Ce să faci dacă App Store Review a respins build-ul?
Citește motivul respingerii în Resolution Center, corectează și reîncarcă build-ul. Cauze frecvente: linkuri nefuncționale, câmpuri necompletate, conținut fără abonament (dacă este necesar), capturi de ecran învechite. App Review rejection întârzie lansarea cu 24-48 de ore, de aceea prima încărcare a build-ului trebuie făcută cu 3-5 zile înainte de data planificată a lansării.
Ce procent de staged rollout este optim pentru început?
Pentru lansări mari (major changes) — 1%. Pentru patch release — 5-10%. Prima etapă trebuie să fie suficient de mică pentru ca, în caz de eroare, impactul să fie minim, dar suficient de mare pentru a obține metrici semnificative statistic. 1% pentru o aplicație cu 10 milioane de utilizatori — 100 de mii de persoane, suficient pentru depistarea problemelor critice.
Trebuie să faci o petrecere de lansare?
Release party (petrecerea echipei) — opțional, dar benefic pentru moral. Mai bine să o organizezi după rollout-ul reușit la 100%, nu în momentul încărcării build-ului. Release celebration poate fi combinată cu release retrospective pentru a discuta ce a mers bine și ce poate fi îmbunătățit.
Cine este responsabil pentru decizia „lansare sau amânare”?
Responsabilitatea revine release managerului (de obicei senior engineer sau tech lead). Decizia se bazează pe datele din release dashboard, nu pe termenul limită. Release manager are autoritatea de a amâna lansarea dacă metricile nu trec de go/no-go gate.
Concluzii
- Ziua lansării — proces coordonat de la code freeze la monitorizarea după rollout
- Pregătirea — release candidate, rulare QA, verificare metadate, plan de rollback
- Staged rollout — 1% → 10% → 25% → 50% → 100% cu go/no-go gate la fiecare etapă
- Monitorizarea — crash-free rate, ANR, error rate 5xx, evaluări utilizatori în primele 4 ore
- Rollback — procedură standard la scăderea crash-free rate sub 99%
- Comunicarea — notificarea echipei și a părților interesate înainte și după lansare
- Release retrospective — analiza procesului după finalizarea rollout la 100%
Vom dezvolta o aplicație mobilă la cheie
IT Sectr creează aplicații iOS și Android pentru startup-uri și afaceri din 2017. Vă vom consilia și vă vom propune cea mai bună soluție.
Citiți și