بایگانی‌ها Continuous Delivery - سلام دواپس

اکتبر 29, 2017مارس 31, 2020

چارچوب CALMS در DevOps چیست و چه کمکی می کند؟

پایه و اساس DevOps ، تغییر است. Keep CALMS !

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

کافی است تا عبارت “DevOps” را در google جستجو کنید تا دیاگرام ها و متدولوژی های بسیاری را پیدا کنید که هر کدام از آن ها جنبه ی متفاوتی را برجسته کرده اند. اما می توان گفت که همه ی آن ها در موارد زیر با هم مشترک اند:

فرهنگ سازی | Culture
خودکارسازی | Automation
تفکر ناب | Lean thinking
اندازه گیری همه چیز | Measurement
اشتراک گذاری | Sharing

به این چهار مورد اصول یا چارچوب CALMS در DevOps می گویند.

چارچوب CALMS در DevOps چیست ؟

چارچوب CALMS را می توان در پنج واژه ی فرهنگ سازی، خودکارسازی، تفکر ناب، اندازه گیری و اشتراک گذاری برشمرد. (این موضوع در برخی مطالب با عنوان “اصول CALMS در DevOps چیست” مطرح شده است که چارچوب صحیح تر است، در آینده در مطلبی جداگانه اصول DevOps را معرفی خواهم کرد)

Culture | فرهنگ

همه میدانیم فرهنگ چیزی نیست که یک نفر بتواند آن را پیاده سازی کند. فرهنگ در یک محیط طبیعی که شامل سرتاسر تیم تولید نرم افزار می شود وجود دارد. منظور از سرتاسر همه ی افراد است از جمله توسعه دهندگان (Development)، تضمین کنندگان کیفیت (QA) و تیم های عملیات (Operation) و … . در چنین اکوسیستمی که متشکل از مجموعه ای از افراد و ابزارها است، برای رفع موانع و تسهیل همکاری برای دستیابی به اهداف نهایی، یک کار فرهنگی لازم است.

هیچ چیز زشت درباره فرهنگ وجود ندارد.

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

Automation | خودکارسازی :

هنگامی که فرهنگ سازی در سازمان انجام شد، می توانید بر خودکارسازی یا اتوماسیون تمرکز کنید. اتوماسیون تنها به نوشتن Script ها و استفاده از Unit Test ها یا Functional Test ها محدود نمی شود. خودکارسازی شامل همه قسمت ها از جمله Continuous-Integration ، Continuous-Delivery/Deployment، Infrastructure-Automation و هر جای دیگری می شود.

با راه اندازی Automation می توانید برای همه چیز برنامه ریزی کنید.

فرایند های دستی بسیار کند و مستعد خطای انسانی هستند. راهی برای رهبری تمامی ابتکارات جدید به وسیله اتوماسیون پیدا کنید و برای رسیدن به مقیاس های بزرگتر به طور مستمر به اتوماسیون فکر کنید.

Lean | ناب:

بعد از راه اندازی اتوماسیون، به یاد داشته باشید که همچنان ناب بمانید و اصول تولید ناب نرم افزار را رعایت کنید.

اجرای Lean به معنی نگه داشتن همه چیز در حداقل است.

ابزارها، جلسات و حتی iteration ها و همه چیز دیگر باید Lean باشد یعنی در حداقل ممکن باشد. تفکر ناب یعنی ارزش محور بودن فعالیت ها و کاهش فعالیت های اضافه و در حداقل نگه داشتن همه چیز. این هم بخشی از فرهنگ DevOps است. وقتی شما ناب هستید، برای هر ابزار، و روشی که انتخاب می کنید، هدفی دارید.

ناب بودن تنها به یک یا چند فرد محدود نمی شود و شامل همه ی تیم ها و افراد می شود.

باید تیم را در اندازه ای نگه داشت که بیشترین کارایی را داشته باشد. یک آشپزخانه با آشپزهای بیش از حد، بازده کمی خواهد داشت. اگر پیچیدگی اپلیکیشن به گونه ای باشد که نیاز به تیم های بزرگ باشد، تیم را به زیرگروه های کوچکتر تقسیم کنید، همانطور که سازمان های بزرگ این کار را می کنند. (spotify یکی از موفق ترین مثال ها در این زمینه است)

Measurement | اندازه گیری :

اندازه گیری مانند چسبی است که همه چیز را در کنار هم قرار می دهد. زمانی شما یک سازمان چابک و ناب هستید که همه چیز را اتوماتیک می کنید، ممکن است که توانایی به خاطر سپردن و مستند سازی را از دست بدهید.

اگر تیمی در همه موارد شفافیت لازم را نداشته باشد و کارها اندازه گیری نشوند، در نهایت اشتباهات بزرگی رخ خواهد داد.

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

با این وجود نمی توانید با یک excel ساده این کار را انجام داد. در یک سازمان ناب، شما فرصت ندارید که همه چیز را به صورت دستی و غیر اتوماتیک ثبت کنید. این کار بسیار زمان گیر و مستعد خطای انسانی است.

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

Sharing | به اشتراک گذاری :

بعد از آنکه داده ها را جمع آوری کردید، باید اشتباهات و نحوه ی جلوگیری از آن و دانش جدیدی که از این راه بدست آوردید را منتشر کنید.

ایجاد جریان اطلاعات دوطرفه یکی از مزیت های شکستن دیوار بین تیم ها می باشد و باعث جلوگیری از انداختن توپ در زمین تیم دیگر می شود. با این وجود اگر اطلاعات به صورت proactive و فعالانه به اشتراک گذاشته نشوند، ارزشی نخواهند داشت.

Sharing و Reporting کاملا با هم متفاوت هستند، Sharing تنها گزارش واقعیات نیست، بلکه مبادله ی ایده ها در سر تا سر تیم ها و به طور دائمی است. Reporting معمولا به صورت انفعالی (reactive) اتفاق می افتد در حالی که Sharing به صورت فعالانه و proactive می باشد.

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

چارچوب CALMS در DevOps برای آزادسازی خلاقیت ها است نه ردیابی عملکرد افراد

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

چیزی که در توصیف CALMS از DevOps منحصر به فرد است، تاکید بر بعد فرهنگی DevOps است.

