روز انتشار در توسعه اپلیکیشنها: ماهیت، مراحل و آمادگی
روز انتشار (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 هفته قبل از روز انتشار آغاز میشود: توافق روی scope، code freeze، تست رگرسیون، آمادهسازی release notes و مواد بازاریابی. هرچه آمادهسازی دقیقتر باشد، خود روز انتشار آرامتر میگذرد.
چکلیست آمادهسازی برای روز انتشار شامل: اجرای نهایی QA (regression + smoke suite) روی بیلد انتشار؛ بررسی متادیتا در فروشگاهها (نام، توضیحات، اسکرینشاتها، keywords)؛ توافق درصد staged rollout با مدیر محصول؛ آمادهسازی طرح rollback (کدام تگ دوباره مستقر شود، چقدر زمان میبرد)؛ اطلاعرسانی به تیم و سرویسهای مرتبط درباره انتشار پیشرو. Release checklist باید از طریق CI/CD خودکار شود — مثلاً به صورت GitHub Actions workflow که همه موارد را قبل از ایجاد تگ انتشار بررسی میکند.
یک عنصر مهم آمادهسازی — blackout period (دورهای که استقرار در محیط تولید ممنوع است). معمولاً blackout 48 ساعت قبل از روز انتشار اعمال میشود و 24 ساعت پس از rollout موفق در 100% برداشته میشود. این کار از استقرارهای تصادفی که میتوانند انتشار را مختل کنند جلوگیری میکند. Change freeze در دوره blackout شامل همه سرویسهای مرتبط با انتشار میشود.
آمادهسازی بیلد: فریز کد، تگزنی و ساخت
24-48 ساعت قبل از روز انتشار، code freeze اعمال میشود — توقف کامل تغییرات در کد. توسعهدهندگان به آمادهسازی مستندات و release notes میپردازند. دوواپس بیلد انتشار را از تگ ثابتشده (مثلاً v2.6.0-rc1) میسازد. بیلد از regression suite کامل (تستهای خودکار + دستی) عبور میکند. اگر critical bugs پیدا شوند — قبل از code freeze رفع میشوند یا انتشار به تعویق میافتد. Release candidate (RC) — بیلدی که QA را پشت سر گذاشته و آماده ارسال به فروشگاه است.
تگزنی در Git: یک تگ annotated ایجاد میشود (git tag -a v2.6.0 -m "Release v2.6.0"). پایپلاین CI/CD برای Google Play AAB (Android App Bundle) و برای Apple App Store IPA (iOS App Store Package) میسازد. به بیلد ضمیمه میشود: فایل با جمعهای کنترلی (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 + universal 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 ساعت، اما بسته به بار بازبینان Apple و الزامات compliance میتواند از 1 ساعت تا 7 روز متغیر باشد. 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)، اسکرینشاتها برای هر supported device (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% افزایش یابد — این یک پرچم قرمز است که نیاز به تحلیل فوری دارد. همچنین مقایسه median و p95 latency اندپوینتهای کلیدی API مهم است: حتی بدون crash، کندی زمان پاسخ به میزان 200ms میتواند نشاندهنده مشکل باشد. Metric comparison (baseline vs current) در Datadog یا Grafana خودکار میشود.
بازخورد کاربران (user feedback) — کمتر از متریکهای عددی مهم نیست. در ساعات اولیه پس از انتشار، کاربران فعالانه در فروشگاهها نظر میدهند و به پشتیبانی پیام میدهند. باگهایی که توسط تستها گرفته نشدهاند به سرعت در نظرات ظاهر میشوند. Team lead یا مهندس QA تعیینشده هر 30 دقیقه در 4 ساعت اول نظرات را بررسی و طبقهبندی میکند: false positive, known issue (از قبل در لیست known issues), 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 تیم به حالت incident میرود: root cause analysis، hotfix یا انتشار بعدی با رفع، post-mortem. Rollback — شکست نیست، بلکه یک روش استاندارد است. تیمهایی که هرگز rollback انجام ندادهاند، به احتمال زیاد مشکل را متوجه نمیشوند، نه اینکه انتشار بدون باگ دارند. Rollback rate — یکی از DORA metrics: تیمهای با عملکرد بالا در کمتر از 10% انتشارها rollback انجام میدهند و در کمتر از 1 ساعت بازیابی میشوند.
سوالات متداول
در چه روزی بهتر است انتشار اپلیکیشن موبایل انجام شود؟
بهترین روزها — سهشنبه، چهارشنبه یا پنجشنبه. دوشنبه — ترافیک بالا از آخر هفته، جمعه — خطر ورود به آخر هفته با انتشار مشکلدار. از جمعه اجتناب کنید: اگر پس از استقرار مشکلی کشف شود، تیم آن را در آخر هفته رفع میکند یا تا دوشنبه صبر میکند.
اگر App Store Review بیلد را رد کرد چه باید کرد؟
دلیل رد را در Resolution Center بخوانید، رفع کنید و بیلد را دوباره آپلود کنید. دلایل رایج: لینکهای غیرفعال، فیلدهای خالی، محتوای بدون اشتراک (در صورت نیاز)، اسکرینشاتهای قدیمی. App Review rejection انتشار را 24-48 ساعت به تأخیر میاندازد، بنابراین اولین آپلود بیلد باید 3-5 روز قبل از تاریخ انتشار برنامهریزیشده باشد.
چه درصد staged rollout برای شروع بهینه است؟
برای انتشارهای بزرگ (major changes) — 1%. برای patch release — 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 از سال 2017 برنامههای iOS و Android را برای استارتاپها و کسبوکارها ایجاد میکند. ما به شما مشاوره میدهیم و بهترین راهحل را پیشنهاد خواهیم کرد.
همچنین بخوانید