بهترین روش‌های استقرار نرم افزار

تغییر در استراتژی استقرار نرم افزار امروزه جزو بزرگ‌ترین تغییرات تیم‌های نرم افزاری است. تیم های تولید نرم‌افزار، نسخه هایی ازمحصول اولیه را مستقر می‌سازند و اغلب اوقات طی ماه ها یا سال ها چرخه انتشار کند می‌شود اما با استفاده از استراتژی‌ استقرار نرم افزار می‌توان به چرخه انتشار محصول سرعت بخشید.

امروزه  با بکارگیری یک معماری سرویس محور و رویکرد میکروسرویس ها، توسعه دهندگان می‌توانند کدی بر مبنای ماژولار بودن طراحی کنند. این کار به آنها امکان می‌دهد تغییرات بر روی بخش های مختلف کد را بشکل همزمان نوشته و مستقر سازند.

منافع تجاری چرخه های استقرار کوتاه تر:

• زمان عرضه محصول به بازار کاهش می‌‌یابد.
• مشتریان در زمان کمتری به ویژگی های جدید محصول دست می‌یابند.
• بازخورد مشتری سریعتر به سمت تیم تولید برمیگردد، این به این معناست که تیم می‌تواند بر روی ویژگی های نرم افزار توسعه مکرر داشته و مشکلات موجود در کدها را سریعتر برطرف نماید.
• چرخه‌های تولید کوتاه‌تر باعث افزایش روحیه و دلگرمی توسعه‌دهندگان می‌شود.

با این وجود، این تغییر چالش های جدیدی را نیز پیش روی تیم توسعه عملیات ها قرار میدهد. با استقرار مکررتر، به احتمال زیاد ، کد مستقرشده می تواند بر قابلیت اطمینان سایت یا تجربه مشتری تاثیر منفی بگذارد. از این رو تدوین استراتژی هایی که در استقرار کد ریسک محصول و مشتری را به حداقل رساند از اهمیت برخوردار می‌گردد. در این مقاله ما در مورد تعدادی از استراتژی‌ های استقرار نرم افزار مختلف، تجارب برتر و ابزارهایی که به تیم شما کمک خواهند نمود تا سریعتر و با قابلیت اطمینان بیشتر کار کند صحبت خواهیم کرد.

چالش برنامه‌های نوین

اپلیکیشن های نوین، اغلب توزیع شده و مبتنی بر ابر هستند. آن‌ها می توانند انعطاف بالایی در مقیاس پذیری داشته و در لحظه به تناسب تقاضای نمود یافته تغییر مقیاس دهند، همچنین به لطف معماری بسیار دسترس پذیر، در مقابل شکست مقاوم ترند. آنها ممکن است از سرویس های کاملا مدیریت شده نظیر  AWS Lambda  یا Elastic Container Service استفاده کنند که در آن پلتفرم مسئولیت اداره بخشی از عملیات ها را برعهده می‌گیرد.

 این اپلیکیشن ها، تقریبا همیشه دارای استقرار مکرر هستند. برای مثال، یک اپلیکیشن موبایل یا اپلیکیشن مبتنی بر وب، ممکن است طی یک ماه چندین تغییر را تحمل کند. برخی از آنها حتی چندین بار در روز استقرار جدید محصول را تجربه می‌کنند. آن‌ها اغلب معماری های میکرو سرویس را بکار می‌گیرند که در آنها چندین مولفه برای رسیدن به عملکرد کامل باهم همکاری می‌کنند. چرخه های انتشار مختلف  برای مولفه های مختلف می‌تواند وجود داشته باشد اما همه آنها باید یکپارچه با هم کار کنند.

افزایش تعداد بخش های متحرک به معنای شانس بیشتر بروز خطا در انجام برخی امور است. وقتی چندین تیم توسعه بر روی کد پایه کار می‌کنند و تغییرات لازم را بر آن اعمال میکنند، تعیین علت اصلی بروز یک  مشکل که  وقوع آن اجتناب ناپذیر است دشوار خواهد شد. چالش دیگر انتزاع لایه زیرساخت است که اکنون به صورت کد در نظر گرفته می‌شود. استراتژی استقرار نرم افزار جدید ممکن است به استقرار زیرساخت جدید نیز نیاز داشته باشد.

محبوب ترین استراتژی های استقرار نرم افزار

برای مواجهه با این چالش ها تیم های توسعه و زیر ساخت باید یک استراتژی استقرار نرم افزار مناسب تدوین و اتخاذ کنند. ما چندین مورد از این استراتژی ها را مرور نموده و جوانب مثبت و منفی آن‌ها را به بحث خواهیم گذاشت تا شما بتوانید انتخاب کنید کدامیک مناسب سازمان شما می‌باشد.

استراتژی استقرار بیگ بنگ