از CALMS برای رها سازی جهت بروز خلاقیت ها استفاده کنید، نه برای ردیابی عملکرد افراد

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

CALMS یک نقشه راه است، نه تعریف تمامی گام ها و جزئیات لازم برای رسیدن به هدف، پس به یاد داشته باشید که به تنهایی کافی نیست.

برخی از موارد که در چارچوب CALMS به آن اشاره نشده است

داشتن iteration و ضرب آهنگ منظم و همچنین نتیجه گرا بودن، از موارد مهمی هستند که در CALMS به آن ها اشاره نشده است و می تواند مکمل CALMS باشند. از موارد دیگری که در CALMS به آن اشاره نشده، Security و امنیت محصول است، اما قطعا DevOps امنیت محصول را بهبود می دهد. تمامی موارد اشاره شده شامل بعد فرهنگی و فناوری می باشند.

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

این تمرین مهم است نه به این دلیل که CALMS باید به یک استاندارد تبدیل شود یا نه، به این دلیل که زمانی که جنبش های جدیدی به وجود می آیند (مانند جنبش DevOps)، باید مسیری از عادت به عملکرد فعالانه وجود داشته باشد. CALMS به کسانی که با Operations زندگی کرده اند و همچنین کسانی که حتی نمی دانند Operations چیست کمک می کند.

تفاوت CALMS و ITSM

کسانی است که با ITSM آشنایی دارند ممکن است دچار این چالش ذهنی بشوند که تفاوت DevOps و ITSM چیست؟ آیا DevOps یک راهکار جایگزین برای ITSM است؟

اگر با مشاهده مثال ها و اسناد ITSM تفاوت ها به وضوح مشخص نبود، کلمه ی اختصاری CALMS در یک نگاه سریع به تشریح تفاوت های این روش ها کمک می کند. همانطور که مشاهده می کنید، فرهنگ اولین گام است، با مشاهده گزینه های بعدی، به سرعت مشخص می شود که نمی توان هیچ مقایسه ی مورد به موردی برای ITSM و DevOps داشت.

ITSM به طور کلی بر مستندسازی، کنترل تغییرات، و تکرارپذیری تمرکز دارد، در حالی که DevOps بر افرادی که این نتایج را بدیت می آورند تمرکز دارد. یک مولفه اصلی در ITSM، تکرارپذیر بودن است، اما ساختار و فرایند ها اهداف اصلی نیستند.

جولای 23, 2017مارس 31, 2020

استراتژی پیشرفته استقرار نرم افزار | Advanced Software Deployment Strategy

در این مطلب قصد دارم به استراتژی های پیشرفته ی استقرار نرم افزار که در Continuous Deployment و DevOps کاربرد فراوانی دارند، بپردازم. در پست قبلی به تعریف استراتژی و استراتژی استقرار نرم افزار پرداختیم، همچنین دو تا از استراتژی های پایه استقرار نرم افزار (Recreate Deployment و Rolling Deployment) را معرفی و بررسی کردیم.

Blue-Green Deployment Strategy

Blue-Green Deployment یکی دیگر از استراتژی های استقرار است که به طور خلاصه شامل نگه داشتن همزمان دو نسخه از سرویس در محیط عملیاتی می شود که ریسک انتشار را به شدت کم می کند. نسخه قبلی (Blue) و نسخه ای که جدیدا منتشر شده و در دسترس قرار گرفته (Green). این روش معمولا از یک load balancer برای هدایت ترافیک به نسخه ی green می شود. اگر Monitoring یک رخداد (Incident) را شناسایی کرد، ترافیک به طور اتوماتیک به نسخه ی قبلی یعنی blue هدایت خواهد شد.

هدف Blue-Green Deployment ، حذف DownTime و کاهش ریسک های ناشی از Deployment وامکان Rollback بسیار سریع است.

روش انجام Blue-Green Deployment: در این روش علاوه بر محیط عملیاتی (سبز)، یک محیط کاملا مشابه اما جداگانه وجود دارد(آبی). نسخه ی قدیم اپلیکیشن در محیط سبز نصب شده و 100% از ترافیک عملیاتی به این محیط هدایت می شود. نسخه ی جدید اپلیکیشن روی محیط آبی نصب، راه اندازی و تست می شود، سپس در یک لحظه 100% از ترافیک عملیاتی به محیط آبی هدایت می شود. در این روش در هر زمان تنها یکی از نسخه ها عملیاتی است و نسخه ی دیگر غیر فعال است.

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

مثال: شکل زیر نشان دهنده ی این استراتژی به صورت کلی است.
مرحله اول: 100% ترافیک عملیاتی به محیط آبی که نسخه ی قدیمی در آن نصب شده هدایت می شود و نسخه ی جدید در محیط آبی نصب و راه اندازی می شود.
مرحله دوم: بعد از راه اندازی کامل نسخه ی جدید در محیط آبی، 100% ترافیک عملیاتی به محیط آبی هدایت می شود.

استراتژی قناری | Canary Deployment Strategy

انتخاب این نام از داستان “قناری در معدن زغال سنگ” گرفته شده است. در گذشته معدنچیان با خود یک قناری در قفس به معدن می بردند، در چنین شرایطی اگر میزان گازهای سمی (متان یا مونو اکسید کربن) در معدن به حدی برسد که برای انسان خطر جدی ایجاد کند، قناری جان خود را از دست می داد و بدین ترتیب معدن چیان از وجود گازهای سمی باخبر می شدند.

روش انجام Canary Deployment: در استراتژی استقرار به روش قناری، نسخه ی جدید اپلیکیشن روی تعداد کمی از نودهای عملیاتی منتشر می شود و درصد کمی از ترافیک عملیاتی به نسخه ی جدید هدایت می شود. در این روش دو نسخه قدیم و جدید به طور همزمان عملیاتی هستند. نسخه ی جدید، نقش یک قناری را بازی می کند تا بدون اینکه ریسکی متوجه اکثریت کاربران شود، متوجه شویم که وضعیت در عملیات چطور خواهد بود (از نظر integration با سایر اپلیکیشن ها، CPU، Mamory، disk Usage و …). در صورت رضایت بخش بودن می توان سایر نود ها را هم به روزرسانی کرد، در غیر اینصورت می توان تصمیم به fail کردن استقرار یا Rollback گرفت.

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

