مدیریت انتشار اپلیکیشن موبایل واقعا به چه معناست
مدیریت انتشار اپلیکیشن موبایل فرآیند هماهنگ برنامه ریزی، ساخت، آزمایش، تایید، ارسال و نظارت بر تغییرات برنامه در طول چرخه عمر آن است. این بافت پیوندی بین کار مهندسی و نسخه ای است که کاربران شما واقعاً دانلود می کنند. اگر به خوبی انجام شود، جریانی از تغییرات کد فردی را به جای یک سری از راه اندازی های مضطرب به نسخه های قابل پیش بینی و کم خطر تبدیل می کند.
این به تفکیک دو ایده که اغلب مبهم هستند کمک می کند. مدیریت انتشار عمومی یک نرم افزار گسترده است که در همه انواع سیستم ها استفاده می شود. مدیریت انتشار اپلیکیشن موبایل پسر عموی تخصصی آن است که بر اساس پشتیبانی فروشگاه اپلیکیشن، قطعه قطعه شدن دستگاه و سیستم عامل، و این واقعیت که شما نمی‌توانید نرم‌افزاری را که از قبل بر روی تلفن کاربر نصب شده است، وصله کنید، شکل می‌گیرد. این تفاوت‌ها تصمیم‌گیری‌های سرعتی را در تلفن همراه بسیار دشوارتر می‌کند تا در وب، جایی که رفع مشکل می‌تواند در عرض چند دقیقه انجام شود.
جایی که کنترل نسخه در چرخه عمر توسعه برنامه قرار دارد
در چرخه عمر توسعه برنامه گسترده تر، کشف، طراحی، توسعه، آزمایش، انتشار و پشتیبانی، مدیریت انتشار انتقال از «کد تمام شده» به «در دست کاربران» را مدیریت می کند. چرخه انتشار نرم‌افزار سالم به‌طور قابل پیش‌بینی تکرار می‌شود: محدوده برنامه‌ریزی، توسعه و ادغام، آزمایش در بین دستگاه‌ها و نسخه‌های سیستم‌عامل، ارسال برای بررسی فروشگاه، استقرار در مراحل، سپس مشاهده رفتار دنیای واقعی قبل از شروع چرخه بعدی. هر یک از این مراحل دارای پیامدهای زمانی است، بنابراین آهنگ را نمی توان جدا از بقیه چرخه عمر توسعه برنامه تنظیم کرد.
چرا Cadence یک راه حل استراتژیک است، نه فقط یک راه حل فنی
برای گروه مختلطی از سهامداران (مهندسین اصلی، صاحبان محصول، و حامیان تجاری)، به جای یک جزییات ورودی، سرعت را به عنوان یک مبادله تجاری در نظر می‌گیرد. به‌روزرسانی‌های سریعتر برنامه تلفن همراه به معنای رفع سریعتر، پاسخ سریعتر به تغییرات بازار، و شتاب پایدارتر محصول است. اما هر نسخه همچنین ظرفیت QA را مصرف می کند، خطر رگرسیون را به همراه دارد و به چیزی از کاربران شما نیاز دارد تا دانلود کنند و با هر تغییر سازگار شوند.
فرکانس به‌روزرسانی برنامه «درست» جهانی وجود ندارد. یک برنامه بانکی با الزامات انطباق دقیق نباید با سرعت یک ابزار بهره وری داخلی ارائه شود. هدف مدیریت انتشار اپلیکیشن موبایل این است که سرعتی را پیدا کند که ارزش تحویلی بیشتر از هزینه و ریسک تحویل باشد، و آن را به یک انتخاب عمدی تبدیل کند، نه تصادفی بودن آخرین کسی که کد را ادغام کرده است.
محدودیت‌های پلتفرم که هر تصمیم انتشار را شکل می‌دهند
قبل از انتخاب آهنگ، تیم های سازمانی باید به محدودیت های اعمال شده توسط اپل و گوگل پایبند باشند. آنها غیرقابل مذاکره هستند و به آرامی سقفی را برای سرعتی که به روز رسانی برنامه های تلفن همراه می تواند به طور واقعی به کاربران برسد تعیین می کنند.
شرایط بررسی App Store و Google Play
در iOS، هر نسخه جدید مورد بررسی فروشگاه App قرار می گیرد. اپل می‌گوید 90 درصد ارسال‌ها را به‌طور میانگین در عرض 24 ساعت بررسی می‌کند، اما این یک میانگین است، نه تضمینی، و برنامه‌های پیچیده، مجوزهای حساس یا ارسال‌های بار اول می‌توانند به میزان قابل توجهی بیشتر طول بکشند. در اندروید، اکثر به‌روزرسانی‌ها به سرعت پاک می‌شوند، اما اسناد کنسول Play خود گوگل هشدار می‌دهد که برخی از برنامه‌ها ممکن است در موارد استثنایی تا هفت روز یا بیشتر مورد بازبینی طولانی‌تری قرار بگیرند. برای تیمی که در حال برنامه‌ریزی پنجره‌های انتشار فشرده است، این تنوع باید در چرخه انتشار نرم‌افزار گنجانده شود، نه اینکه به عنوان یک مورد لبه نادر تلقی شود.
انتشار مرحله ای و انتشار مرحله ای
هر دو پلتفرم به شما این امکان را می‌دهند که به‌جای یک‌باره، یک مکانیسم ایمنی حیاتی در مدیریت انتشار برنامه‌های تلفن همراه را به صورت تدریجی منتشر کنید. عرضه تدریجی اپل در یک دوره هفت روزه به‌روزرسانی‌هایی را برای کاربرانی که به‌طور تصادفی انتخاب شده‌اند و به‌روزرسانی‌های خودکار فعال است، ارائه می‌کند و اگر مشکلی به نظر می‌رسد می‌توانید آن را تا 30 روز متوقف کنید. عرضه مرحله‌ای Google Play به شما کنترل دستی می‌دهد: شما درصد دقیق کاربرانی را انتخاب می‌کنید که هر مرحله از عرضه را دریافت می‌کنند.
یک تفاوت در برنامه ریزی ریسک اهمیت زیادی دارد. در iOS، عرضه بر روی یک برنامه هفت روزه ثابت کار می‌کند که می‌توانید آن را متوقف کنید، اما نمی‌توانید پیکربندی مجدد آن را انجام دهید، و برای به‌روزرسانی‌ها اعمال می‌شود، نه برنامه‌های جدید. مهمتر از آن، استقرار برنامه ای که قبلاً به دست کاربران رسیده است را نمی توان به سطح باینری در اپ استور بازگرداند. اگر در حین انتشار یک باگ جدی پیدا کردید، می توانید قرار گرفتن در معرض بیشتر را متوقف کنید، اما تنها راه حل واقعی این است که یک نسخه جدید و نسخه بالاتر را از طریق بررسی مجدد ارسال کنید. این واقعیت باید قبل از شروع هر برنامه کاربردی، میزان اعتماد شما را مشخص کند.
الگوهای آهنگ انتشار رایج
اکثر تیم های سازمانی بر روی یکی از چندین مدل آهنگی مستقر می شوند. درک مبادلات بین آنها در قلب مدیریت انتشار برنامه های تلفن همراه است.
آهنگ مبتنی بر زمان (ثابت).
در اینجا شما یک تقویم (دو هفته ای، ماهانه یا فصلی) را بدون توجه به اینکه دقیقاً چه چیزی آماده است، ارسال می کنید. این مدل که اغلب به عنوان «قطار آزادسازی» نامیده می‌شود، قابلیت پیش‌بینی را به همراه دارد: سهامداران می‌دانند چه زمانی ویژگی‌ها در حال آمدن هستند، چرخه‌های QA عادی می‌شوند، و بازاریابی می‌تواند در مورد تاریخ‌های شناخته شده برنامه‌ریزی کند. هر قطاری که از دست می دهد، فقط قطار بعدی را می گیرد. معاوضه این است که یک ویژگی تکمیل شده می تواند منتظر شکاف برنامه ریزی شده خود باشد.
آهنگ مبتنی بر ویژگی
در این مدل، زمانی که یک ویژگی یا نقطه عطف مهم تکمیل شود، نه در یک تاریخ ثابت، آن را آزاد می کنید. برای محصولات با تحویل نامنظم و بزرگتر مناسب است. مزیت این است که شما یک مقدار را زمانی که واقعا آماده است ارسال می کنید. نکته منفی غیرقابل پیش بینی بودن آن است که برنامه ریزی هماهنگی و بررسی برنامه فروشگاه را دشوارتر می کند.
انتشار مداوم
برخی از تیم‌های بالغ، با پشتیبانی از اتوماسیون سنگین، خطوط لوله قوی CI/CD، و دارای پرچم‌هایی هستند که به آنها اجازه می‌دهد عملکرد را بدون ارسال باینری جدید روشن یا خاموش کنند، اغلب فشار می‌آورند. در تلفن همراه، قدرتمند اما محدود است: پیش‌نمایش فروشگاه و ارائه مرحله‌ای هفت روزه به این معنی است که هرگز نمی‌توانید به اندازه یک وب سرویس فوری باشید. پرچم‌های ویژگی در اینجا ضروری می‌شوند زیرا «کد کشتی» را از «آزادی ویژگی» جدا می‌کنند و به تیم‌ها با وجود چرخه انتشار نرم‌افزار موبایل کندتر، کنترل وب‌مانندی را می‌دهند.
هیبریدی با نوار به روز
در عمل، اکثر تیم‌های سازمانی این رویکردها را ترکیب می‌کنند: یک سرعت قابل پیش‌بینی و مبتنی بر زمان برای کارهای برنامه‌ریزی‌شده، به‌علاوه یک خط سریع جداگانه برای رفع فوری امنیتی و رفع اشکال‌های حیاتی. این ترکیبی اغلب سالم‌ترین شکل مدیریت انتشار برنامه‌های تلفن همراه است، زیرا انتشارات روتین را آرام و قابل پیش‌بینی نگه می‌دارد و در عین حال امکان انتشار برنامه‌های اضطراری را در زمانی که چیزی واقعاً نمی‌تواند منتظر قطار بعدی باشد، می‌دهد.
نحوه انتخاب فرکانس مناسب به روز رسانی برنامه
به جای کپی کردن یک رقیب، تصمیم بگیرید هر چند وقت یکبار برنامه خود را مطابق با زمینه خود به روز کنید. چند سوال بیشتر کار را انجام می دهد:
- پایگاه کاربر و سهام: یک پایگاه کاربر بزرگ یا تنظیم‌شده، هزینه انتشار بد را افزایش می‌دهد، و به نفع آهنگ‌های آهسته‌تر، آزمایش‌شده‌تر و استقرار مرحله‌ای محتاطانه‌تر است.
- ظرفیت و کیفیت تیم: نسخه‌های مکرر فقط در صورتی کار می‌کنند که آزمایش، نظارت و تعمیر و نگهداری بتواند سرعت خود را حفظ کند. Cadence هرگز نباید از ظرفیت QA شما تجاوز کند.
- اتصال عقب: اگر برنامه شما به سرویس‌های پشتیبان وابسته است که مرتباً تغییر می‌کنند، کنترل نسخه باید این دو را هماهنگ کند تا به‌روزرسانی برنامه تلفن همراه هرگز قبل از API که به آن متکی است ارسال نشود.
- تحمل ریسک و انطباق: محیط های بسیار تنظیم شده نیاز به شکاف های تایید و مسیرهای ممیزی دارند که به طور طبیعی چرخه انتشار نرم افزار را طولانی تر می کند.
- سررسید درخواست: برنامه جدیدی که به دنبال تناسب محصول با بازار است، از تکرار سریعتر سود می برد. یک برنامه بالغ و پایدار اغلب به آهنگ های کندتر و ایمن تر تغییر می کند.