همانطورکه از نامش مشخص است، استقرارهای بیگ بنگ کل یا بخش های بزرگی از یک اپلیکیشن را در یک حرکت کنار زده و به روز رسانی می‌کند. این استراتژی به روزهایی بر می‌گردد که  نرم افزار بر روی رسانه فیزیکی منتشر می‌شد و توسط مشتری نصب می‌گردید. استقرارهای بیگ بنگ، کسب و کارهای حوزه تولید نرم افزار را ملزم به  شکل دادن توسعه و تست های گسترده اغلب تحت مدل آبشاری پیش از انتشار محصول می نمود.

اپلیکیشن های نوین از این مزیت برخوردارند که به طور مرتب و خودکار در سمت مشتری یا سرور بروز رسانی می‌شوند.این امر باعث می‌شود تا رویکرد بیگ بنگ نسبت به تیم های نوین از سرعت و چابکی کمتری برخودار باشد.

ازجمله مشخصه های استقرار بیگ بنگ 

• همه قطعات اصلی در یک استقرار بسته بندی شده اند.
• یک نسخه نرم افزار موجود بطور گسترده یا کامل با نرم افزار جدید جایگرین می‌گردد.
• استقرار معمولا حاصل چرخه طولانی مدتی از تست و توسعه است.
• یک شانس حداقلی برای بروز خطا لحاظ می‌گردد چراکه بازگشت به عقب میتواند غیر ممکن یا غیر عملی باشد.
• زمان تکمیل پروژه معمولا طولانی است و می تواند تلاش تیم های متعددی را به همراه داشته باشد.
• چون نصب اپلیکیشن در سمت مشتری صورت گرفته ضرورت دارد اقدام به بروز رسانی از طرف مشتریان انجام شود.

استراتژی‌ استقرار نرم افزار به روش بیگ بنگ مناسب اپلیکیشن های نوین نیست چون در اپلیکیشن های با کاربری عمومی یا مرتبط با کسب و کارهای حیاتی وجود ریسک ها  قابل پذیرش نیست. درجایی که توقف لحظه ای به معنای ضرر بزرگ مالی است و عقبگردها غالبا پرهزینه، زمان بر و حتی غیر ممکن هستند.

رویکرد بیگ بنگ می‌تواند برای سیستم های غیر Production یا نرم‌افزارهایی که توسط فروشندگان در قالب یک بسته نرم افزاری ارائه میشوند نظیر برنامه های دسکتاپ مناسب باشد. امروزه از این استراتژی به ندرت استفاده می‌شود.

استراتژی استقرار چرخشی

استراتژی استقرار نرم افزار چرخشی، فازی یا مرحله ای از استقرارهای بیگ بنگ بهترند چون بسیاری از ریسک های مربوطه از جمله مواجهه کاربر با خرابی بدون بازگشت آسان  را به حداقل می رسانند. دریک استقرار چرخشی، ورژن جدید یک اپلیکیشن به تدریج جایگزین ورژن قدیمی آن می‌گردد. استقرار واقعی دریک دوره زمانی  رخ می‌دهد. طی این دوره ورژن های جدید و قدیمی  بدون تاثیر بر عملکرد یا تجربه کاربر همزیستی خواهند نمود. این روند باعث می‌گردد تعویض مولفه های جدید ناسازگار با مولفه های قدیمی ساده تر شود. نمودار زیر الگوی استقرار را نشان می‌دهد. بر روی هر سرور درخوشه ورژن قدیمی به رنگ آبی و ورژن جدید به رنگ سبز نشان داده شده است.

ارتقاء سلسله وار یک اپلیکیشن، نمونه ای از یک استقرار چرخشی است. اگر اپلیکیشن هh بر روی کانتینر مستقر شده باشند، ارتقاء می‌تواند در قالب یک کانتینر در هر زمان شکل گیرد. هر کانتینر با دانلود جدیدترین تصویر از ریپازیتوری مجددا راه اندازی می‌شود. اگر مشکلات سازگاری با یکی از ورژن های برنامه وجود داشته باشد، تصویر قدیمی تر می‌تواند مجددا در قالب کانتینر راه اندازی شود. در این حالت، ورژن های جدید و قدیم از سلسله برنامه ها تا زمانی که هر برنامه ارتقاء داده شود با یکدیگر همزیستی می‌کنند.

استراتژی استقرار آبی-قرمز یا قرمز-مشکی یا آبی‌-سبز یا A/B

این رویکرد، روند دیگری از مواجه امن با شکست  نرم افزار است. در این روش، دو محیط یکسان به صورت موازی کار می‌کنند. یکی محیط تولید درحال اجرا که تمام ترافیک کاربر را دریافت می‌کند (به رنگ آبی مشخص شده)، دیگری یک clone (همزاد) از آن است اما بیکار است(به رنگ سبز). هر دو از پشتیبانی پایگاه داده و پیکربندی اپلیکیشن یکسان بهره می‌برند.