Dark Launch Strategy

Dark launching فرایندی است که در آن Featureهای جدید نرم افزار به نحوی تدریجی یا مخفیانه ریلیز می شود و در یک زمان مشخص، یا برای گروه های کاربری مشخصی، فعال و قابل استفاده می شود. با این روش می توان بازخورد بخشی از کاربران را دریافت کرد و در محیط عملیاتی بدون اینکه اکثر کاربران تحت تاثیر قرار گیرند، Performance Test انجام داد. با این روش دیگر نیازی نیست که انتشار Feature های تکمیل شده به دلیل یک یا چند Feature تکمیل نشده به تعویق بیافتد و می توان کدهای تکمیل نشده را (با در نظر گرفتن ملاحظاتی) بدون تاثیر در عملکرد کلی اپلیکیشن منتشر کرد.

روش انجام Dark Launch Strategy: این کار با به کارگیری یک تکنیک در توسعه نرم افزار به نام Feature Flag یا Feature Toggle انجام می شود. در این تکنیک، پیکربندی هایی برای هر Feature یا مجموعه ای از آن ها افزوده می شود، همچنین تکه کدهایی در ابتدای هر ویژگی استفاده می شود که با توجه به پیکربندی، آن ویژگی را در زمان خاصی، یا برای گروهی از کاربران فعال می کند.

Google، Facebook، و بسیاری از غول های فناوری اطلاعات برای ریلیز تدریجی و تست ویژگی های جدید توسط گروه کوچکی از کاربرانشان، از Dark Launching استفاده می کنند. بدین ترتیب قبل از ریلیز عمومی، این فرصت را پیدا می کنند تا میزان علاقه ی کاربران را شناسایی کنند و همچنین تاثیر تغییرات جدید را روی کارایی کل سیستم اندازه گیری کنند. ابزاری که Facebook برای این کار استفاده می کند، “Gatekeeper” نام دارد.

A/B Deployment Strategy

به این معنی است که دو (یا چند) نسخه مختلف از اپلیکیشن/کانفیگ به طور همزمان به منظور تست در حال اجرا باشند. آسان ترین راه استفاده از این روش، تقسیم ترافیک عملیاتی بین دو شاخه همگن (شاخه A و شاخه B) می باشد به طوری که در شاخه A، نسخه ی یکسانی از اپلیکیشن و کانفیگ ها وجود داشته (نسخه A) باشد و در نودهای شاخه ی دیگر، یک نسخه ی دیگر (نسخه B).

یک مثال پیچیده تر شامل یک proxy یا load-balancer تخصصی که ترافیک را بر اساس کاربران یا اپلیکیشن ها بین شاخه های A و B تقسیم می کند. تمامی تستر ها به شاخه B هدایت می شوند و سایر کاربران به شاخه A.

A/B Deployment می تواند به عنوان A/B Testing در نظر گرفته شود، اگر چه یک استقرار A/B نشان دهنده چندین نسخه از کد و پیکربندی است، در صورتی که A/B Testing اعلب از یک کد با چک های خاص برنامه تشکیل شده است.

چه موقع از A/B Deployment استفاده کنیم ؟

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

جولای 10, 2017مارس 31, 2020

استراتژی استقرار نرم افزار | Software Deployment Strategy

در این مطلب به ابتدا به تعریف استراتژی (Strategy)، استقرار نرم افزار (Software Deployment) اشاره شده و در ادامه دو تا از استراتژی های پایه استقرار نرم افزار معرفی و بررسی شده است.

در این صفحه به مطالب زیر می پردازیم :

استراتژی چیست ؟ | What is Strategy ?
دیپلویمنت چیست ؟ | What is Deployment ?
استقرار نرم افزار | Software Deployment
استراتژی استقرار نرم افزار چیست ؟ | What is Software Deployment Strategy ?
اهداف استراتژی های استقرار نرم افزار کدامند ؟
معایب استقرار به روش های قدیمی چیست ؟
رانش پیکربندی چیست ؟ | What is Configuratoin Drift ؟
Immutable Server چیست ؟
استراتژی های پایه استقرار نرم افزار
- Recreate Deployment Strategy
  - چه موقع از Recreate Deployment استفاده کنیم ؟
- Rolling Deployment Strategy
  - چه موقع از Rolling Deployment استفاده کنیم ؟

در مطلب بعدی موارد زیر معرفی و بررسی خواهند شد

استراتژی های پیشرفته استقرار نرم افزار
- Canary Deployment Strategy
- Blue-Green Deployment Strategy
- Dark Launch Strategy
- A/B Deployment Strategy

استراتژی چیست ؟ | What is Strategy ?

تعاریف مختلفی از استراتژی وجود دارد اما به نظرم سه تعریف زیر در کنار هم دید خوبی از مفهوم استراتژی به ما می دهد.

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

همانطور که از تعاریف مشخص است، استراتژی برنامه ای با جزئیات دقیق و کاملا قابل پیش بینی نیست. تاکید یک استراتژی خوب بر آن است که در برخی از توانایی های رقابتی خاص پیشرفت حاصل شود. برای دستیابی و رسیدن به اهداف یک استراتژی، نیاز است برنامه هایی (Plans) قابل پیش بینی و با جزئیات، تعریف و اجرا شود.

دیپلویمنت چیست ؟ | What is Deployment ?

دیپلویمنت یعنی گسترش دادن، استفاده، یا سازماندهی برای رسیدن آگاهانه به یک هدف. (Merrian Webster – Definition of Deploy)

استقرار نرم افزار چیست ؟ | What is Software Deployment ?

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

(در ادامه ی این متن، از واژه ی “استقرار” به جای “Software Deployment” یا “استقرار نرم افزار” استفاده شده است.)

استراتژی استقرار نرم افزار چیست ؟ | What is Software Deployment Strategy ؟

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

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

اهداف استراتژی های استقرار نرم افزار کدامند ؟

از جمله اهدافی که استراتژی های استقرار به دنبال دستیابی به آن ها هستند، می توان به این موارد اشاره کرد:

