وقتی در حال توسعه یک نرم‌افزار هستیم، گردش کار استاندارد به این صورت است که اول نرم‌افزار رو بسازیم، سپس به صورت محلی اون رو آزمایش کنیم و در نهایت از طریق یک استقرار منتشرش کنیم. معمولا هر نوع آزمایشی در یک محیط جداگانه در سطوح پایین‌تر انجام میشه، به استثناء تولید که به طور ویژه برای استفاده مشتری رزرو شده. اما چطور آزمایش در حین تولید رو به صورت درست انجام بدیم؟
این موضوع برای برخی از افراد ممکنه عجیب به نظر برسه. شاید بگن آزمایش در حین تولید بی احتیاطی نیست؟ که البته اگر به شکل نادرست پیاده‌سازی بشه هست. با این حال، شرکت‌های بزرگی مانند نتفلیکس و فیسبوک این استراتژی‌ها رو در پیش گرفتند که به اون‌ها اجازه داده به صورت ایمن ویژگی‌های کاربردی خودشون رو به میلیون ها عضو خود ارائه بدن. استفاده از استراتژی استقرار سوییچ ویژگی (سوییچ ویژگی شبیه به یک کلید تغییر وضعیت برای ویژگی ها و امکانات نرم افزار شماست. با استفاده از این سوییچ های ویژگی می‌تونید هر ویژگی در اپلیکیشن خودتون رو فعال یا غیر فعال کنید) به اون‌ها اجازه میده استقرارهای انعطاف‌پذیر داشته باشند که به اون‌ها در کنترل عملکرد نرم افزار اختیار کامل میده و زمان اضافه شدن ویژگی‌ها به محصول رو کاهش میده که باعث وفاداری مشتریان میشه.
آزمایش حین تولید به یک استراتژی استقرار کامل نیاز داره که برای اون باید از یک ابزار سوییچ ویژگی استفاده کنید، به خصوص اگر از قبل این ابزارها رو ندارید.
در این مقاله در مورد مزایا و معایب بزرگ آزمایش در حین تولید صحبت می‌کنیم. بعد از اون به صورت قدم به قدم آزمایش در حین تولید توسط خودتون رو شرح می‌دیم.
اول از همه، بیاین به برخی از مزایای آزمایش در حین تولید نگاهی بیندازیم.
مزایای آزمایش در حین تولید
۱. در هنگام استقرار دقت آزمایش رو افزایش میده
وقتی صحبت از آزمایش یک ویژگیه، بهترین راه، آزمایش اون در محیطی مشابه با محیطیه که قراره در اون استفاده بشه. این موضوع به خصوص در مواردی که آزمایش در محیط‌های پایین‌تر انجام میشه اهمیت داره، که اگر در محیط مشابه نباشه، نتایج غیر دقیق یا پیکربندی متفاوت رو به همراه داره. این موضوع می‌تونه به استقرارهای غیر‌منظم در حین انتقال بین محیط‌ها منجر بشه.
اگر شما در حین تولید آزمایش انجام بدید، اطمینان دارید کاربران همون عملکردی رو تجربه می‌کنن که در حین آزمایش تایید شده.
۲. باعث اجرای استقرارهای منظم میشه
برای این که توانایی آزمایش در حین تولید داشته باشید، باید نگرشتون رو در مورد نحوه استقرار عوض کنید.
دیگر با روزها و ماه‌های بین استقرارها که در هر کدام کلی ویژگی وجود داره، خداحافظی کنید.این‌گونه استقرارها کلی خطر به همراه دارند که در نهایت محصولی تولید می‌کنند که فقط به اندازه کافی خوبه، و رفع باگ‌ها حتی اگه زود اون‌ها رو پیدا کنید، تا زمان استقرار بعدی که ماه‌ها فاصله داره طول می‌کشه.
با استقرارهای منظم و نزدیک به هم، بهتر می‌تونید به درخواست‌های مشتریان واکنش نشون بدید و تغییرات رو وقتی لازمه پیاده‌سازی کنید. استقرارهای منظم اجازه میده توسعه مبتنی بر سوییچ داشته باشید. که یعنی یک سوییچ ویژگی دارید که در زمان مناسب می‌تونه تبدیل به عملکرد بشه. این کار اگر به صورت درست انجام بشه، یعنی توسعه‌دهنده نیازی نیست نگران نشت عملکردها به محیط‌های بالاتر باشه، حتی اگر اون عملکرد کامل نباشه.
همون‌طور که در بخش بعد می‌گیم، استفاده از سوییچ ویژگی این توانایی رو افزایش میده که بتونین عملکردها رو حتی بدون استقرار تغییر بدید.
۳. اجازه انتقال یکپارچه بین فازهای آزمایش رو میده
آزمایش در حین تولید، تعریف شما از آزمایش رو گسترش میده:
به جای این که آزمایش یک سناریوی «این کار می‌کنه یا نه» باشه، تبدیل میشه به آزمایش واقعی یک ویژگی خاص.
برای مثال ممکنه ما بخوایم یک رابط کاربری متفاوت رو آزمایش کنیم.
می‌تونیم از روش آزمایش در حین تولید استفاده کنیم تا عملکردش رو اول از طریق کیفیت‌سنجی آزمایش کنیم. بعد از تایید، ما می‌تونیم از مشتری‌های واقعی و آزمایش A/B استفاده کنیم و داده‌های مربوط به عملکرد جدید رو جمع آوری کنیم.
این مزایا عالی هستند اما البته استفاده از یک استراتژی مثل این، چالش‌های خودش رو هم داره.
چالش‌های آزمایش حین تولید
۱. خطرات امنیتی
وقتی آزمایش در حین تولید انجام می‌دید، یکی از مهمترین مسائلی که با اون برخورد می‌کنید امنیته. ما دیگر فقط با داده‌های آزمایشی کار نمی‌کنیم، بلکه با داده‌های واقعی در لحظه سروکار داریم. این موضوع اهمیت محافظت از داده‌ها رو افزایش میده. این یعنی موقع آزمایش با داده‌های مشتریان باید خیلی مراقب باشیم.
اهمیت مراقبت از داده‌ها بسته به اپلیکیشن شما تغییر‌می کنه. بعضی از نرم‌افزارها موافقت‌نامه HIPAA دارند که تخطی از اون‌ها می‌تونه هزینه‌های خیلی سنگینی داشته باشه. بقیه، به خصوص در صنایع مالی، حاوی اطلاعات هویتی اشخاص هستند. نشت داده‌های کاربران می‌تونه منجر به شکایت‌های بزرگ یا حتی اتفاقات بدتر از اون بشه.
یکی از راه‌های کم کردن خطر اینه که تعداد ابزارهایی که به این داده‌ها دسترسی دارن رو محدود کنید. هر چه تعداد مکان‌هایی که این اطلاعات هویتی ذخیره می‌شن بیشتر باشه، خطرش هم بیشتره. ابزاری مثل CloudBees Feature Flags این کار رو با عدم اجبار به ذخیره داده‌ها برای استفاده انجام میده. علاوه بر این CloudBees در تمام مراحل، امنیت رو به طور کامل رعایت می‌کنه.
۲. داشتن بلوغ لازم در مهارت‌های استقرار
آزمایش حین تولید نیاز داره که از قبل یک فرایند استقرار بالغ و کامل وجود داشته باشه.
اول از همه شما باید ابزارهای لازم برای استقرار سریع رو داشته باشید. یعنی از استقرارهای سنگین به صورت دستی دوری کنید. چون این استقرارها به خاطر عدم ثبات خطرناک هستند.
در مرحله بعدی، استقرارها باید با فاصله کمتری انجام بشن تا سوییچ‌های ویژگی با امنیت بیشتری به اپلیکیشن اضافه بشن. شما باید از سوییچ‌های ویژگی به صورت داینامیک استفاده کنید، تا نه تنها قدرت خاموش یا روشن کردن ویژگی رو داشته باشید، بلکه بتونید بر اساس نیاز مشتری، عملکرد اون رو تغییر بدید. در نهایت، همون سوییچ‌ها باید از قبل وجود داشته باشند تا در صورت نیاز بتونید یک سوییچ ویژگی رو به راحتی خاموش کنید.
فعال‌سازی تک به تک سوییچ‌های ویژگی که در سراسر تخته استفاده شدند، اهمیت یک تجربه کاربری مثبت در مدیریت سوییچ‌های ویژگی رو بیشتر می‌کنه. نکته مهم در اینجا داشتن یک رابط کاربری خوب برای تغییر وضعیت سوییچ‌های ویژگی و ابزارهای لازم برای کنترل در سراسر شرکته. نکته آخر به خصوص در شرکت‌های خیلی بزرگ اهمیت بیشتری داره چون فرایند استقرار در این شرکت‌ها در قسمت‌های مختلفی انجام می‌گیره.
مشکلات مربوط به آزمایش حین تولید بدون قابلیت‌های استقرار مناسب
در صورتی که سعی کنید بدون قابلیت‌های استقرار مناسب آزمایش حین تولید انجام بدید، چند اتفاق ممکنه بیفته:
- داده های بد می‌تونن پایگاه داده تولید شما رو پر کنن و بدون یک طرح برای برگشت به حالت اولیه، ممکنه نیاز به دخالت دستی برای اصلاح داده‌ها باشه. این موضوع از نظر امنیتی و عملکرد مشکلاتی رو به وجود میاره.
- ممکنه مشکلات پیش‌بینی نشده در عملکرد یا از کار افتادن پیش‌بینی نشده‌ی اپلیکشن‌های خارجی اتفاق بیفته. اصلاح این مشکلات ممکنه نیاز به تغییر عملکرد بر اساس درخواست‌ها با استفاده از سوییچ‌های ویژگی یا متوازن کردن بارگذاری سیستم‌هایی با عملکردهای مختلف شبیه به تکنیک انتشار قناری (canary releasing) داشته باشه.
این ممکنه در نگاه اول خیلی ترسناک به نظر برسه. شاید حتی برای گروهی که از استراتژی‌های جدید استقرار استفاده نمی‌کنند، خیلی سخت باشه.
سختی کار فقط در پیاده‌سازی این ویژگی‌ها نیست، بلکه در سازگاری با انتشار مکرر هم اتفاق میفته. با توجه به این دو مشکل بالقوه، در نظر گرفتن خرید ابزارهایی مثل CloudBees Feature Flags برای پیاده‌سازی این ویژگی‌ها ارزشش رو داره.
چطور آزمایش حین تولید انجام بدیم؟
حالا بعد از خواندن مزایا و معایب آزمایش حین تولید، نوبت به نحوه استفاده از اون در گردش کار استقرار نرم‌افزار می‌رسه.
شروع آزمایش حین تولید معمولا حول دو محور می چرخه:
- استقرار مداوم و منظم در محیط تولید؛
- فعال‌سازی تک به تک و انتشار ویژگی‌ها برای کاربران به صورت افزایشی.
بیاید فاکتورهای مهم برای انجام هر کدوم رو بررسی کنیم.
۱. استقرارهای مداوم و منظم سوییچ‌های ویژگی
اولین قدم در آغاز آزمایش حین تولید، استقرارهای کوچک‌تر و منظم‌تر است.
این استقرارها باید با سوییچ‌های ویژگی همراه باشند تا فعال‌سازی در محیط رو کنترل کنند.
نکته‌ای که برای استقرار منظم باید در نظر داشته باشیم:
سوییچ‌های ویژگی اجازه استقرار نرم‌افزار با عملکرد کامل نشده رو میده. این طوری، می‌تونید بدون نگرانی در عملکرد، استقرار رو انجام بدید.
۲. فعال‌سازی سوییچ ویژگی به صورت تک به تک
بالاخره، به مرحله عمل رسیدیم: آزمایش حین تولید.
برای شروع، سوییچ‌های ویژگی رو به همراه عملکرد در اون استقرار می‌دیم.
ما نه تنها می‌تونیم اون ویژگی‌ها رو خاموش یا روشن کنیم، بلکه می‌تونیم تعداد کاربرانی رو که به اون ویژگی دسترسی دارند، کنترل کنیم.
بررسی مثال اول
به عنوان مثال، فرض کنید می‌خوایم یک ویژگی جدید رو معرفی کنیم.
با استفاده از یک سوییچ ویژگی، ما این ویژگی رو با عملکرد خاموش برای همه کاربران در تولید استقرار می‌دیم.
وقتی آماده بودیم، ما سوییچ ویژگی رو برای گروهی از کاربران که جزیی از تیم QA هستند، روشن می‌کنیم.
این تیم می‌تونه آزمایش دستی انجام بده تا مطمئن بشیم همه چیز در جای درست قرار داره. وقتی مطمئن شدیم همه چیز درسته، ما سوییچ ویژگی رو برای همه کاربران روشن می‌کنیم. چون آزمایش داخلی در همون محیطی انجام شده که کاربران از اون استفاده می‌کنند، از عملکرد مناسب ویژگی اطمینان بیشتری داریم.
این تیم می‌تونه آزمایش دستی انجام بده تا مطمئن بشیم همه چیز در جای درست قرار داره.
وقتی مطمئن شدیم همه چیز درسته، ما سوییچ ویژگی رو برای همه کاربران روشن می‌کنیم. چون آزمایش داخلی در همون محیطی انجام شده که کاربران از اون استفاده می‌کنند، از عملکرد مناسب ویژگی اطمینان بیشتری داریم.
بررسی مثال دوم
در یک مثال دیگه، انتشار یک رابط کاربری جدید رو در نظر می‌گیریم، که جایگزین یک گردش کار برای چیزی مثل پر کردن یک اپلیکیشن میشه.
ما این عملکرد رو با استفاده از سوییچ ویژگی و به صورت 80/20 پیاده می‌کنیم، که در اون به صورت تصادفی برای 20 درصد از کاربران فعال می‌کنیم.
ما می‌تونیم داده‌های مربوط به رضایت کاربران رو ثبت کنیم (نظرسنجی‌ها، سرعت تطبیق‌پذیری و غیره) و این مقدار رو با توجه به داده‌های کاربران عوض کنیم. با فرض این که کاربران عکس‌العمل خوبی داشتند، می‌تونیم به طور کامل رابط کاربری جدید رو استقرار بدیم.
احتمال دیگه اینه کاربران عکس‌العمل خوبی نداشتند.
این موضوع اگرچه باعث تاسفه، ولی به این معناست که می‌تونیم سوییچ ویژگی رو به حالت قبل برگردانیم و دوباره روی رابط کاربری جدید کار کنیم.
در نظر اول، این ممکنه اتلاف وقت به نظر برسه، اما در نظر داشته باشید که عکس‌العمل ضعیف کاربران به رابط کاربری جدید در مراحل اولیه مشخص شد.
مشخص شدن این عکس‌العمل ضعیف بعد از انتشار کامل ممکن بود عواقب بدتری مثل از دست رفتن اعتماد مشتریان و بروز مشکل در برگشت به حالت قبل بشه.
برتری در ارائه ویژگی با آزمایش حین تولید
اگرچه ممکنه این کار خیلی سخت به نظر برسه، اما استفاده از گردش کار آزمایش حین تولید در مقایسه با رقبا به شما برتری بیشتری برای انتشار یک نرم‌افزار باثبات و ارائه عملکردهای جدید میده.
اگر قصد دارید از آزمایش حین تولید استفاده کنید اما احساس می کنید باعث فشار مضاعف بر روی تیم شما میشه، می‌تونید از ابزار CloudBees Feature Flags برای افزایش سرعت کارتون استفاده کنید.