ورژن جدید نرم افزار در محیط سبز مستقر شده و بر روی آن تست عملکرد و کارایی صورت می‌پذیرد. هنگامی که نتایج تست موفقیت آمیز ارزیابی شد، ترافیک  اپلیکیشن از محیط آبی به سبز هدایت می‌گردد. پس از آن  نمونه سبز محصول جدید می‌شود. اگر بعد از استقرار در  محیط سبز مشکلی بروز کند، ترافیک می‌تواند به محیط آبی برگشت داده شود.

در یک استراتژی استقرار نرم افزار به روش آبی – سبز هر دو سیستم از یک لایه پایداری و پایگاه داده یکسان استفاده می‌کنند. حفظ همگام سازی داده های  اپلیکیشن ضروری است و یک پایگاه داده Mirror (آینه ای‌) می‌تواند کمک کننده باشد. شما می‌توانید پایگاه داده اصلی را بوسیله آبی برای Write عملیات ها در پایگاه داده استفاده کنید و پایگاه داده ثانویه را به وسیله سبز برای خواندن عملیات ها حین جابجایی از آبی به سبز استفاده کنید. اگر سبز نیز حین عملیات تست به نوشتن نیاز داشته باشد، پایگاه های داده می‌توانند بصورت دو طرفه تکثیر یابند.

وقتی سبز فعال می‌شود، شما می‌توانید نمونه قدیمی آبی را غیرفعال نموده و یا مجددا به چرخه فعالیت بازگردانید. ممکن است  یک ورژن جدیدتر را بر روی آن  نمونه مستقر نمایید و به عنوان سبز جدید در انتشار بعدی از آن استفاده نمایید. استقرارهای آبی- سبز بر مسیریابی ترافیک  متکی هستند. اینکار را می‌توان با بروز رسانی DNS CNAME  ها برای میزبان (host) ها به انجام رساند. با اینحال مقادیر طولانی TTL می‌تواند این تغییرات را با تاخیر مواجه سازد. بعنوان جایگزین، شما می‌توانید تنظیمات متعادل کننده بار را تغییر دهید تا تغییرات به سرعت اعمال شوند.

استراتژی استقرار قناری

استراتژی استقرار نرم افزار به روش قناری مشابه آبی- سبز است جز اینکه با ریسک پذیری بیشتری همراه است. به جای جابجایی از آبی به سبز در یک گام، شما از یک رویکرد مرحله بندی شده استفاده می‌کنید. با استقرار به روش قناری، یک کد جدید را در بخش کوچکی از زیرساخت های Production مستقر می‌کنید. پس از اینکه اپلیکیشن به تایید جهت انتشار دست یافت، تنها عده کمی از کاربران به سمت آن هدایت می‌شوند. اینکار هرگونه خرابی را به حداقل می‌رساند.

اگر گزارش شود که هیچ خطایی بروز نیافته، ورژن جدید می تواند به تدریج بر باقیمانده زیرساخت گسترش یابد. تصویر زیر نشان دهنده  نحوه اجرای استقرار قناری است.

دلیل نام گذاری استراتژی فوق به اسم استقرار قناری، به این دلیل است که در گذشته افرادی که در معدن زغال سنگ کار می‌کردند با استفاده از سروصدای قناری ها، انتشار گازهای سمی را در معدن می‌فهمیدند. به همین دلیل در این استراتژی ابتدا تغییرات جدید را بر روی تعداد اندکی از کاربران تست می‌کنیم و این کاربران همانند سروصدای قناری‌ها،‌ می‌توانند مشکلات پیش آمده را به ما نشان دهند.

چالش اصلی استراتژی استقرار نرم افزار به روش قناری تدبیر راهی برای  هدایت برخی کاربران به  اپلیکیشن جدید است. علاوه بر آن برخی برنامه ها ممکن است همیشه به گروه یکسانی از کاربران برای تست نیاز داشته باشند درحالیکه  برخی دیگر در هر زمان به گروه متفاوتی از کاربران احتیاج دارند.

با انتخاب یکی از تکنیک‌های زیر می‌توانید ترافیک کاربر را در استقرار قناری هدایت کنید.

• ابتدا کاربران داخلی وارد استقرار قناری شوند و سپس کاربران خارجی
• مسیریابی ترافیک بر مبنای محدوده IP کاربران
• انتشار اپلیکیشن در نواحی جغرافیایی خاص
• به کارگیری یک منطق به منظور فعال کردن ویژگی های جدید برای کاربران یا گروه های خاص. این منطق هنگامی که برنامه برای باقیمانده کاربران نیز فعال می‌شود حذف می‌گردد.

بهترین روش‌های استراتژی استقرار نرم افزار