به حداقل رساندن DownTime یا به صفر رساندن آن
کاهش ریسک ناشی از استقرار
کاهش ریسک عملیاتی کردن نسخه ی جدید
شناسایی سریع مشکلات نسخه ی جدید بعد از عملیاتی شدن
سرعت بخشیدن به امکان Rollback به نسخه ی قبلی

معایب استقرار به روش های قدیمی چیست ؟

استفاده از روش های استقرار قدیمی و غیر اتوماتیک در نگهداری سرور ها و استفاده از آن ها برای مدت زمان طولانی (چندین ماه یا چند سال) باعث مشکلات زیادی می شود. حتی اگر شما تمامی patch ها و update ها را به درستی روی سرور و اپلیکیشن نصب کرده باشید، بعد از مدتی با یک سرور حساس و شکننده با پیکربندی منحصر به فرد مواجه خواهید شد که نمی توانید آن را تعویض کنید یا سروری مشابه آن ایجاد کنید. (به چنین سروهایی در اصطلاح “Snowflake Servers” می گویند). دلایل مختلفی وجود دارد که نیاز می شود یک سرور جدید راه اندازی کنید، از جمله تغییر دیتاسنتر، اضافه کردن سرورهای fail-over، اضافه کردن سرور برای مقیاس پذیری بیشتر، مشکلات امنیتی و … که در چنین شرایطی امکان آن وجود نخواهد داشت یا با ریسک بسیار بالا و صرف زمان زیادی همراه خواهد بود.

رانش پیکربندی چیست ؟ | What is Configuratoin Drift ؟

از اصطلاح Configuration Drift یا “رانش پیکربندی” مواقعی استفاده می شود که تغییرات پیکربندی به صورت موردی، با توجه کم و بدون مستند سازی روی سرورها اعمال می شود عملا سرور را به یک سرور منحصر به فرد تبدیل می کند که محدودیت ها و مشکلاتی را به همراه خود دارد.

برخی از این مشکلات که در بالا اشاره شد، با به کار گیری ابزارهای مدیریت پیکربندی نظیر Chef و Puppet و Ansible برطرف می شوند. اگر پیکربندی ها با استفاده از این ابزارها انجام شود، از پدیده ی Configuration Drift جلوگیری می شود. اما نکته ی مهم این است که در این روش تنها پیکربندی هایی که صراحتا از طریق ابزار اعمال شده انجام خواهد شد و اگر مواردی خارج از آن به محیط یا سرور اعمال شود، ابزار مطلع نمی شود.

Immutable Server چیست ؟

استراتژی ای وجود دارد که در آن به صورت دوره ای سرورها را حذف مب کنند و یک سرور جدید به جای آن ایجاد می کنند و با استفاده از ابزارهایی که در بالا معرفی شد، به صورت اتوماتیک، پیکربندی می کنند. این کار باعث جلوگیری از Configuration Drift می شود. با این روش، با هر تغییر در پیکربندی، بلافاصله قادر به راه اندازی یک سرور جدید خواهیم بود. این استراتژی با نام Immutable Server شناخته می شود از رانش پیکربندی و Snowflake Server ها جلوگیری می کند. از این استراتژی می توان در کنار Recreate Deployment Strategy که در ادامه توضیح خواهم داد استفاده کرد.

انواع استراتژی استقرار نرم افزار | Deployment Strategies

در ادامه به معرفی استراتژی های پایه استقرار نرم افزار می پردازیم. در مطلب بعدی “استراتژی های پیشرفته استقرار نرم افزار” را بررسی خواهم کرد. لازم به ذکر است که این استراتژی ها را می توان با هم ترکیب کرد و استراتژی جدیدی ایجاد کرد. در ادامه مطالب زیر بررسی خواهد شد :

استراتژی های پایه استقرار نرم افزار
- Recreate Deployment Strategy
  - چه موقع از Recreate Deployment استفاده کنیم ؟
- Rolling Deployment Strategy
  - چه موقع از Rolling Deployment استفاده کنیم ؟
استراتژی های پیشرفته استقرار نرم افزار (در پست بعدی معرفی و بررسی خواهند شد)
- Canary Deployment Strategy
- Blue-Green Deployment Strategy
- Dark Launch Strategy
- A/B Deployment Strategy

Recreate Strategy | Recreate Deployment

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

این استراتژی به دلیل اینکه در یک بازه زمانی هیچ نمونه ای از اپلیکیشن در حال اجرا و سرویس دهی نیست، منجر به DownTime خواهد شد. درنتیجه برای محیط های عملیاتی مناسب نیست.

چه موقع از Recreate Deployment استفاده کنیم ؟

زمانی که قبل از راه اندازی نسخه ی جدید، نیاز است یک مهاجرت ( Migration ) در سطح دیتا یا سرور انجام شود
زمانی که نیازی نیست تا نسخه های جدید و قدیم اپلیکیشن به طور همزمان با هم کار کنند
زمانی که از یک RWO volume ای استفاده می کنید که قابلیت به اشتراک گذاری بین چند نسخه را ندارد [openshift.org]

مثال: در شکل زیر مراحل انجام این روش برای محیطی با سه نود نمایش داده شده است.

مرحله اول: قبل از شروع کار، ترافیک به سرور که نسخه ی قدیمی اپلیکیشن را دارد، هدایت می شود.

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

مرحله سوم: همه ی نودها به روزرسانی شده اند و به مدار باز میگردند.

Rolling Strategy | Rolling Deployment

Rolling Deployment یکی دیگر از استراتژی های پایه استقرار نرم افزار است و هدف آن به حداقل رساندن یا حذف DownTime و کم کردن ریسک های وابسته به استقرار می باشد. Rolling Deployment برای محیط هایی عملیاتی که نیاز است به روزرسانی در آن ها بدون DownTime انجام شود، مناسب است. این استراتژی معمولا در محیط هایی با تعداد نود(سرور)های زیاد به کار گرفته می شود و برخلاف برخی دیگر از استراتژی ها نیاز به منابع اضافه ندارد و با استفاده از سرورها و منابع جاری قابل اجرا است.

