یکی از مهمترین بخش های صنعت نرم افزار، ارائه نرم افزار ساخته شده به کاربران واقعیه. این ارائه میتونه در مورد نرم افزاری باشه که تازه قراره بره زیر تست، یا نرم افزاری که یک نسخه عمومی داره و نسخه جدیدش قراره جایگزین بشه.
اصطلاح deployment strategy یا استراتژی استقرار، به مسیری گفته میشه که قراره نرم افزار رو در دید و استفاده عموم قرار بدیم. استراتژی های مطرحی طی این سالیان ارائه شده اند که میخوایم به معروف ترین هاش بپردازیم:
استراتژی Blue-Green
استراتژی Canary
استراتژی A/B Testing
چرا مسیر استقرار نرم افزار مهمه ؟
برای اینکه کاربرها موقع استفاده از سرویس ما، کمترین میزان down time رو حس کنند. موقع استفاده از برنامه ما به کمترین خطای ممکن برخورد کنند. و در نهایت رضایت خاطر مشتری رو به همراه داره.
استراتژی Blue-Green
سال ۱۹۹۴ دو برنامه نویس تصمیم گرفتند نسخه جدید فروشگاه اینترنتی شون رو مستقر کنند. همه تست های اتوماتیک رو هم نوشته بودند. بلافاصله بعد از استقرار نسخه جدید، مشتریان با کوهی از مشکلات و خطاهای عجیب و غریب روبرو شدند. بعد از کلی بررسی، فهمیدند که مشکل از کجاست
محیط development و production دو محیط کاملا متفاوت بودند و تست ها روی محیط development همه چیز رو درست نشون میدادند
استقرار Blue-Green نوع خاصی از استقرار Autometed حساب میشه که از دو محیط یکسان به نام های آبی و سبز برای استقرار اپلیکیشن وب تون استفاده می کنید. محیط آبی محیطیه که محصول فعلی تون در اختیار کاربرانه، در حالی که محیط سبز جاییه که نسخه جدید برنامه تون رو مستقر میکنید. می توانید قبل از تغییر ترافیک از محیط آبی به محیط سبز، محیط سبز رو آزمایش و تأیید کنید. این کار زمان خرابی، خطر و اختلال رو به حداقل می رسونه و به شما امکان میده در صورت بروز هر گونه مشکلی به محیط آبی برگردید.
مزایای استفاده از استراتژی Blue-Breen
زمانی که تست ها واقعیت های نرم افزار رو منعکس میکنند، اجرای تست ها روی محیط سخت افزار و نرم افزاری که دقیقا مثل production باشه، اون ها رو مفیدتر و معنادارتر میکنه. بنابر این برای نرم افزارهایی که از تست های خوبی بهره می برند، استفاده از استراتژی Blue-Green مزیت حساب میشه.
استقرار بدون محدویت زمان: ما می توانیم در هر زمانی که دلمون میخواد منتشرش کنیم. نیازی نیست که مثلا ساعت ۳ صبح منتشرش کنیم یا مثلا منتظر تصحیح یک فیچر خاص باشیم.
انتقال فوری: کاربران بلافاصله یا تقریبا بلافاصله به نسخه جدید منتقل میشن. با جابجا کردن ترافیک روی نسخه جدید، همه به طور همزمان آخرین نسخه رو می بینند.
بازگشت فوری: اگر تصمیم بگیریم به هر دلیلی به نسخه قبلی برگردیم، میتونیم همه کاربرها رو در یک لحظه برگردونیم.
کاهش استرس فاجعه های احتمالی : استراتژی Blue-Green می تونه ما رو از سناریوهای فاجعه نجات بده. فرض کنید مشکلی پیش بیاد و یک مرکز داده آفلاین بشه یا محیط live مون down بشه. مهم نیست، تا زمانی که مشکل برطرف بشه، ترافیک رو به محیط دیگه مون (سبز یا آبی) منتقل می کنیم.
اشکال زدایی راحت تر نسخه های ناموفق: وقتی نسخه جدید به مشکل میخوره، اولویت بیزینس همیشه بازگشت به حالت عادیه و اینکه چرا نرم افزار به مشکل خورده اولویت دومه. در استراتژی های قدیمی تر وقتی نرم افزار جدید به مشکل میخورد، نرم افزار جدید کلا از بین میرفت و خیلی از اطلاعات ارزشمند که میتونست به رفع اشکالات نرم افزار کمک کنه، طی بازگشت به نسخه فعلی از بین میرفت. در استراتژی Blue-Green، بازگشت به عقب ( rollback ) همیشه استقرار ناموفق رو برای تجزیه و تحلیل دست نخورده باقی می گذاره.
معایب استراتژی Blue-Green
تجربه سرد کاربران: ممکنه وقتی کاربران به طور ناگهانی به محیط جدید تغییر مکان میبدن، کندی و سردرگمی رو تجربه کنند.
هزینه ها: در مقایسه با روش های دیگه، استقرار Blue-Green گرون تره. تهیه زیرساخت استقرار، بخصوص وقتی چندین بار طی روز بخوایم نسخه جدید رو مستقر کنیم، خیلی بالا میره. چون راه اندازی فرآیند استقرار Blue-Green نیاز به زمان و تلاش داره. این فرآیند پیچیده است و مسئولیت زیادی دارد. ممکن است لازم باشد قبل از اینکه به درستی کار کند، چندین بار تکرار کنیم.
پایگاه‌های داده: انتقال Database سخت‌تره، حتی تا حدی که یک نمایشگر باشد. تغییرات هماهنگی پایگاه داده بین دو نسخه میتونه خیلی پیچیده باشه. مشکل زمانی پیچیده تر میشه که دو پایگاه داده داریم، یکی برای محیط آبی و یکی دیگه برای محیط سبز. sync نگه داشتن داده ها دردسرسازه.
تراکنش های کاربر: در طول جابجایی ترافیک، برخی از transaction های کاربر قطع میشه. چطوری با transaction های نصفه کاره برخورد میکنیم؟ یک راه حل ممکن اینه که همه تراکنش ها رو همزمان به صورت موازی به هر دو محیط انتقال بدیم. بعد از اتمام استقرار، حتما باید دیتابیس رو بررسی کنیم و اگر داده های تکراری پیدا کردیم، براشون راه حل پیدا کنیم.
سرویس‌های مشترک: پایگاه‌های اطلاعاتی و بقیه سرویس‌های مشترک می‌تونن باعث درز اطلاعات محیط های آبی و سبز به همدیگه بشن. خیلی باید محتاط باشیم، در غیر این صورت ممکنه یک محیط به طور غیرمستقیم روی اون یکی تأثیر بگذاره. ترجیحا باید تا جایی که میشه محیط ها رو مستقل و منزوی کنیم.
استراتژی Canary یا همون قناری
استراتژی قناری یکی دیگه از استقرارهای automated محسوب میشه. در این استراتژی برنامه وب تون رو کم کم برای زیرمجموعه ای از کاربران مستقر می کنید. اگر همه چیز خوب پیش رفت، برنامه رو به zone همه کاربران منتقل میکنید. این به شما این امکان را می‌دهد تا عملکرد، بازخورد و تأثیر تغییرات برنامه وب خود را در مقیاس کوچک نظارت و ارزیابی کنید، قبل از اینکه اون ها رو در مقیاس بزرگ‌تر عرضه کنید. این استراتژی حداکثر رضایت کاربر، تضمین کیفیت و اعتبارسنجی ویژگی رو به همراه داره و میتونید هر مشکلی رو زود تشخیص بدید و رفع کنید.
می تونیم از استراتژی Canrary برای انجام تست A/B استفاده کنیم. به عبارت دیگر، با توسعه این زیرساخت، ما میتونیم بیشتر از یک جایگزین رو در اختیار کاربران قرار بدیم و ببینیم که از کدوم نسخه استقبال بهتری میشه.
تست تحمل فشار: آزمایش تحمل فشار یک محیط production بزرگ غیرممکنه. با استقرار یک نمونه از نسخه جدید در محیط های کاملا برابر با production، میتونیم تست های تحمل فشار رو روی نسخه جدید اعمال کنیم. هر گونه مشکل عملکردی که در سیستم خود داشته باشیم با انتقال بخش بخش کاربران به نسخه جدید خودش رو نشون میده.
بازخورد: ما بازخوردهای باارزشی از کاربرهای واقعی دریافت می کنیم.
بدون تجربه سرد کاربران: راه اندازی سیستم های جدید ممکنه کمی طول بکشد. آرام آرام مستقر کردن نسخه های جدید، جلوی تجربه های بد کاربران رو میگیره.
بدون down time: مثل استقرار Blue-Green، استقرار Canary باعث خرابی نمیشه.
بازگشت بی درد سر: اگر مشکلی پیش بیاد، خیلی راحت می توانیم به نسخه قبلی برگردیم.
معایب استراتژی Canary
تجربه بد گروه اول: اولین گروهی که از نسخه جدید استفاده می کنند، به بدترین باگ ها رو برخورد میکنند. علاوه بر این ممکنه بعضی از کاربرها فکر کنند که از اونها به عنوان خوکچه هندی استفاده می‌شده. بهتره سیاست مناسبی اتخاذ کنین که مانع انتقال احساس بد به این کاربرها بشه ( مثلا بهشون احساس برگزیده بودن از بین همه کاربران رو بدید )
هزینه ها: هزینه استقرار نسخه های جانبی خیلی زیاده چون به زیرساخت های اضافی نیاز داریم. میتونیم با استفاده از زیرساخت های آماده از هزینه اضافه کم کنیم.
پیچیدگی: استراتژی Canary به اندازه استقرار Blue-Green پیچیده است. داشتن سرورهای زیاد، مهاجرت کاربرها و نظارت کردن به سیستم جدید وظایف پیچیده ای هستند که به هر قیمتی شده به صورت automated پیاده سازیش کنی نه به صورت دستی. همیشه فرآیند Deployment رو با استفاده از یک پلت فرم CI/CD مثل Semaphore خودکار کنین.
زمان: راه اندازی یک pipeline استقرار Canary سالم به زمان و تلاش نیاز داره. البته که از جنبه مثبتش، وقتیی که درست انجامش بدیم، خیلی به صرفه تره و می‌توانیم استقرارهای مکرر و مطمئن‌تری رو انجام بدیم.
پایگاه های داده: کتاب های کاملی در مورد نحوه ایجاد تغییرات در طرح های پایگاه داده وجود دارند. مشکل اینه که Database باید همزمان با نسخه مستقر شده و نسخه های کنترلی در طول استقرار کار کنه. بنابراین، اگر تغییرات اساسی و ساختاری در Database داشته باشیم، دچار مشکل میشیم. ما باید در حین ایجاد تغییرات، سازگاری با نسخه های قبلی رو هم حفظ کنیم که لایه بیشتری به پیچیدگی ها اضافه نکنیم.
استراتژی A/B testing
استراتژی تست A/B نوعی از استقرار قنارییه که در اون شما دو یا چند نسخه از برنامه وب تون رو برای زیرمجموعه های مختلف کاربران مستقر می کنید و نتایج اون ها رو با هم مقایسه می کنید. این به شما امکان می‌دهد ویژگی‌ها، طرح‌ها یا عملکردهای مختلف برنامه وب تون رو آزمایش کنید و تأثیرشون رو بر رفتار، علاقه و تعامل کاربرها اندازه‌گیری کنید. این امر تاثیر فوق العاده ای روی بهبود تجربه کاربر و نحوه ارائه داده ها داره. نوآوری رو افزایش میده و به شما کمک می کنه تا برنامه وب تون رو قوی تر و موثر تر بهبود بدید.
برای مشاهده پست های بیشتر و ارتباط با من از طریق لینکدین اینجاکلیک کنید.
