حدودا یک سال پیش بود که ایرادهای فرایند نسخه‌دهی کلاینت اندروید در شرکت مطرح شد. ایراداتی مثل نامنظم بودن زمان انتشار نسخه‌های رسمی، کیفیت نسبتا پایین در انتشار برخی از نسخه‌ها و تعدد نسخه‌های هاتفیکس. یکی از دلایل این ایرادات حذف شدن اپلیکیشن بله از گوگل پلی به خاطر تحریم‌ها بود. قبل از این اتفاق یک فرایند نسخه داشتیم که بخش مهمی از آن از طریق گوگل پلی انجام می‌شد. هم کانال‌های انتشار نسخه (اینترنال، آلفا و بتا) و هم تضمین کیفیت و سلامت نسخه خروجی. برای اندازه‌گیری کیفیت و سلامت نسخه اندروید روش نوآورانه‌ای ارائه داده بودیم (AHI: App Health Indicator) که بعدها در متنی دیگر به طور مفصل در مورد آن صحبت خواهیم کرد و خواهیم گفت که چگونه تحولی در کارایی اپلیکیشن ما ایجاد کرد :)
فعلا می‌رویم سراغ اینکه در این یک سال چه مشکلاتی در روند نسخه‌دهی کلاینت اندروید داشتیم و چگونه با ایجاد فرایندهای جدید توانستیم این روند را بهبود بخشیم.
مقالات مختلفی را در زمینه مدیریت انتشار نسخه مطالعه کردیم. یکی از اصلی‌ترین بحث‌هایی که در این مقالات مطرح کرده بودند Continuous Delivery بود. یعنی اینکه ما بتوانیم رفع باگ‌ها، بهبودها و قابلیت‌های جدید را به صورت امن (Safe) و سریع به دست کاربر برسانیم. امن یعنی نسخه‌ای که می‌دهیم کیفیت لازم را داشته باشد و موجب اذیت کاربر نشود. سریع هم یعنی نسخه‌ها با فاصله‌های کمی به دست کاربران برسد.
برای اینکه نسخه‌های ما امن باشد و زود به زود نسخه بدهیم، رفتیم سراغ ایجاد فرایند انتشار نسخه (اینترنال و بتا).
نخست، فرایند انتشار نسخه اینترنال از طریق اپلیکیشن بله برای اعضای داخلی شرکت را راه‌اندازی کردیم. این نسخه اینترنال به صورت روزانه منتشر می‌شود و بچه‌های بله آن را تست می‌کنند و بازخوردهای خود را در گروه مربوطه ارسال می‌کنند. برای اینکه این تست به صورت هدف‌مندتری صورت گیرد، نیاز بود که لیست تغییرات نسخه نوشته شود. با توجه به اینکه نوشتن دستی لیست این تغییرات کار زمانبر و غیربهینه‌ای است، از کامیت مسیج‌ها (Commit message) برای استخراج و تولید لیست تغییرات (Change Log) استفاده کردیم.
با توجه به اینکه گاها نیاز می‌شود تیم‌های مختلف قبل از آنکه کد را با مستر مرج کنند، تست‌های لازم را انجام دهند، یک فرایند برای انتشار نسخه تستی نیز ایجاد کردیم. این فرایند به بهبود کیفیت نسخه‌هایی که قرار بود در اینترنال منتشر شود کمک می‌کند.
وقتی فرایندهای اولیه برای انتشار نسخه را ایجاد کردیم، رفتیم سراغ اینکه آن را در بین اعضای بله منتشر و فرهنگ‌سازی کنیم. برای مثال با ارائه‌هایی که در جامعه اندرویدمون داشتیم، اینکه چگونه کامیت معنادار بزنیم و یا نحوه استفاده از تک #CL برای نوشتن چنج لاگ کاستوم را توضیح دادیم و در فرایند رویو به این موارد بیشتر دقت کردیم.
همچنین برای اینکه تیم‌های مختلف بتوانند برای انتشار نسخه رسمی بهتر هماهنگ شوند، با صحبتی که با مدیر محصول داشتیم، تصمیم بر این شد که زمان انتشار نسخه‌ها حداقل از دو هفته قبل مشخص و اطلاع‌رسانی شود. همچنین هفته قبل از نسخه را هم تیم‌ها بیشتر به رفع باگ‌های گزارش شده بپردازند تا بتوانیم نسخه سالمی داشته باشیم.
در نهایت اولین نسخه رسمی را با روال جدید منتشر کردیم.
حال نوبت آن بود که فرایندی ایجاد کنیم که نسخه‌های خود را قبل از انتشار رسمی برای افراد بیشتری منتشر کنیم تا بهتر تست شود. برای اینکار یک کانال در اپلیکیشن بله ساختیم که به صورت هفتگی و خودکار نسخه بتا در آن منتشر می‌شود. برای اینکه نسخه بتا کیفیت حداقلی را داشته باشد، اول به صورت اینترنال منتشر می‌شود و سپس بتا. با انتشار نسخه بتا بازخوردهای خوبی گرفتیم و کاربران مشتاقمان همکاری خیلی خوبی در این زمینه دارند.
نسخه‌ای که در اسفندماه منتشر شد با حداقل رفت و برگشت و با کیفیت مناسب منتشر شد و توانستیم تاثیر فرایند جدید بر روالی نسخه‌دهی را ببینیم.
فرایندی که به آن رسیدیم را می‌توانید در شکل زیر مشاهده کنید.
حال نوبت آن بود که کیفیت نسخه‌های منتشر شده را افزایش دهیم.
بسیاری از ابزارها و معیارهایی که برای بررسی کیفیت نسخه‌های منتشر شده استفاده می‌کردیم (کرش، ANR، میزان مصرف باتری و حافظه گوشی، میزان مصرف پهنای باند و غیره)، مربوط به پنل گوگل پلی می‌شد (معیار AHI که بعدا در مقاله‌ای جدا توضیح خواهیم داد). بعد از تحریم اپلیکیشن بله توسط گوگل پلی، شروع به جایگزین کردن این ابزارها و معیارها کردیم. در بعضی قسمت‌ها سراغ ابزارهای آماده رفتیم، در بعضی هم خودمان ابزار ارائه کردیم.
یکی دیگر از اقداماتی که در راستای بهبود کیفیت نسخه‌ها انجام دادیم، افزایش کیفیت توسعه بود. این کیفیت توسعه شامل موارد مختلفی می‌شود. مثل:
با اینکه فرایند نسخه ما خیلی پخته‌تر شده بود، اما همچنان نسخه رسمی با تاخیر منتشر می‌شد و گاها کیفیت لازم را نداشت و مجدد مجبور می‌شدیم نسخه جدیدی ارائه دهیم. با هر نسخه‌ای که ارائه دادیم تجربیات جدیدی آموختیم. برخی از این تجربیات در ادامه آمده است:
با توجه به اینکه برا هر نسخه‌ای که منتشر می‌کردیم یکسری تجربیات جدید در مسیر نسخه‌دهی به دست می‌آوردیم، سندی به نام مانا (مدیریت انتشار نسخه اندروید) تدوین کردیم و در جلسات مختلف با توسعه‌دهندگان، مدیران تیم‌ها و اقلیم‌ها به اشتراک گذاشتیم.
قالب کلی سند مانا در ادامه آورده شده است:
«بسم الله الرحمن الرحیم»
روال نسخه‌دهی اندروید:
نسخه اینترنال:
نسخه بتا:
نسخه پروداکشن:
مسئول نسخه:
فرایند انتشار نسخه خود بخشی از فرایند تضمین کیفیت (QA) ماست. در سری جلسات و بحث‌های مختلفی که در شرکت در مورد تضمین کیفیت (QA) داشتیم به این نتیجه رسیدیم که چیزی که ما نیاز داریم فرایند QA هست و نه تیم QA. به طور خلاصه برخی از دلایل این تصمیم در ادامه آورده شده است:
در ادامه برای بهبود این فرایند، اقداماتی مثل ارائه معیار جایگزین AHI برای بررسی سلامت و کارایی اپلیکیشن و نیز افزایش تست‌های اتومات در راستای کاهش باگ‌ها و در نتیجه کاهش تعداد نسخه‌های هاتفیکس را در دستور کار داریم.