روش انجام Rolling Deployment : در این روش یکی از (یک گروه از) نودها از دسترس خارج شده و نسخه ی جدید اپلیکیشن با نسخه ی قبلی جایگزین می شود، سپس ترافیک عملیات به آن هدایت می شود و نوبت به نود بعدی می رسد. این کار تا به روزرسانی همه ی نود ها ادامه می یابد.

مثال: در شکل زیر مراحل انجام این استراتژی برای محیطی با سه نود (سرور) نشان داده شده است. این مثال یک محیطی با عملیاتی است که ترافیک ورودی توسط یک Router یا Load-Balancer به سرورهای مشابه هدایت می شوند.

مرحله صفر : قبل از شروع کار، ترافیک به هر سه سرور که نسخه ی قدیمی اپلیکیشن را هاست کرده اند، هدایت می شود.

مرحله اول: یکی از نود ها از مدار خارج می شود و از آن پس ترافیک عملیاتی به سمت آن هدایت نمی شود. در همین حین نودی که از مدار خارج شده، به روزرسانی می شود.

مرحله دوم: نودی که به روزرسانی شده به مدار باز میگردد و نود دیگری از مدار خارج و به روزرسانی می شود.

مرحله سوم: مرحله دوم برای تمامی نودهای باقیمانده (در اینجا یک نود) تکرار می شود.

مرحله چهارم: در این مرحله تمامی نودها به مدار بازگشته و ترافیک به آن ها هدایت می شود.

چه موقع از Rolling Deployment استفاده کنیم ؟

زمانی که میخواهیم در حین استقرار یا به روزرسانی اپلیکیشن، DownTime نداشته باشیم
زمانی که اپلیکیشن می تواند به طور همزمان با نسخه ی جدید و قدیم کار کند

استفاده از این روش به این معنی است که اپلیکیشن باید بتواند با نسخه ی قدیم و جدید به طور همزمان کار کند. در این روش ممکن است دیتایی توسط نسخه ی جدید ذخیره شود و توسط نسخه ی قدیمی خوانده شود (و بالعکس). در نتیجه اپلیکیشن باید به گونه ای طراحی شده باشد تا بدون اینکه مشکلی پیش بیاید این کار را انجام دهد. این موضوع در جاهای مختلفی باید رعایت شود، از جمله برای دیتاهایی که در فایل ذخیره می شوند، دیتاهایی که در پایگاه داده ذخیره می شوند، دیتاهایی که به طور موقت در cache ذخیره می شوند، یا دیتاهایی که سمت کلاینت و در مرورگر کاربران ذخیره می شوند. نکته ای بسیار مهم که در به کارگیری این روش وجود دارد این است که اپلیکیشن برای این کار تست باید طراحی و تست شده باشد.

جمع بندی

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

امیدوارم این مطب مورد استفاده شما دوستان واقع شده باشه. در مطلب بعدی که سعی میکنم کمتر از یک هفته دیگه منتشر کنم، استراتژی های پیشرفته ی استقرار نرم افزار که در Continuous Deployment و DevOps کاربرد دارند را بررسی خواهم کرد.

ژوئن 24, 2017مارس 31, 2020

دوآپس و تصورات اشتباه درباره DevOps

دوآپس و تصورات اشتباه درباره آن | DevOps Misundrestandings

تصورات اشتباه و کج فهمی ها درباره دوآپس ( DevOps )

دنیای فناوری اطلاعات با سرعت و شتاب زیادی در حال تغییر است و هر روز واژه های جدیدی در حال شکل گرفتن است، با این وجود شاید عجیب نباشد که درک های نادرست و کج فهمی هایی از این واژه ها ایجاد شود. واژه DevOps / دوآپس (که اولین بار در کنفرانس Agile 2008 مطرح شد) هم از این قاعده مستثنی نبوده. از این رو سوالات زیادی درباره اینکه واقعا دوآپس چیست مطرح می شود. در این مطلب سعی کردم به طور خلاصه به برخی از تصورات اشتباه درباره DevOps بپردازم. در پست های آینده، به طور مفصل تری به “انواع روش های اشتباه اجرا و استقرار دوآپس در سازمان ها” خواهم پرداخت.

DevOps چیست ؟

بیشتر از آنکه روی پاسخ سوال “DevOps چیست ؟” توافق وجود داشته باشد، روی سوال “DevOps چه نیست ؟” وجود دارد. در ادامه بیشتر به این مطلب خواهم پرداخت
در ادامه مطالب زیر را خواهید خواند:

دوآپس فقط Automation و Continuous Delivery نیست
دوآپس به معنی حذف عملیات نیست
دوآپس فقط ابزار نیست
دوآپس فقط یک فرهنگ نیست
دوآپس فقط توسعه و عملیات نیست
دوآپس فقط یک عنوان شغلی نیست
دوآپس یک تیم نیست
دوآپس راجع به همه چیز و همه جا نیست

دوآپس فقط Automation و Continuous Delivery نیست

اشتباه بزرگ و رایجی که وجود دارد این است که تصور شود جنبش دوآپس کلا درباره ی خودکارسازی همه چیز با یک سری ابزار و تکنولوژی است. (مثل Docker, Ansible, Kubernetes, Team Foundation ). بسیاری بیان می کنند که ما در سازمان خودمان، دوآپس داریم آن را اجرا کردیم. وقتی که می پرسیم چطور آن را اجرا کردید، متوجه می شویم که از واقعیت دور هستند و فقط بخش کوچکی از آن را اجرا کرده اند. (معمولا پاسخ ها به مسائلی بیش از Automation و Continuous Delivery ختم نمی شود).

دوآپس به معنی حذف عملیات نیست

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

همانطور که متوجه شدیم قسمت هایی از عملیات نیاز به خودکارسازی دارند. این کار به چند روش قابل انجام است، یکی اینکه اعضای تیم عملیات، خودکارسازی را توسعه دهند، یا توسعه دهندگان برای “operation” کدنویسی کنند، یا هر دوی آن. پذیرش این موضوع برای برخی سخت است و در مقابل آن مقاومت می کنند، اما این بخشی از ارزشی است که با همکاری مشترک بین تیمی بوجود می آورد. تمامی تیم هایی که در این زمینه موفق شده اند شامل هر دو گروه از افراد بودند (متخصصان حرفه ای توسعه و متخصصان حرفه ای عملیات) و با یک همکاری مشترک در کنار هم، یک محصول بهتر ایجاد کردند.

