خب؛ سوال خوبیه! منم این روزها زیاد ازش میشنوم که CI/CD Pipeline چیه، چه کاربردی داره و چطوری کار میکنه.
CI/CD Pipeline چیه؟
در حوزه برنامه نویسی، CI/CD Pipeline به شما کمک میکنه که مراحل توسعه نرم افزارتون رو automated (آتومانیک) کنید. به عنوان مثال، خروجی گرفتن از پروژه، اجرای تست ها، بارگذاری اون بر روی سرور و .. همه و همه قراره به صورت خودکار اتفاق بیوفته.
همچنین pipelines های خودکار، ارورهای دستی رو هندل میکنن، یک گزارش کلی از بازخوردهای چرخه فرایند اجرای نسخه جدید محصول نرم افزاری رو هم میسازن و ارسال میکنن برای توسعه دهنده های اون نسخه جدید.
نکته: واژه pipeline در جاهای مختلف معانی مختلفی داره. به صورت تحت اللفظی معنی «لوله» میده ولی در اینجا و به طور کلی معنی «سلسله مراحل یک فرایند» رو میده.
معنی CI و CD چیه؟
در واقع CI مخفف Continuous Integration (ادغام پیوسته) هست که یک عمل نرم افزاری است که توی اون همه برنامه نویس ها، تغییراتی که توی کدشون میدن رو روی یک ریپازیتوری مرکزی merge میکنن (شاید چندین بار این اتفاق در روز بیوفته).
همچنین CD مخفف Continuous Delivery هست که در یک سطح بالای Continuous Integration قرار میگیره و عمل خودکار-سازی انتشار یک پروژه نرم افزاری رو به چرخه فرایند اضافه میکنه.
در CI، هر تغیر در کد، یک زنجیره build-and-test (ساخت و تست) رو برای اون پروژه ای که توش کد تغییر کرده اجرا میکنه، همچنین بازخورد اون تغییر کد رو به برنامه نویس یا برنامه نویسایی که اون تغییرات رو ایجاد کردن اعلام میکنه. تمام چرخه CI (از خروجی گرفتن پروژه تا تست و بارگذاریش) همه باید کمتر از 10 دقیقه طول بکشه.
از طرفی CD شامل تهیه و تدارک زیرساخت ها هست. که میتونه گاها شامل چندین لایه/سطح باشه. چیزی که مهمه اینه که تمام این فرایند براید کاملا خودکار باشه؛ و هر نسخه جدیدی که آماده میشه و این چرخه شروع به اجرا میکنه، یک نسخه کاملی از log ها (گزارش کامل) ساخته بشه و در اختیار تیم فنی قرار بگیره که همه متوجه بشن اون features (قابلیت یا قابلیت های) جدیدی که اضافه شده، به چه صورتی و با چه بازخوردی به پروژه اضافه شدن.
نکته: در بعضی موارد هم CD به منظور Continuous Deployment هم در مطرح میشه و از اونجایی که خیلی روی صحبت من مرتبط باهاش نیست، اشاره ای بهش نمیکنم.
اجزای CI/CD pipeline چی هستن؟
شاید در یک نگاه کلی به قصه، CI/CD pipeline یک کار اضافی و سربار به نظر برسه، ولی واقعا اینطور نیست. همانطور که گفته شد، دقیقا ضروری ترین مراحل انتشار یک نسخه جدید از محصول رو به صورت خیلی حرفه ای و دقیق خودکار یا همون automated میکنه. مراحلی که باید هر سری برای انتشار یک نسخه جدید انجام و بررسی بشن.
در نبود یک pipeline خودکار، در واقع مهندسین (یا برنامه نویس ها) باید به صورت دستی (و با ضریب خطای بیشتری) این مراحل رو انجام بدن که خب همین امر باعث میشه زمان بیشتری هم بزارن و طبیعتا عملکردشون (یا همون productively) هم افت میکنه.
اکثر پروژه های نرم افزاری، برای انتشار یک نسخه جدید، باید این مراحل رو طی کنن:
همانطور که میبینی، مراحل کلی یک فرایند برای انتشار یک ورژن یا نسخه جدید از یک پروژه/محصول 4 مورد زیر هستن:
- مرحله Source (منبع کد)
- مرحله Build (ساخت)
- مرحله Test (تست)
- مرحله Deploy (استقرار، انتشار)
خطا هر کدوم از مراحل بالا به صورت یه نوتیفیکیشن (یا از طریق ایمیل یا اسلک یا هرچی) به برنامه نویسای پروژه ارسال میشه که برنامه نویسایی که مسئول اون بخش هستن به خطای رخ داده رسیدگی بکنن. در غیر این صورت (اگر هیچ خطایی نباشه) برای تمام تیم یک نوتیفیکیشن «موفقیت آمیز» از انتشار نسخه جدید ارسال میشه.
مرحله Source (منبع کد)
در بیشتر مواقع، شروع pipeline زمانی اتفاق میوفته که یک push به ریپازیتوری (که کد پروژه اونجاس) انجام میشه. به عبارت بهتر، همون تغییر کدی که گفته بودم، وقتی به سورس پروژه تزریق میشه فرایند CI/CD شروع به کار می کنه. البته یک نوع دیگه ای از شروع کار CI/CD هم وجود داره که بهش میگن scheduled (یعنی زمان بندی شده)؛ این مورد اغلب برای مواقعی هست که میخوایم در یک ساعت خاصی از روز مثلا وب سایتمون رو بروزرسانی بکنیم که میدونیم در اون ساعت تعداد کاربرهای آنلاین کمتری دارن از سایت استفاده میکنن. که در اون صورت توی تنظیمات ست میکنیم که در فلان زمان عملیات CI/CD شروع به کار کنه.
مرحله Build (ساخت)
در این مرحله ما کدی که به سورس پروژه اضافه شده رو ترکیب میکنیم با کد سورس اصلی و تمام وابستگی هاش (dependencies) رو هم نصب و دانلود میکنیم و سورس رو تبدیل میکنیم به همون چیزی که کاربر نهایی قراره در این نسخه ببینه. برنامه هایی که به زبان های
جاوا، سی پلاس پلای یا .. نوشته شدن، نیاز دارن که کامپایل بشن (و در این مرحله میشن)، در حالی که زبان هایی مثل روبی، پایتون، جاوااسکریپت یا .. نیازی به این کار ندارن.
علاوه بر در نظر گرفتن زبان برنامه نویسی، نرم افزارهای cloud-native عموما در بستر داکر Docker قرار دارن و توسعه داده میشن، پس در این مرحله، CI/CD pipeline یک داکر کانتینر Docker containers میسازه. رخداد خطا در این مرحله ساخت، یک شاخص هست از یک مشکل اساسی در تنظیمات پروژه که باید در اسرع وقت بهش رسیدگی بشه.
مرحله Test (تست)
در این مرحله، به صورت خودکار، تست هایی که پروژه باید سپری بکنه تا صحتش اعتبارسنجی بشه اجرا میشن. هم توی کد و هم رفتار کلی محصول. این مهمترین مرحله هست برای حصول اطمینان از صحت عملکرد محصول در نسخه جدید؛ که باعث میشه نسخه ای که قرار انتشار پیدا بکنه و در معرض استفاده کاربر نهایی قرار میگیره، بدون باگ Bug free و بدون کرش Crash free باشه.
عموما دیده میشه که برنامه نویس ها خیلی تمایلی به نوشتن تست ها ندارن و معمولا پشت گوش میندازن. ولی خب همونطور که مشخص هست یک مرحله خیلی مهم هست و برای راه اندازی CI/CD pipeline جزو الزامات هستش. هر پروژه برنامه نویسی با توجه به زبان و ساختاری که داره تست های خودش رو داره که نهایتا هرگونه خطایی که تست ها نشون میدن به برنامه نویس های پروژه گزارش داده میشه.
مرحله Deploy (استقرار، انتشار)
خب الان ما تا قبل از این مرحله، یک ورژن جدید از پروژه رو داریم که یک سری ویژگی و قابلیت جدید بهش اضافه شده، تلفیق و ترکیب کد بیس اتفاق افتاده، تست شده و آماده به انتشار هست. در اینجا محیط های انتشار متفاوتی وجود داره، مثلا «بتا - Beta» یا «staging» که برای تیم داخلی قابل استفاده و در دسترس هست و همچنین محیط «ساخت نهایی - production» که دقیقا همونجایی هست که کاربر نهایی میبینه.
تیم هایی که متدولوژی مدیریت پروژشون مدل Agile هست، که توی مراحل توسعشون تست و مانیتور کردن وجود داره، معمولا محیط Deployشون همون staging هست که باز بتونن یه سری تست ها و ریویو ها رو روی نسخه جدید انجام بدن و بعد از تایید نهایی، به محیط production انتقال پیدا میکنه و نسخه جدید برای کاربرهای نهایی قابل روئیت و استفاده میشه.
موفق باشید.