تیم های توسعه‌دهنده و عملیات می‌‌توانند تعدادی از روش‌های برتر را دنبال کنند تا ریسک های استقرار را به حداقل برسانند.

• استفاده از یک چک لیست استراتژی استقرار نرم افزار: برای مثال یک آیتم درچک لیست ممکن است تنها بعد از اینکه سرویس های اپلیکیشن متوقف شدند، به منظور پیشگیری از تخریب داده، از کل پایگاه داده پشتیبان گیری نماید.
• ادغام مداوم (Continuous Integration): مکانیزم CI تضمین می‌کند کد merge شده در انشعاب یک مخزن کد تنها بعد از بررسی یک سری وابستگی ها، تست های واحد و بیلد موفق با انشعاب اصلی ادغام می‌گردد. اگر خطایی در طول مسیر وجود داشته باشد فرآیند شکست می‌خورد و تیم برنامه نویسی مطلع می‌گردد. بنابراین استفاده از CI به این معناست که هر تغییری در برنامه پیش از استقرار تست شده است. نمونه هایی از ابزارهای CI عبارتند از : CircleCI و Jenkins
• تحویل مداوم (Continuous Delivery) :  با مکانیزم CD، کد نهایی مرحله قبل، بسته بندی شده و همواره آماده استقرار در یک یا چند محیط است. Gitlab CI/CD از چنین ابزارهایی هست.
• استفاده از محیط های عملیاتی استاندارد (SOE ها):  برای اطمینان از ثبات محیط می‌توانید از ابزارهایی نظیر Vagrant  و Packer برای محیط‌های توسعه و سرورها استفاده کنید.
• استفاده از ابزارهای خودکار برای ساخت محیط ها: با استفاده از این ابزارها، به راحتی می‌توانید یک زیرساخت را با یک کلیک، ازبین ببرید و از نو بسازید. CloudFormation نمونه ای از چنین ابزارهایی است. 
• استفاده از ابزارهای مدیریت پیکر بندی:  نظیر Puppet ،Chef یا  Ansible در سرور ها برای اعمال خودکار تنظیمات سیستم عامل، اجرای  وصله ها (patches) یا نصب نرم افزار.
• استفاده از کانال های ارتباطی :  نظیر Slack  برای اعلان های خودکار از بیلد های ناموفق و  شکست های  اپلیکیشن
• ایجاد فرآیندی برای  هشدار دهی به  تیم مسئول استقرار ها پیرامون بروز خطا:  در حالت ایده آل این موارد را در محیط های CI  بدست خواهید آورد اما اگر این تغییرات استقرار یابند شما به راهی برای اطلاع رسانی به تیم مسئول نیاز خواهید داشت.
• فعال سازی بازگشت به عقب های خودکار برای استقرارها: که بواسطه  بروز مشکلات پیرامون دسترس پذیری به سرویس، نرم‌افزار به آخرین نسخه ی خود rollback می‌شود.

مانیتورینگ پس از استقرار

حتی پس از اینکه شما موارد فوق را اتخاذ نمائید ممکن است هنوز استراتژی استقرار نرم افزار برنامه با شکست مواجه شود. به همین دلیل، نظارت بر مواردی که بلافاصله پس از استقرار به وقوع می پیوندد به همان اندازه برنامه ریزی و اجرای یک استقرار کامل مهم است. یک ابزار نظارت بر کارایی اپلیکیشن (Application Performance Monitoring)، می تواند به تیم شما کمک کند تا معیارهای کارایی مهم  از جمله زمان پاسخگویی سرور پس از استقرار را نظارت نماید. تغییرات در اپلیکیشن یا معماری سیستم می تواند بطور چشمگیری بر کارایی برنامه تاثیر بگذارد.

یک راه حل نظارت بر خطا نظیر Rollbar بسیار ضروری است. این کار به سرعت تیم شما را از خطاهای جدید یا مجدد فعال شده پس از استقرار مطلع می‌سازد که می‌تواند اشکالات مهمی که نیاز است فورا به آنها توجه و رسیدگی گردد را کشف نماید. بدون یک ابزار نظارت بر خطا، ممکن است اشکالات هرگز کشف نشوند. درحالیکه عده اندکی از کاربران در مواجهه با این اشکالات زمانی را به گزارش دهی آنها اختصاص میدهند، بیشتر کاربران چنین عمل نمی‌کنند. تجربه منفی مشتری، می‌تواند به مرور زمان منجر به بروز مشکلات زیادی شود.

یک ابزار نظارت بر خطا یک دید مشترک از همه مسائل پس از استقرار در میان تیم های عملیات (Ops) و توسعه دهندگان (Dev) ایجاد می‌کند. این درک مشترک به تیم ها امکان می‌دهد پاسخگویی و همکاری بیشتری داشته باشند.