دوآپس فقط ابزار نیست

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

معمولا در چابک سازی تیم ها هم مشابه این اتفاق می افتد، اعضای گروه کار کردن در قالب iteration و اجرای سایر تمرین های چابک (Agile) را شروع می کنند بدون آنکه همکاری معناداری با هم داشته باشند. من تیم های زیادی را می شناسم که از برخی از روش ها و ابزارهای چابک استفاده می کنند بدون آنکه به اصول چابک توجه کافی داشته باشند. مشخص است که نتیجه ایده آل نمی شود. مطمئنا ابزارهای چابک (یا به طور مشابه ابزارهای دوآپس) می توانند مفید باشند، اما اگر ندانید که چطور از آن ها درست استفاه کنید، شبیه چاقوی جراحی ای است که با آن هندوانه قاچ کنید!

در آخر به این موضوع هم اشاره کنم این جمله هم اشتباه است که بگوییم “هیچ ابزاری نباید به نام ابزار دوآپس معرفی شود”. آیا poker planning در Agile به این معنی است که انجام آن باعث چابک شدن شما می شود ؟ خیر. اما این یک ابزار مشترک در بسیاری از روش های چابک است، پس می توانیم از آن به عنوان یک “ابزار چابک” نام ببریم. به طور مشابه به این دلیل که نمی توان دوآپس را فقط مجموعه ای از ابزار دانست، نمی توان گفت که ابزارهایی که برای اجرای آن ساخته می شوند، “ابزار دوآپس” نیستند.

دوآپس فقط یک فرهنگ نیست

بسیاری از افراد اسرار دارند که بگویند “دوآپس فقط یک فرهنگ است” و شما نمی توانید آن را با یک سری اصول و تمرین ها اعمال کنید، اما این جمله هم درست نیست. Agile فقط به واسطه بعد فرهنگی اش نیست که به هزاران تیم کمک کرده است، اعضای تیم های چابک در کنار هم بهروش هایی (Best Practice) را جهت اجرای آن شناسایی کردند و ابزارهایی را به کار گرفتند و آن ها را به اشتراک گذاشتند. دوآپس از بهروش ها، ابزارها و به طور کلی آیتم هایی در سطوح مختلف تشکیل شده است (و همچنان در حال کامل تر شدن است) ، و عمدتا بدون اجرای تمریناتی که حول آن بوجود آمده، بی فایده است.

دوآپس فقط توسعه و عملیات نیست

دوآپس محدود به توسعه (Development) و عملیات (Operation) نیست. برخی شاکی هستند و می گویند پس اعضای تیم امنیت چه ؟ یا مدیران شبکه چه ؟ چرا دوآپس به آن ها توجه نکرده ؟ اما نکته ی مهم این است که دوآپس برای همه ی کسانی است که به نحوی در تولید و تحویل یک محصول یا یک سیستم مشارکت دارند، از افراد کسب و کار گرفته، تا تحلیل گران، توسعه دهندگان، اعضای تیم های زیرساخت، شبکه، امنیت و سایر افراد مرتبط. همانطور که در توسعه چابک، تمرکز بر ارتباط و همکاری بین کسب و کار (Business) و تیم توسعه (Development) است (Biz + Dev)، در دوآپس تمرکز بر ارتباط و همکاری بین توسعه (Development) و عملیات (IT Operation) است اما تنها به این موارد محدود نمی شود. در نتیجه دوآپس شامل تمام کسانی می شود که به نحوی در تحویل یک محصول یا سرویس مشارکت دارند. به همین منظور اسامی مشابهی مانند DevSecOps, DevOpSec, SecOps, SecureDevOps یا BizDevSecOps مطرح می شود اما رویکرد و طرز تفکری دوآپس شامل همه ی این موارد هست، درگیر عناوین نشوید.

دوآپس فقط یک عنوان شغلی نیست

به سادگی و با تغییر نام تیم عملیات (IT Operation) به تیم دوآپس، هیچ چیز عوض نمی شود. با تعویض عنوان شغلی به مهندس دوآپس (DevOps Engineer) هم چیزی عوض نمی شود. اگر شما ارزش ها و اصول دوآپس را قبول نکنید (که نیازمند تغییرات در سطح کلی سازمان است نه فقط تغییرات در یک بخش یا تیم)، نمی توانید از تمام مزایای آن بهره مند شوید.

البته من مخالف این موضوع نیستم که کسی نباید از واژه ی دوآپس در عناوین شغلی استفاده کند. معمولا استفاده از این واژه برای تمایز بین دو تفکر است، یکی “تفکر به روش دوآپس، تاکید بر خودکارسازی، همکاری توسعه و عملیات، اجرای CI و …” و دیگری “تفکر کسانی که در اتاق خودشان نشسته اند و اهمیتی نمی دهند که در بیرون از اتاق چه اتفاقی می افتد و منافع سازمان در چیست”.

دوآپس یک تیم نیست

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

دوآپس راجع به همه چیز و همه جا نیست

برخی از افراد با طرح یک ادعای بزرگ به اشتباه مدعی می شوند که دوآپس درباره “همه چیز و همه جا !” است. دوآپس با تفکر های چابک (Agile) و ناب (Lean) اجین می شود و از آن به عنوان فرصتی برای همکاری درون سازمانی استفاده می شود، اما واقعا همه چیز به خاطر وجود آن نیست. این بخشی از یک فرهنگ کلی، امیدوار به همکاری و فرهنگ سازمانی چابک است در حالی که دوآپس به طور خاص در مورد این است که چطور محصولات و سرویس ها، عملیاتی و تحویل داده می شوند.

