چرا CI/CD به کارمون میاد ؟ چی هست ؟

چرا CI CD بوجود اومد ؟ چی کار میکنه حالا ؟

این دو حرف یعنی CI/CD مخفف دو کلمه continuous integration و continuous delivery یا continuous deployment هست که البته این که کدوم باشه بستگی به شرایط داره !

اولی با CI شروع میکنیم : ( برای درک بهتر تمام صحبتا حتما پیشنهاد میکنم روی لینک youtube کلیک کنید تا با ویدیو راحت تر بحث رو درک کنید )
تویه دوران قدیم ( در این لحظه صفحه سیاه سفید میشود :) ) تیم های Developer که کدهاشون رو مینوشتن بعد از این که develop میشد میدادن به یک تیم ای به نام integration ، که این تیم code ها رو بررسی میکرد و merge میزد و ماژول هایی که استفاده شده بود تویه هر کد رو بررسی میکرد که باهم اختلالی نداشته باشند و اگر داشت دوباره کد رو به تیم Developer بر میگردوند .

بعد از اون اگر کد اوکی بود داده میشد به تیم operation برای build زدن و test کردن کد که بازم اگه اونجا مشکلی بود مجدد تیم operation اونو میداد به تیم developer برای بررسی مجدد کد و این loop تا زمان که build درست انجام بشه و یک app یا pkg یا هر نسخه ای که قابل نصب باشه داشته باشیم ادامه داشت ...

بعد از دیدن این موضوعات بحث CI رو کار اومد که 2 تا مورد خیلی مهم رو از موارد زیر مجموعش هندل میکرد :

1-کد ها زمانی که میان تویه Repository ما ( یا همون centralize repo ) خودشون به صورت automate اونجا merge بخورن و تویه یک جابه صورت یکپارچه نگهداری شوند.

2- کدهایی که merge میخورن و تویه central repo قرار میگیرن ، هر زمانی که بخوایم روی یک Build server اون رو build کنیم ( compile کنیم که در نهایت به ما یک نسخ مثل pkg بده ) و بعد از Build به صورت auto روی server ای که ما به عنوان تست تعریف کردیم pkg رو نصب کنه ( به واسطه task و pipeline ای که براش نوشته شده ) .

پس در نتیجه CI :

1-مرحله merge

2-مرحله Build

3-مرحله Test

رو به صورت auto هندل میکنه و اون sprint که تایید شده رو به راحتی pass میکنه و باعث ایحاد gap های طولانی مثل دوران قبلی نمیشه .

حالا میخوایم راجب CD صحبت کنیم :

مخفف continuous delivery/deployment میشه حالا چرا دوتا ؟ راجبش صحبت میکنیم .

من این قسمت رو برای راحتی درک مطلب به سه بخش تقسیم :

1-manual

2-automatic

3-approval

اگر از manual شروع کنیم در اصل میشه همون بخش delivery حالا یعنی چی ؟زمانی که من بعد CI که یک pkg آماده نصب تویه env ام دارم ، اگر اون رو بیاد شخص/تیم ای نصب کنه مثلا operation یا DevOps به این عمل میگن manual .

در وجه دیگه اگر این pkg مستفیم بعد CI بره تویه env نصب بشه میشه auto و هیچ نیرو انسانی توش دخیل نباشه بعد از مرحله CI ولی خب یک مشکلی که داره این هست که شما اینجا CAB ندارید ( CAB چی هست ؟ ) و علاوه بر اون وقتی من بعد CI بدون تست بیام بگم بره اون pkg رو نصب کنه دیگه خودتون تا آخرش رو میتونید دریابید:) احتمال ایجاد مشکل تویه prod امون خیلی میره بالا از نظر عدم down time و شکایت end user ها .

و قسمت آخر هم approval میشه که یک شخص یا CAB یا مدیر یا هر شخص بالا دستی اون Deploy شدن تویه env prod مون رو تایید کنه و بعد از اون ، pkg وارد محیط مورد نظر میشه و نصب میشه و Up میشه و حالا که این اتفاق تویه تایمی میوفته که اکثریت از اون app استفاده نمیکنن ( عموما بامداد ) هم باعث میشه شکایت از app کاهش پیدا کنه هم اگر که pkg مشکل خورد راحت تر rollback انجام بشه .
در آخر ما دو بحث دارم راجب
1-CICD Push Based
2-CICD pull Based

که تویه قسمت های بعدی راجبش صحبت میکینیم ولی پیشنهاد میکنم قبل از شروع حتما مقداری آشنایی با GIT و بحث Repository داشته باشید که راحت تر بتونید متوجه موضوعات بشید

دمتون گرم .