وبلاگ شخصی حامد شیربندی

حامد شیربندی

توسعه دهنده نرم افزار

Continuous Dellivery - بخش اول : مفهوم

در مقاله های قبلی با مفهوم CI آشنا شدیم و با استفاده از امکانات داخلی TFS توانستیم یک فرآیند تعریف کنیم که بعد از هر بار تغییر روی سورس اجرا شده و در نهایت باعث یکپارچه سازی آن میشد. اما بعد از اینکه ما توانستیم نسخه های stable و یکپارچه ی سورس خود را مشخص کنیم توسط آنها چه ارزشی را میتوانیم به بیزنس خود اضافه کنیم؟ در ادامه و با بررسی این مسئله با CD یا همان Continuous Dellivery آشنا خواهیم شد.


Continuous Dellivery چیست؟

Continuous Dellivery یا "تحویل مداوم" در واقع یک فرآیند برای Build کردن سورس و سپس اجرای یک سری تست و در نهایت Deploy کردن روی محیط Production می باشد. این فرآیند ممکن است شامل یک یا چند محیط Staging و Testing نیز باشد اما در نهایت نتیجه ی کار روی محیط Production منتشر یا به اصطلاح Release میشود.


یک مسئله

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


یک راه حل

حالا راهکاری که CD ارائه میکند این است که با توجه به اینکه ما طبق سری مقالات CI همواره یک نسخه ی یکپارچه و stable از سورس را داریم میتوانیم یک فرآیند دیگری را هم تعریف کنیم که پابلیش و deploy و تست کردن پروژه روی سرور مشتری را نیز به صورت خودکار انجام دهد. در این صورت اگر ویژگی جدیدی در برنامه کد نویسی کردیم و یا اگر مشکلی از نظر مشتری در نسخه ی جاری برنامه وجود داشته و به ما گزارش دهد کافی است آن را در سورس حل کرده و Check In کنیم و به ادامه ی توسعه ی خود بپردازیم چرا که در پشت صحنه فرآیندهایی که قبلا به صورت دستی انجام میدادیم اینبار به صورت خودکار انجام شده است.


تعریف یک فرآیند

در مقالات آتی یک فرآیند CD به شکل زیر را به کمک TFS پیاده خواهیم کرد : یک محیط Staging ایجاد میکنیم که در واقع یک محیط برای deploy کردن پروژه قبل از محیط Production است و آنجا میخواهیم از صحت برنامه مطمئن شویم. در واقع محیط Production همن محیط عملیاتی است که نتیجه ی نهایی در دسترس End User ها قرار میگیرد و با توجه به حساس بودن این محیط ما نمیخواهیم که ریسک کنیم و نسخه های تحویل گرفته شده از فرآیند CI را مستقیما آنجا deploy کنیم چرا که ممکن است آن نسخه مشکلی داشته باشد و برنامه را از دسترس کاربران خارج کند. برای ایجاد محیط های Production و Staging کافی است برای هرکدام یک وب سایت در iis درست کنید مثلا به اسم myapp و staging.myapp که هر کدام با یک دامنه مثلا به اسمهای myapp.ir و staging.myapp.ir در دسترس هستند.این وب سایتها میتوانند روی دو سرور مجزا هم تعریف شوند که بستگی به میزان منابع و حساسیت پروژه دارد. فرآیند را به این شکل تعریف میکنیم که ابتدا نسخه ی دریافتی از CI را روی محیط Staging منتشر کند.سپس یک سری تست UI را به صورت E2E روی آن اجرا میکنیم تا مطمئن شویم وب سایت در دسترس است و به درستی کار میکند.حالا این نسخه که با موفقیت روی Staging اجرا شده در انتظار یک تایید قرار میگیرد تا روی محیط Production نیز Deploy شود.

اگر فرآیند Deploy روی محیط Production را نیز خودکار کنیم یعنی نیازی به تایید دستی نداشته باشد در این صورت به آن Continuous Deployment می گویند.

نوشته شده توسط حامد شیربندی

اگر در مورد این نوشته سوال یا ابهامی وجود دارد میتوانید به ایمیل من ارسال کنید. البته در این مورد باید کمی صبور باشید. در آینده بخش نظرات اضافه خواهد شد.