برخی افراد به اشتباه دوآپس را به یک نسخه ی کوچک از Agile و Lean یا فقط به عنوان یک علاقه مندی تبدیل می کنند (البته به عنوان یک چشم انداز خوب است) اما با دنبال کردن سلسله مراتب پیچیدگی ها، بیشتر به یکپارچکی عملیاتی (Operational Integration) می رسند و تلاش در سایر بخش ها امیدوار کننده نیست. اما همچنان مشکلات حل نشده ای در تحویل نرم افزار، نگهداری سرویس و سریعتر، قابل اعتمادتر و امن تر کردن آن باقی مانده است. اگر کسی بخواهد با استفاده از آموخته هایش در دوآپس در محدوده ی (scope) بزرگتری از سازمان به مشاوره بپردازد، که خیلی هم عالی است، اما معمولا افرادی فنی درگیر دوآپس هستند که می خواهند کار خودشان را بهبود بخشند نه کار دیگران را !

به گفته ی ارنست مولر، دوآپس را می توان “تحویل و عملیات چابک نرم افزار” (“Agile Software Delivery and Operations”) دانست که در آن افراد با همکاری یکدیگر بر روی ابتکارات سازمانی بزرگتر کار می کنند بدون اینکه ارزش پیشنهادی اصلی خود را فراموش کنند.

ژوئن 17, 2017مارس 31, 2020

Continuous Delivery چیست ؟

Continuous Delivery یا (CD)، رویکردی در مهندسی نرم افزار است که تیم ها را قادر می سازد نرم افزار تولید شده را به روشی سریع و مطمئن برای انتشار و تحویل آماده کنند. این فرایند از لحظه اضافه شدن یا تغییر کد در source control شروع می شود و شامل بیلد، تست، پیکربندی و انتشار در محیط های مختلف تست و محیط عملیات می شود. این مفهوم در فارسی به “تحویل مداوم” یا “تحویل مستمر” ترجمه شده است.

به عبارت دیگر: Continuous Delivery توانایی اعمال تغییرات در محیط عملیات در هر لحظه با روشی سریع و مطمئن و به طور کاملا پایدار می باشد. این تغییرات شامل همه انواع آن از جمله تغییرات پیکربندی در نرم افزار، زیرساخت و پلتفرم، افرودن ویژگی های جدید، رفع باگ و خطا ها می شود.

به وسیله محیط های تست مختلف، می توان یک Release Pipeline ایجاد کرد تا بتوان یک زیرساخت جدید را به طور اتوماتیک ایجاد کرد و نرم افزار را روی آن منتشر کرد. منظور از زیرساخت، سرور، سیستم عامل، سرویس دهنده ی وب، virtualization، شبکه و پیکربندی و تنظیمات آنها می باشد. به کمک این محیط های متوالی می توان فعالیت های طولانی Integration، تست عملکرد و تست های پذیرش نهایی را به تدریج انجام داد. فرایند Continuous Delivery در Release Pipeline با Continuous Integration شروع میشود و با انتشار و پایان تست در هر محیط، انتشار و تست در مرحله بعدی شروع می شود. مجموع این کارها به صورت حلقه های یک زنجیر در پشت سر هم قرار گرفته و فرایند Continuous Delivery را تشکیل می دهند.

هدف Continuous Delivery چیست ؟

هدف CD این است که که انتشار و تحویل نرم افزار را به خصوص برای سیستم های توزیع شده در مقیاس بسیار بزرگ و محیط های عملیاتی پیچیده به یک فرایند روتین، ساده و قابل پیش بینی تبدیل کند. رسیدن به این هدف تنها در صورتی امکان پذیر است که کدهای نرم افزار همیشه در وضعیت آماده برای انتشار باشند، حتی در شرایطی که یک تیم با هزاران توسعه دهنده به طور روزانه در حال تغییر و به روزرسانی کد ها و نرم افزار هستند. به این ترتیب روش سنتی فازهای ادغام (Integration)، تست، پیکربندی و Hardening جای خود را به روش های اتوماتیک می دهد. همچنین زمان آماده شدن برای انتشار، زمان مهاجرت به محیطهای دیگر (Time to Remediate) و زمان برطرف کردن رخداد در محیط عملیات را کاهش (Time To Mitigate or time to remediate production incidents) می دهد.

تفاوت Continuous Delivery و Continuous Deployment چیست ؟

بسیاری از مواقع دو مفهوم Continuous Delivery و Continuous Deployment به اشتباه به جای هم استفاده می شوند اما تقاوت این دو چیست ؟ Continuous Deployment به این معنی است که هر تغییر در نرم افزار به طور اتوماتیک (یا بر طبق یک زمان بندی مشخص) در محیط عملیات منتشر شود. اما Continuous Delivery به این معنی است که هر تغییر در نرم افزار، آماده انتشار در هر محیطی باشد اما ممکن است تصمیم این باشد که منتشر نشود (معمولا به دلایل کسب و کاری). این محیط ها شامل محیط تست تیم توسعه، محیط تست تیم کنترل کیفیت و محیط عملیات و هر محیط دیگری می شود.

تفاوت Continuous Delivery و دواپس چیست ؟

این دو مفهوم از جهاتی به هم نزدیک هستند و اما تفاوت های بنیادی با هم دارند. دامنه ی DevOps بسیار گسترده تر از CD است و علاوه بر خودکارسازی فرایند تحویل نرم افزار، شامل تغییرات فرهنگی به خصوص ارتباط بین تیم های مختلفی که در جریان آماده سازی و تحویل محصول نرم افزاری (Software Delivery) هستند هم می شود. (از جمله تیم های توسعه، عملیات، تضمین کیفیت، مدیریت و … ) اما Continuous Delivery روشی است برای اتوماتیک سازی زنجیره تحویل محصول و بر این موضوع تمرکز دارد که فرایند های مرتبط در کنار هم طوری اجرا شود که منجر شود محصول نرم افزاری، سریعتر، امن تر و با تکرار بیشتری به دست مشتری برسد.

در نبود Continuous Delivery …

در نبود CD، انتشار نرم افزار یک bottleneck برای تیم های “عملیات فناوری اطلاعات” و در نهایت برای محصول است. فرایند دستی و غیر اتوماتیک، باعث انتشارهای غیر قابل اتکا، با تاخیر و پر از خطا می شود. تیم های درگیر این موضوع معمولا به کارهای دستی که افراد انجام می دهند تکیه می کنند که باعث مشکلات جدی خواهد شد.

حداقل الزامات اجرای Continuous Delivery

