خط لوله ساخت و انتشار اپلیکیشن
در وب، اگر ساخت و استقرار دستی باشد، دردسر است. در موبایل، گلوگاه است — و دلیلش یک واقعیت ساده است:
بازگشت نسخه در موبایل وجود ندارد. نمی‌توانید نسخهٔ بد را از گوشی کاربران بردارید. تنها گزینه‌تان انتشار سریع نسخهٔ اصلاحی است، که چند روز طول می‌کشد.
پس هر چیزی که احتمال انتشار نسخهٔ معیوب را کم کند، در موبایل ارزش نامتناسبی دارد.
چه چیزی خودکار می‌شود
ساخت. روی هر ادغام، خودکار. اگر کامپایل نمی‌شود، همان‌جا معلوم شود.
تحلیل ایستا و قالب‌بندی.
تست واحد و یکپارچگی.
ساخت نسخهٔ قابل نصب با شمارهٔ نسخه و شناسهٔ کامیت.
توزیع نسخهٔ آزمایشی به تیم و آزمایش‌کنندگان.
بارگذاری در بازارها.
اگر امروز هیچ‌کدام را ندارید، سه مورد اول را بگذارید. بیشتر ارزش را همان‌ها می‌دهند — منطق کلی‌اش در CI/CD.
کلید امضا، حساس‌ترین بخش
هر فایل نصبی باید امضا شود، و کلید امضا برگشت‌ناپذیرترین دارایی پروژهٔ شماست: اگر گمش کنید، نمی‌توانید هرگز به‌روزرسانی منتشر کنید و باید اپ جدیدی بسازید و کاربران را از صفر جمع کنید.
قواعد:
در مخزن کد نگذارید. هرگز.
در انبار امن خط لوله نگه دارید، با دسترسی محدود.
پشتیبان بگیرید، جای دیگری، رمزنگاری‌شده.
چه کسانی دسترسی دارند را بنویسید و در فرایند خروج کارمند بیاورید.
این را در انتشار اپلیکیشن و هزینهٔ نگهداری اپلیکیشن هم گفتیم و اینجا سومین بار است — چون تنها اشتباه این حوزه است که هیچ راه جبرانی ندارد.
شمارهٔ نسخه
خودکار افزایش یابد، نه دستی. شمارهٔ نسخهٔ تکراری، بارگذاری را رد می‌کند و وقت تلف می‌کند.
نسخهٔ نمایشی و نسخهٔ داخلی را جدا کنید. آنچه کاربر می‌بیند و آنچه فروشگاه برای ترتیب استفاده می‌کند.
و نسخه را به کامیت وصل کنید. وقتی گزارش خرابی می‌آید، باید بتوانید دقیقاً بدانید کدام کد بوده.
محیط‌ها
اپ باید بتواند به سرورهای مختلف وصل شود بدون تغییر کد:
توسعه، آزمایش، تولید. پیکربندی در زمان ساخت تزریق شود.
نصب همزمان چند نسخه. شناسهٔ بستهٔ متفاوت برای نسخهٔ آزمایشی، تا آزمایش‌کننده بتواند هم نسخهٔ تولید و هم آزمایشی را روی یک گوشی داشته باشد. این یک تنظیم کوچک است و کیفیت تست را واقعاً بالا می‌برد.
و نشانهٔ بصری روی نسخهٔ آزمایشی — آیکون متفاوت یا نوار رنگی. بدون آن، کسی گزارش باگی می‌دهد که مال محیط آزمایش بوده.
توزیع نسخهٔ آزمایشی در بازار ایران
اینجا مسئلهٔ خاصی داریم: سازوکار استاندارد توزیع آزمایشی که در بازارهای جهانی هست، اینجا کامل در دسترس نیست.
گزینه‌های عملی:
سرویس توزیع داخلی، که فایل را میزبانی می‌کند و لینک نصب می‌دهد.
میزبانی روی سرور خودتان، با صفحهٔ نصب و کنترل دسترسی. ساده و کاملاً در کنترل شما.
بخش آزمایشی بازارهای داخلی، که بعضی‌شان امکان انتشار محدود دارند.
توصیهٔ عملی: خط لوله پس از هر ادغام موفق، فایل را بسازد و لینکش را در کانال تیم بگذارد. همین یک قابلیت، چرخهٔ بازخورد را از روزها به دقیقه‌ها می‌رساند.
پرچم قابلیت، ضروری‌تر از وب
چون بازگشت نسخه ممکن نیست، پرچم قابلیت تنها راه خاموش‌کردن قابلیت معیوب بدون انتشار جدید است.
و پیکربندی از سمت سرور همین منطق را گسترش می‌دهد: هر چیزی که ممکن است عوض شود — متن‌ها، آستانه‌ها، لینک‌ها، آدرس سرویس‌ها — از سرور بیاید نه از داخل اپ.
هر تغییری که نیاز به انتشار نسخه نداشته باشد، چند روز و چند برابر هزینه صرفه‌جویی می‌کند.
آنچه پیش از انتشار باید در خط لوله باشد
- تست‌ها سبزند
- نسخهٔ انتشار ساخته و تست شده، نه نسخهٔ توسعه
- شمارهٔ نسخه افزایش یافته
- فایل با کلید درست امضا شده
- پیکربندی محیط تولید است
- گزارش خرابی فعال است
- حجم فایل بررسی شده — رشد ناگهانی، نشانهٔ چیزی است
بند دوم را جدی بگیرید: نسخهٔ انتشار به‌دلیل بهینه‌سازی و مبهم‌سازی کد، گاهی رفتار متفاوتی دارد و باگ‌هایی هست که فقط آنجا ظاهر می‌شوند — همان نکته‌ای که در تست اپلیکیشن موبایل گفتیم.
پس از انتشار
پایش نرخ خرابی به تفکیک نسخه. اگر نسخهٔ جدید بدتر از قبلی است، فوراً معلوم شود.
انتشار تدریجی، اگر بازار پشتیبانی می‌کند.
و برنامهٔ اصلاح فوری: اگر باگ جدی پیدا شد، چقدر طول می‌کشد تا نسخهٔ اصلاحی برسد؟ اگر جوابتان «نمی‌دانم» است، همین را اول درست کنید.
و یک نکتهٔ زیرساختی
ساخت اپ به سخت‌افزار و ابزار خاصی نیاز دارد — و برای iOS، به سیستم‌عامل خاص.
در بازار ما، سرویس‌های ابری ساخت همیشه در دسترس نیستند. اگر خط لولهٔ شما به سرویسی وابسته است که ممکن است قطع شود، ماشین ساخت محلی داشته باشید — حتی اگر معمولاً از ابری استفاده می‌کنید.
همان اصلی که در CI/CD دربارهٔ آینهٔ داخلی وابستگی‌ها گفتیم: خط لوله‌ای که برای ساخت به شبکهٔ آزاد نیاز دارد، پایدار نیست.