تغییر در استراتژی استقرار نرم افزار امروزه جزو بزرگ‌ترین تغییرات تیم‌های نرم افزاری است. تیم های تولید نرم‌افزار، نسخه هایی ازمحصول اولیه را مستقر می‌سازند و اغلب اوقات طی ماه ها یا سال ها چرخه انتشار کند می‌شود اما با استفاده از استراتژی استقرار نرم افزار می‌توان به چرخه انتشار محصول سرعت بخشید.
امروزه با بکارگیری یک معماری سرویس محور و رویکرد میکروسرویس ها، توسعه دهندگان میتوانند کدی بر مبنای ماژولار بودن طراحی کنند. این کار به آنها امکان میدهد تغییرات بر روی بخش های مختلف کد را بشکل همزمان نوشته و مستقر سازند.
با این وجود، این تغییر چالش های جدیدی را نیز پیش روی تیم توسعه عملیات ها قرار میدهد. با استقرار مکررتر، به احتمال زیاد ، کد مستقرشده می تواند بر قابلیت اطمینان سایت یا تجربه مشتری تاثیر منفی بگذارد. از این رو تدوین استراتژی هایی که در استقرار کد ریسک محصول و مشتری را به حداقل رساند از اهمیت برخوردار می‌گردد. در این مقاله ما در مورد تعدادی از استراتژی های استقرار نرم افزار مختلف، تجارب برتر و ابزارهایی که به تیم شما کمک خواهند نمود تا سریعتر و با قابلیت اطمینان بیشتر کار کند صحبت خواهیم کرد.
اپلیکیشن های نوین، اغلب توزیع شده و مبتنی بر ابر هستند. آنها می توانند انعطاف بالایی در مقیاس پذیری داشته و در لحظه به تناسب تقاضای نمود یافته تغییر مقیاس دهند، همچنین به لطف معماری بسیار دسترس پذیر، در مقابل شکست مقاوم ترند. آنها ممکن است از سرویس های کاملا مدیریت شده نظیر AWS Lambda یا Elastic Container Service استفاده کنند که در آن پلتفرم مسئولیت اداره بخشی از عملیات ها را برعهده می‌گیرد.
این اپلیکیشن ها، تقریبا همیشه دارای استقرار مکرر هستند. برای مثال، یک اپلیکیشن موبایل یا اپلیکیشن مبتنی بر وب، ممکن است طی یک ماه چندین تغییر را تحمل کند. برخی از آنها حتی چندین بار در روز استقرار جدید محصول را تجربه میکنند. آنها اغلب معماری های میکرو سرویس را بکار می‌گیرند که در آنها چندین مولفه برای رسیدن به عملکرد کامل باهم همکاری میکنند. چرخه های انتشار مختلف برای مولفه های مختلف میتواند وجود داشته باشد اما همه آنها باید یکپارچه با هم کار کنند.
افزایش تعداد بخش های متحرک به معنای شانس بیشتر بروز خطا در انجام برخی امور است. وقتی چندین تیم توسعه بر روی کد پایه کار میکنند و تغییرات لازم را بر آن اعمال میکنند، تعیین علت اصلی بروز یک مشکل که وقوع آن اجتناب ناپذیر است دشوار خواهد شد. چالش دیگر انتزاع لایه زیرساخت است که اکنون به صورت کد در نظر گرفته می‌شود. استراتژی استقرار نرم افزار جدید ممکن است به استقرار زیرساخت جدید نیز نیاز داشته باشد.
برای مواجهه با این چالش ها تیم های توسعه و زیر ساخت باید یک استراتژی استقرار نرم افزار مناسب تدوین و اتخاذ کنند. ما چندین مورد از این استراتژی ها را مرور نموده و جوانب مثبت و منفی آنها را به بحث خواهیم گذاشت تا شما بتوانید انتخاب کنید کدامیک مناسب سازمان شما می‌باشد.
همانطورکه از نامش مشخص است، استقرارهای بیگ بنگ کل یا بخش های بزرگی از یک اپلیکیشن را در یک حرکت کنار زده و به روز رسانی می‌کند. این استراتژی به روزهایی بر می‌گردد که نرم افزار بر روی رسانه فیزیکی منتشر می‌شد و توسط مشتری نصب می‌گردید. استقرارهای بیگ بنگ، کسب و کارهای حوزه تولید نرم افزار را ملزم به شکل دادن توسعه و تست های گسترده اغلب تحت مدل آبشاری پیش از انتشار محصول می نمود.
اپلیکیشن های نوین از این مزیت برخوردارند که به طور مرتب و خودکار در سمت مشتری یا سرور بروز رسانی میشوند.این امر باعث می‌شود تا رویکرد بیگ بنگ نسبت به تیم های نوین از سرعت و چابکی کمتری برخودار باشد.
از جمله مشخصه های استقرار بیگ بنگ
استراتژی استقرار نرم افزار به روش بیگ بنگ مناسب اپلیکیشن های نوین نیست چون در اپلیکیشن های با کاربری عمومی یا مرتبط با کسب و کارهای حیاتی وجود ریسک ها قابل پذیرش نیست. درجایی که توقف لحظه ای به معنای ضرر بزرگ مالی است و عقبگردها غالبا پرهزینه، زمان بر و حتی غیر ممکن هستند.
رویکرد بیگ بنگ میتواند برای سیستم های غیر Production یا نرم‌افزارهایی که توسط فروشندگان در قالب یک بسته نرم افزاری ارائه میشوند نظیر برنامه های دسکتاپ مناسب باشد. امروزه از این استراتژی به ندرت استفاده می‌شود.
استراتژی استقرار نرم افزار چرخشی، فازی یا مرحله ای از استقرارهای بیگ بنگ بهترند چون بسیاری از ریسک های مربوطه از جمله مواجهه کاربر با خرابی بدون بازگشت آسان را به حداقل می رسانند. دریک استقرار چرخشی، ورژن جدید یک اپلیکیشن به تدریج جایگزین ورژن قدیمی آن می‌گردد. استقرار واقعی دریک دوره زمانی رخ میدهد. طی این دوره ورژن های جدید و قدیمی بدون تاثیر بر عملکرد یا تجربه کاربر همزیستی خواهند نمود. این روند باعث می‌گردد تعویض مولفه های جدید ناسازگار با مولفه های قدیمی ساده تر شود. نمودار زیر الگوی استقرار را نشان میدهد. بر روی هر سرور درخوشه ورژن قدیمی به رنگ آبی و ورژن جدید به رنگ سبز نشان داده شده است.
ارتقاء سلسله وار یک اپلیکیشن، نمونه ای از یک استقرار چرخشی است. اگر اپلیکیشن هh بر روی کانتینر مستقر شده باشند، ارتقاء میتواند در قالب یک کانتینر در هر زمان شکل گیرد. هر کانتینر با دانلود جدیدترین تصویر از ریپازیتوری مجددا راه اندازی می‌شود. اگر مشکلات سازگاری با یکی از ورژن های برنامه وجود داشته باشد، تصویر قدیمی تر میتواند مجددا در قالب کانتینر راه اندازی شود. در این حالت، ورژن های جدید و قدیم از سلسله برنامه ها تا زمانی که هر برنامه ارتقاء داده شود با یکدیگر همزیستی میکنند.
این رویکرد، روند دیگری از مواجه امن با شکست نرم افزار است. در این روش، دو محیط یکسان به صورت موازی کار میکنند. یکی محیط تولید درحال اجرا که تمام ترافیک کاربر را دریافت می‌کند (به رنگ آبی مشخص شده)، دیگری یک clone (همزاد) از آن است اما بیکار است(به رنگ سبز). هر دو از پشتیبانی پایگاه داده و پیکربندی اپلیکیشن یکسان بهره می‌برند.
ورژن جدید نرم افزار در محیط سبز مستقر شده و بر روی آن تست عملکرد و کارایی صورت می‌پذیرد. هنگامی که نتایج تست موفقیت آمیز ارزیابی شد، ترافیک اپلیکیشن از محیط آبی به سبز هدایت می‌گردد. پس از آن نمونه سبز محصول جدید می‌شود. اگر بعد از استقرار در محیط سبز مشکلی بروز کند، ترافیک میتواند به محیط آبی برگشت داده شود.
در یک استراتژی استقرار نرم افزار به روش آبی – سبز هر دو سیستم از یک لایه پایداری و پایگاه داده یکسان استفاده میکنند. حفظ همگام سازی داده های اپلیکیشن ضروری است و یک پایگاه داده Mirror (آینه ای) میتواند کمک کننده باشد. شما می‌توانید پایگاه داده اصلی را بوسیله آبی برای Write عملیات ها در پایگاه داده استفاده کنید و پایگاه داده ثانویه را به وسیله سبز برای خواندن عملیات ها حین جابجایی از آبی به سبز استفاده کنید. اگر سبز نیز حین عملیات تست به نوشتن نیاز داشته باشد، پایگاه های داده میتوانند بصورت دو طرفه تکثیر یابند.
وقتی سبز فعال می‌شود، شما می‌توانید نمونه قدیمی آبی را غیرفعال نموده و یا مجددا به چرخه فعالیت بازگردانید. ممکن است یک ورژن جدیدتر را بر روی آن نمونه مستقر نمایید و به عنوان سبز جدید در انتشار بعدی از آن استفاده نمایید. استقرارهای آبی- سبز بر مسیریابی ترافیک متکی هستند. اینکار را می‌توان با بروز رسانی DNS CNAME ها برای میزبان (host) ها به انجام رساند. با اینحال مقادیر طولانی TTL میتواند این تغییرات را با تاخیر مواجه سازد. بعنوان جایگزین، شما می‌توانید تنظیمات متعادل کننده بار را تغییر دهید تا تغییرات به سرعت اعمال شوند.
استراتژی استقرار نرم افزار به روش قناری مشابه آبی- سبز است جز اینکه با ریسک پذیری بیشتری همراه است. به جای جابجایی از آبی به سبز در یک گام، شما از یک رویکرد مرحله بندی شده استفاده می‌کنید. با استقرار به روش قناری، یک کد جدید را در بخش کوچکی از زیرساخت های Production مستقر می‌کنید. پس از اینکه اپلیکیشن به تایید جهت انتشار دست یافت، تنها عده کمی از کاربران به سمت آن هدایت میشوند. اینکار هرگونه خرابی را به حداقل می‌رساند.
اگر گزارش شود که هیچ خطایی بروز نیافته، ورژن جدید می تواند به تدریج بر باقیمانده زیرساخت گسترش یابد. تصویر زیر نشان دهنده نحوه اجرای استقرار قناری است.
دلیل نام گذاری استراتژی فوق به اسم استقرار قناری، به این دلیل است که در گذشته افرادی که در معدن زغال سنگ کار می‌کردند با استفاده از سروصدای قناری ها، انتشار گازهای سمی را در معدن می‌فهمیدند. به همین دلیل در این استراتژی ابتدا تغییرات جدید را بر روی تعداد اندکی از کاربران تست می‌کنیم و این کاربران همانند سروصدای قناری‌ها، میتوانند مشکلات پیش آمده را به ما نشان دهند.
چالش اصلی استراتژی استقرار نرم افزار به روش قناری تدبیر راهی برای هدایت برخی کاربران به اپلیکیشن جدید است. علاوه بر آن برخی برنامه ها ممکن است همیشه به گروه یکسانی از کاربران برای تست نیاز داشته باشند درحالیکه برخی دیگر در هر زمان به گروه متفاوتی از کاربران احتیاج دارند.
با انتخاب یکی از تکنیک‌های زیر می‌توانید ترافیک کاربر را در استقرار قناری هدایت کنید.
تیم های توسعه‌دهنده و عملیات میتوانند تعدادی از روش‌های برتر را دنبال کنند تا ریسک های استقرار را به حداقل برسانند.
حتی پس از اینکه شما موارد فوق را اتخاذ نمائید ممکن است هنوز استراتژی استقرار نرم افزار برنامه با شکست مواجه شود. به همین دلیل، نظارت بر مواردی که بلافاصله پس از استقرار به وقوع می پیوندد به همان اندازه برنامه ریزی و اجرای یک استقرار کامل مهم است. یک ابزار نظارت بر کارایی اپلیکیشن (Application Performance Monitoring)، می تواند به تیم شما کمک کند تا معیارهای کارایی مهم از جمله زمان پاسخگویی سرور پس از استقرار را نظارت نماید. تغییرات در اپلیکیشن یا معماری سیستم می تواند بطور چشمگیری بر کارایی برنامه تاثیر بگذارد.
یک راه حل نظارت بر خطا نظیر Rollbar بسیار ضروری است. این کار به سرعت تیم شما را از خطاهای جدید یا مجدد فعال شده پس از استقرار مطلع می‌سازد که میتواند اشکالات مهمی که نیاز است فورا به آنها توجه و رسیدگی گردد را کشف نماید. بدون یک ابزار نظارت بر خطا، ممکن است اشکالات هرگز کشف نشوند. درحالیکه عده اندکی از کاربران در مواجهه با این اشکالات زمانی را به گزارش دهی آنها اختصاص میدهند، بیشتر کاربران چنین عمل نمی‌کنند. تجربه منفی مشتری، میتواند به مرور زمان منجر به بروز مشکلات زیادی شود.
یک ابزار نظارت بر خطا یک دید مشترک از همه مسائل پس از استقرار در میان تیم های عملیات (Ops) و توسعه دهندگان (Dev) ایجاد می‌کند. این درک مشترک به تیم ها امکان میدهد پاسخگویی و همکاری بیشتری داشته باشند.