برای راه اندازی و اجرای Continuous Delivery الزاماتی وجود دارد که در کمترین حالت می توان از دو مورد زیر نام برد

زیربنایی از تست ها که تا حد قابل قبولی خیال شما را از اینکه نرم افزار به درستی کار می کند، راحت کند و به شما اعتماد به نفس لازم را برای شروع استقرار بدهد
ابزارهای خودکارسازی (automation) و اسکریپت های لازم که به شما اطمینان دهد استقرار با موفقیت انجام خواهد شد و در صورت نیاز امکان Rollback وجود خواهد داشت

سخن آخر

در آخر باید این این نکته را اضافه کنم که فرایند Continuous Delivery و Infrastructure as Code و Monitoring به طور قابل ملاحظه ای مکمل یکدیگر هستند. Continuous Delivery برای کنترل تاثیر تغییرات در محیط عملیاتی از استراتژی های استقرار از جمله Blue-Green Deployment و همچنین تکنیک Feature Flags (یا Feature Toggles) نیز پشتیبانی می کند. (در آینده راجع به استراتژی های انتشار مطلبی خواهم نوشت)
امروزه ارزش هایی که CD برای سازمان ها ایجاد می کند، آن را به یک نیاز ضروری تبدیل کرده است. برای رساندن ارزش به مشتریان نهایی، باید محصول را به طور پیوسته و بدون خطا منتشر کرد. Release Pipeline های پیشرفته به توسعه دهندگان اجازه می دهد که feature های جدید را سریع و مطمئن منتشر کنند. با کمک CD، رفع خطاها در محیط عملیات و اضافه کردن ویژگی های جدید بسیار سریع تر و با اطمینان بالا انجام خواهد شد و به دست مشتری خواهد رسید.

ژوئن 7, 2017ژانویه 4, 2021

به زبان ساده DevOps چیست ؟ | به زبان ساده دوآپس چیست ؟

DevOps چیست ؟ | دوآپس چیست و چرا مطرح شد ؟

سال های متمادی در شرکت های توسعه نرم افزار، تیم هایی با هدف کاملا متفاوت به نام تیم توسعه (Development) و تیم عملیات (Operation) وجود داشتند. هدف تیم توسعه ساخت ویژگی های جدید بر روی محصول و در نتیجه تغییرات زیاد روی آن بود، اما هدف تیم عملیات، ثابت نگه داشتن وضعیت موجود سرویس ها برای پایداری بیشتر آن ها بود. بدین ترتیب دیواری بین این دو تیم وجود داشت. (DevOps چیست ؟)

DevOps - Wall Of Confusion — Wall Of Confusion

به مرور زمان تیم های توسعه به روش های چابک برای تولید نرم افزار روی آوردند که تعامل همیشگی با مشتری، اعمال تغییرات، و اضافه کردن ویژگی های جدید بر اساس نظر مشتریان قسمتی از این روش های چابک بود.
اما دیوار بین دو تیم Dev و Ops باعث می شد تا عملیاتی کردن ویژگی های جدید توسعه داده شده و تغییرات، به اندازه کافی چابک نباشد. تمرکز روش های چابک توسعه نرم افزار، بر توسعه و تولید نرم افزار بود و کمتر به موضوعاتی مثل استقرار (Deployment) و عملیات (Operation) توجه می کرد.

به دنبال این محدودیت هامفهوم دوآپس (DevOps) مطرح شد و به دنبال این بود که دیوار بین تیم های Dev و Ops را از بین ببرد و با تمرکز بر افزایش تعاملات بین تیمی، موجب افزایش سرعت تحویل ارزش به مشتری شود. پس دوآپس به دنبال این است که ارزش های ایجاد شده در نرم افزار را خیلی سریعتر به دست مشتری برساند

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

دواپس چیست ؟ | What is DevOps ?

DevOps یا دِوآپس، مجموعه ای از روش ها، فرایند ها و ابزارهایی است که با تمرکز بر ارتباطات و همکاری و یکپارچگی بین تیم های توسعه، تضمین کیفیت و عملیات، ارزش های تولید شده را سریع و به صورت مستمر به مشتریان نهایی می رساند. ادغام کلمات اختصاری “Dev” و “Ops” به این موضوع اشاره دارد که توسعه و عملیات به عنوان دو تیم مستقل و کاملا جدای از هم، جای خود را به تیم های چند تخصصی با مهارتها، روش ها و ابزار یکپارچه داده است.

یک تعریف ملموس برای کسب و کار

دواپس اتحاد بین افراد، فرایندها و محصولات برای تحویل مستمر ارزش ها (Continuous Delivery of value) به مشتریان نهایی است. Donovan Brown

از جمله الزامات اجرای دواپس می توان به موارد زیر اشاره کرد :

Continuous Integration
Continuous Delivery
Agile Planning
Application Monitoring

چرا دواپس را اجرا کنیم ؟ | Why should implement DevOps ?

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

چرا دواپس مهم شد ؟

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

دوآپس سعی می کند با نزدیک تر کردن این تیم ها با تمرکز بر تعامل و همکاری بیشتر و حذف دیوار بین آن ها، و همچنین به کمک یک سری ابزار که کارهای تکراری را اتوماتیک می کند، تحویل ارزش به مشتری سریعتر و مطمئن تر انجام شود.

کج فهمی ها در مورد دواپس

آیا دوآپس یک ابزار یا یک تکنولوژی است ؟
آیا دوآپس یک فرهنگ است یا یک تیم ؟ یا تنها یک سبک تفکر؟
آیا دوآپس فقط یک عنوان شغلی است؟
آیا دوآپس فقط Automation یا Continuous Delivery است؟
آیا دوآپس به معنی حذف Operation است ؟
آیا دوآپس فقط به توسعه و عملیات (Dev و Ops) محدود می شود ؟

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

چطور دواپس را اجرا کنیم ؟ | How to implement DevOps ?

در پست های بعدی به تشریح این موضوع خواهم پرداخت…

می 30, 2017ژانویه 4, 2021

دواپس چیست و چرا آن را اجرا کنیم ؟ | What is DevOps, Why should imp it ?

دواپس به زبان ساده

این مطلب با پست دیگری “دواپس به زبان ساده چیست ؟” ادغام شد.