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

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

تیم باید مطمئن بشه تغییرهای جدید با هم تداخل ندارن، چیزی از قبل خراب نشده و نسخه جدید درست کار می‌کنه. اگه این بررسی‌ها هر بار دستی و نامنظم انجام بشن، ممکنه یه مرحله جا بیفته یا یه ایراد خیلی دیر خودش رو نشون بده. سؤال اینجاست: چطور می‌شه این مسیر رو منظم‌تر کرد و مشکل‌ها رو زودتر دید؟

اینجاست که CI/CD وارد ماجرا می‌شه. اگه خیلی ساده بخوایم بگیم، CI/CD یه رویکرده که کمک می‌کنه تغییرات کد مرتب‌تر بررسی بشن و آماده‌سازی نسخه‌های جدید تا جای ممکن قابل تکرار و خودکار جلو بره. توی این مقاله قدم‌به‌قدم می‌بینیم CI و CD چه کاری می‌کنن، Delivery با Deployment چه فرقی داره و Pipeline چطور این مسیر رو کنار هم می‌چینه.

CI/CD چیست و چه مشکلی را حل می‌کند؟

برای جواب دادن به سؤال CI/CD چیست بهتره اول از خود اسمش شروع کنیم. CI مخفف Continuous Integration یا «یکپارچه‌سازی مداوم»ه. CD هم بسته به Context می‌تونه Continuous Delivery یعنی «تحویل مداوم» یا Continuous Deployment یعنی «استقرار مداوم» باشه.

اما معنی واقعی CI/CD فقط باز کردن این مخفف‌ها نیست. CI/CD یه رویکرد یا Approach تو توسعه نرم‌افزاره؛ یعنی تغییرات کد مرتب وارد یه جریان مشخص می‌شن، Build و Test می‌تونن خودکار اجرا بشن و نسخه‌ای که کنترل‌ها رو رد کرده برای Release آماده بشه یا در بعضی مدل‌ها تا Production جلو بره.

برگردیم به فروشگاه خودمون. برنامه‌نویس قابلیت سبد خرید رو اضافه کرده. اگه تغییرش مدت زیادی جدا بمونه، شاید موقع ادغام تازه معلوم بشه پروژه Build نمی‌شه یا رفتاری خراب شده. CI/CD می‌خواد فاصله بین «تغییر کد» و «فهمیدن نتیجه اون تغییر» رو کوتاه کنه.

نقش Automation هم همین‌جا مهمه. ماشین جای برنامه‌نویس فکر نمی‌کنه؛ فقط مراحل تکراری و قابل تعریف، مثل Build و Test، هر بار با یه روش مشخص جلو می‌رن. تیم هم کمتر درگیر این می‌شه که «این بار کدوم مرحله جا افتاد؟»

CI/CD یک رویکرد است، نه یک ابزار

یه سوءبرداشت رایج اینه که CI/CD رو اسم یه نرم‌افزار خاص بدونیم. این نگاه دقیق نیست. CI/CD روش کاره، نه اسم ابزار. ابزارهای مختلف فقط کمک می‌کنن این روش اجرا بشه.

مثلاً وقتی می‌گیم تیم می‌خواد هر تغییر کد رو بعد از ثبت، به‌صورت خودکار Build و Test کنه، داریم درباره یه تصمیم فرایندی حرف می‌زنیم. اینکه این تصمیم با چه سرویسی اجرا بشه، یه سؤال بعدیه. برای فهم خود CI/CD فعلاً همین تفکیک کافیه: اول رویکرد رو می‌فهمیم، بعداً می‌تونیم سراغ ابزار اجرای اون بریم.

CI/CD چه مشکلاتی را در فرایند توسعه حل می‌کند؟

حالا سؤال مهم‌تر اینه که اصلاً چرا تیم‌ها سراغ CI/CD می‌رن. مسئله فقط «مدرن بودن» یا داشتن یه Pipeline قشنگ نیست. CI/CD چند مشکل واقعی تو توسعه نرم‌افزار رو هدف می‌گیره.

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

مشکل بعدی کشف دیرهنگام خطاست. شاید تغییر سبد خرید روی سیستم Developer خوب به نظر برسه، ولی موقع Build یا Test مشکلش مشخص بشه. هرچقدر Feedback زودتر برگرده، اصلاح هم راحت‌تره؛ چون Context تغییر هنوز تازه‌ست.

یه مشکل دیگه کارهای دستی تکراریه. وقتی قبل از هر Release همون بررسی‌ها بارها با دست تکرار می‌شن، احتمال جا افتادن یه مرحله بیشتره. CI/CD کمک می‌کنه بخش قابل تعریف این کارها طبق یه مسیر ثابت تکرار بشه.

انتشارهای خیلی بزرگ هم معمولاً پرریسک‌ترن. وقتی تعداد زیادی تغییر یک‌جا منتشر می‌شن، پیدا کردن منشأ مشکل سخت‌تره. CI/CD با روان‌تر کردن بررسی تغییرها، کار با تغییرهای کوچیک‌تر و Feedback سریع‌تر رو عملی‌تر می‌کنه.

پس هدف اصلی CI/CD این نیست که «همه‌چیز رو خودکار کنیم». هدف اینه که فاصله بین تغییر، بررسی و آماده‌سازی برای انتشار کمتر بشه و مراحل تکراری، قابل اعتمادتر و قابل پیش‌بینی‌تر جلو برن.

تفاوت CI و CD چیست؟

تا اینجا یه تصویر کلی داریم، ولی هنوز CI و CD رو باید از هم جدا کنیم. اگه این مرز روشن نباشه، اصطلاح CI/CD تبدیل می‌شه به یه اسم کلی که همه‌چیز رو با هم قاطی می‌کنه.

اگه بخوایم خیلی فشرده بگیم، CI بیشتر روی Integration و Validation تغییرات تمرکز داره. CD از جایی مهم‌تر می‌شه که نسخه تأییدشده باید برای Release آماده بمونه یا تا Deployment جلو بره.

اول این سه مفهوم رو کنار هم ببین:

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

Continuous Integration چه کاری انجام می‌دهد؟

Continuous Integration یعنی اعضای تیم تغییراتشون رو مرتب با کد مشترک پروژه یکپارچه کنن و سیستم خیلی زود بهشون Feedback بده که این تغییر سالمه یا نه. «مرتب» بودن اینجا مهمه. اگه هر برنامه‌نویس مدت زیادی روی یه شاخه جدا کار کنه و بعد حجم زیادی از کد رو یک‌جا وارد پروژه کنه، Integration سخت‌تر و پرریسک‌تر می‌شه.

تو مثال فروشگاه، برنامه‌نویس قابلیت سبد خرید رو تغییر داده. وقتی این تغییر وارد مخزن مشترک کد یا Repository می‌شه، فرایند CI می‌تونه شروع بشه. پروژه Build می‌شه و تست‌های از قبل تعریف‌شده اجرا می‌شن. اگه Build بشکنه یا یه Test مهم Fail بشه، تیم خیلی زود می‌فهمه این تغییر هنوز آماده ادامه مسیر نیست.

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

Continuous Delivery و Continuous Deployment چه تفاوتی دارند؟

اینجا همون جاییه که خیلی‌ها گیج می‌شن، چون حرف D تو CI/CD همیشه یه معنی ثابت نداره. گاهی منظور Continuous Delivery هست و گاهی Continuous Deployment.

در Continuous Delivery، نسخه تأییدشده به وضعیت Ready for Release می‌رسه. یعنی Build و تست‌های تعریف‌شده رو رد کرده، Artifact لازم آماده‌ست و تیم از نظر فنی می‌تونه منتشرش کنه؛ با این حال یه تصمیم انسانی هنوز می‌تونه قبل از Production باقی بمونه.

همون فروشگاه رو در نظر بگیر. قابلیت جدید سبد خرید همه کنترل‌ها رو رد کرده و نسخه آماده‌ست. تیم شاید تصمیم بگیره انتشار به Production فقط وقتی انجام بشه که مسئول Release یه Manual Approval بده. این هنوز مدل Continuous Delivery به حساب میاد، چون نرم‌افزار رو مرتب در وضعیت قابل انتشار نگه می‌داریم، حتی اگه دکمه آخر رو انسان بزنه.

در Continuous Deployment یه قدم جلوتر می‌ریم. اگه تغییر از کنترل‌های تعیین‌شده رد بشه، لازم نیست یه Approval دستی اجباری بین نسخه تأییدشده و Production وجود داشته باشه. Pipeline می‌تونه نسخه رو خودش Deploy کنه.

پس یه خط قرمز مفهومی رو یادت بمونه: CI/CD لزوماً به معنی Deploy خودکار روی Production نیست. اگه تیم Continuous Delivery داشته باشه، می‌تونه همه مراحل تا آماده‌بودن نسخه رو خودکار کنه و همچنان تصمیم نهایی انتشار رو دستی نگه داره.

این تفاوت فقط بازی با کلمات نیست. وقتی کسی می‌گه «ما CD داریم»، باید بدونی منظورش Delivery هست یا Deployment؛ چون میزان Automation تا Production تو این دو مدل یکی نیست.

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

حالا رسیدیم به بخشی که همه تکه‌های قبلی رو به هم وصل می‌کنه. تا اینجا درباره Practice حرف زدیم؛ حالا باید ببینیم این رویکرد چطور تبدیل به یه جریان اجرایی قابل تصور می‌شه.

CI/CD Pipeline یه Workflow یا مسیر اجراییه که مراحل تعریف‌شده رو با ترتیب و قواعد مشخص جلو می‌بره. یک Pipeline واقعی ممکنه مرحله‌های بیشتری داشته باشه، ولی برای ساختن مدل ذهنی درست، این مسیر ساده کاملاً جواب می‌ده:

Code Change → Trigger → Build → Test → Delivery → Deployment

هر Code Change رو مثل یه بسته ببین که از چند ایستگاه رد می‌شه. هر ایستگاه یه سؤال داره: «قابل ساختنه؟»، «کنترل‌ها رو رد کرده؟»، «برای Release آماده‌ست؟» و آخرش «باید Deploy بشه یا منتظر تصمیم بمونه؟»

تفاوت CI/CD با CI/CD Pipeline چیست؟

این دو تا خیلی نزدیکن، ولی یکی نیستن. CI/CD یه رویکرده؛ Pipeline سازوکار اجرایی اون رویکرده.

یه تشبیه ساده: روش ثابت آماده‌سازی و کنترل یه سفارش شبیه CI/CDه؛ مسیری که سفارش واقعاً از ایستگاه‌های مختلف رد می‌شه شبیه Pipelineه. تو نرم‌افزار هم تیم رویکرد رو انتخاب می‌کنه و Pipeline اون تصمیم رو مرحله‌به‌مرحله اجرا می‌کنه.

Pipeline از کجا شروع می‌شود؟ Code Change و Trigger

نقطه شروع معمول یه Pipeline، یه Code Change یا رویدادیه که به تغییر کد مربوطه. تو مثال فروشگاه، Developer منطق سبد خرید رو اصلاح کرده و تغییرش وارد Repository شده. حالا باید چیزی به سیستم بگه «وقتشه جریان بررسی رو شروع کنی».

اون اتفاق رو به‌صورت مفهومی Trigger می‌گیم؛ یعنی رویدادی که Pipeline رو راه می‌اندازه. برای این مقاله لازم نیست وارد این بشیم که Trigger دقیقاً با چه تنظیمی یا روی چه رویدادی تعریف شده. چیزی که باید تو ذهنت بمونه اینه که Pipeline خودبه‌خود و بی‌دلیل اجرا نمی‌شه؛ یه رویداد مشخص شروعش می‌کنه.

از اینجا تغییر سبد خرید وارد یه مسیر کنترل‌شده می‌شه. Pipeline کمک می‌کنه همین مسیر هر بار به شکل تکرارپذیر جلو بره.

Build و Test در Pipeline چه نقشی دارند؟

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

اگه تغییر سبد خرید باعث بشه پروژه دیگه Build نشه، Pipeline می‌تونه همین‌جا متوقف بشه؛ نه اینکه مشکل تا Release نهایی پنهان بمونه.

اگه Build خوب جلو بره، نوبت Test می‌رسه. تست‌ها کنترل‌هایی هستن که تیم از قبل برای بررسی رفتار مورد انتظار تعریف کرده. اینجا قرار نیست انواع Test رو باز کنیم؛ فقط نقش اون‌ها مهمه. Pipeline این تست‌ها رو اجرا می‌کنه تا ببینه تغییر جدید چیزی رو که باید درست کار کنه خراب کرده یا نه.

اگه Test مهمی Fail بشه، مسیر معمولاً ادامه پیدا نمی‌کنه. تیم Feedback می‌گیره و Developer برمی‌گرده سراغ تغییر. یکی از ارزش‌های اصلی Pipeline همین‌جاست: تغییر مشکل‌دار قبل از جلو رفتن متوقف شده و سریع خبر داده.

اگه Build و Test موفق باشن، خروجی وارد بخش CD می‌شه. این خروجی می‌تونه یه Artifact باشه؛ یعنی خروجی مشخصی از Build که مرحله‌های بعد باهاش کار می‌کنن.

Delivery و Deployment چگونه نسخه را به Production می‌رسانند؟

بعد از اینکه تغییر سبد خرید Build و Test رو رد کرد، وارد بخش آماده‌سازی برای Release می‌شیم. تو Delivery هدف اینه که نسخه تو وضعیتی باشه که اگه تیم تصمیم به انتشار گرفت، مجبور نشه تازه از اول دنبال Build، تست و جمع‌کردن خروجی بگرده. نسخه از قبل آماده‌ست.

اینجا دوباره تفاوت Manual Approval خودش رو نشون می‌ده. تو Continuous Delivery، تیم می‌تونه بگه «همه‌چیز آماده‌ست، ولی قبل از رفتن به Production یه نفر باید تأیید کنه». پس Pipeline تا نقطه Ready for Release جلو رفته، اما آخرین تصمیم هنوز انسانی مونده.

Deployment یعنی نسخه واقعاً به محیط هدف منتقل بشه. وقتی درباره Production حرف می‌زنیم، منظور محیطیه که کاربران واقعی دارن نسخه نرم‌افزار رو استفاده می‌کنن. پس Production رو با «نسخه آماده» قاطی نکن؛ Ready for Release هنوز لزوماً جلوی کاربر نرفته.

اگه تیم Continuous Deployment داشته باشه، قابلیت سبد خرید بعد از رد کردن کنترل‌های تعیین‌شده می‌تونه بدون Manual Approval اجباری به Production برسه. اگه Continuous Delivery داشته باشه، همون نسخه می‌تونه آماده بمونه تا تیم زمان انتشار رو تأیید کنه.

حالا کل سناریوی فروشگاه رو یک‌جا ببین: Developer قابلیت سبد خرید رو تغییر می‌ده (Code Change). یه رویداد Pipeline رو شروع می‌کنه (Trigger). پروژه آماده خروجی می‌شه (Build). کنترل‌های خودکار روی تغییر اجرا می‌شن (Test). نسخه تأییدشده به حالت قابل انتشار می‌رسه (Delivery). بعد بسته به مدل تیم، با تأیید انسانی یا به‌صورت خودکار به محیط واقعی می‌ره (Deployment / Production).

اگه این مسیر تو ذهنت جا افتاده، مهم‌ترین بخش مقاله رو گرفتی. جزئیات ابزارها بعداً عوض می‌شن، ولی این Mental Model پایه می‌مونه.

اگه می‌خوای از این مدل ذهنی یه قدم جلوتر بری و توسعه یه Web Application واقعی رو با MVC Core و Web API تجربه کنی، دوره پروژه‌محور MVC Core همراه با Web API می‌تونه ادامه طبیعی مسیر یادگیریت باشه. داشتن یه پروژه واقعی کمک می‌کنه بعدها وقتی سراغ Build، Test و Pipeline می‌ری، این مفاهیم فقط چند تا اصطلاح جدا از هم نباشن و Context واقعی‌تری برات داشته باشن.

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

حالا مزایای CI/CD ملموس‌ترن. تو همون فروشگاه، وقتی Build، Test و آماده‌سازی نسخه تو یه جریان تعریف‌شده جلو می‌رن، تیم کمتر انرژی روی کارهای مکانیکی می‌ذاره و زودتر Feedback می‌گیره.

مهم‌ترین مزایای CI/CD

Feedback سریع‌تر: وقتی تغییر نزدیک به زمان ثبت خودش Build و Test می‌شه، Developer لازم نیست چند روز صبر کنه تا بفهمه چیزی شکسته. این فاصله کوتاه‌تر کمک می‌کنه اصلاح مشکل با Context تازه‌تر انجام بشه.

کاهش خطاهای انسانی در مراحل تکراری: منظور این نیست که انسان دیگه خطا نمی‌کنه. منظور اینه که کارهایی که قابل Automation هستن هر بار با روال یکسان اجرا می‌شن و احتمال جا افتادن دستی یه مرحله کمتر می‌شه.

Release قابل تکرارتر: مسیر تعریف‌شده باعث می‌شه Release کمتر به حافظه یه نفر وابسته بمونه و تیم بدونه تغییر از چه کنترل‌هایی رد شده.

کاهش کارهای دستی: Build و تست‌های تکراری نمونه واضح‌ان. هر کاری که قانون مشخص و اجرای ماشینی قابل اعتماد داشته باشه، کاندید خوبیه که از دوش آدم‌ها برداشته بشه.

انتشار تغییرهای کوچک‌تر: وقتی هزینه عبور هر تغییر از مسیر کنترل کمتره، تیم مجبور نیست برای هر Release تعداد زیادی تغییر رو روی هم جمع کنه. تغییر کوچک‌تر معمولاً فهم اثر و پیدا کردن منشأ مشکل رو ساده‌تر می‌کنه.

اعتماد بیشتر به فرایند Release: این اعتماد از جادو نمیاد؛ تیم بارها همون مسیر رو اجرا کرده و می‌دونه چه کنترل‌هایی رد شده. با این حال هیچ Pipeline تضمین نمی‌کنه نرم‌افزار بدون باگه.

آیا CI/CD برای پروژه‌های کوچک هم مفید است؟

بله، حتی یه پروژه کوچک هم می‌تونه از CI/CD سود ببره؛ ولی جواب درست این نیست که «هر پروژه‌ای حتماً یه Pipeline پیچیده می‌خواد».

فرض کن فروشگاه اینترنتی ما فقط سه نفر Developer داره، اما هر هفته چند تغییر منتشر می‌کنه. همین تیم کوچیک اگه Build و Test تکراری داشته باشه، از یه جریان خودکار ساده ارزش واقعی می‌گیره. اندازه تیم کم شده، ولی نیاز به Feedback و تکرارپذیری هنوز سر جاشه.

اگه یه Prototype خیلی موقتی داری که احتمالاً دیگه تغییر نمی‌کنه، راه‌اندازی فرایند پیچیده شاید ارزش زیادی نداشته باشه. ارزش CI/CD به تعداد تغییرات، تکرار Build/Test/Deploy، هزینه خطای دستی و نیاز به Feedback سریع بستگی داره.

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

تفاوت CI/CD و DevOps چیست؟

CI/CD و DevOps به هم نزدیکن، ولی یکی نیستن. CI/CD یه Practice مهم تو مسیر توسعه و انتشار نرم‌افزاره؛ DevOps یه رویکرد گسترده‌تره که فقط به Build و Test و Deployment محدود نمی‌شه.

برای این مقاله همین مرز کافیه. وقتی درباره CI/CD حرف می‌زنیم، تمرکز ما روی جریان تغییر کد، Integration، Validation و رساندن نسخه به Release یا Deployment هست. DevOps دامنه بزرگ‌تری داره و اگه بخوایم همه جنبه‌هاش رو باز کنیم، از سؤال اصلی این صفحه دور می‌شیم.

پس اگه جایی دیدی CI/CD زیر چتر DevOps معرفی شده، تناقضی وجود نداره. CI/CD می‌تونه یکی از رویکردهای مهم یه تیم DevOps باشه، ولی DevOps رو نمی‌شه به CI/CD خلاصه کرد.

آیا برای CI/CD باید Docker یا Kubernetes بلد باشیم؟

خیر. Docker و Kubernetes پیش‌نیاز ذاتی CI/CD نیستن.

این ابزارها تو بعضی معماری‌ها می‌تونن کنار CI/CD استفاده بشن، مخصوصاً وقتی پروژه با کانتینرها یا محیط‌های ارکستریشن کار می‌کنه. ولی خود مفهوم CI/CD وابسته به اون‌ها نیست. یه پروژه می‌تونه بدون Docker و بدون Kubernetes هم Code Change رو بگیره، Build و Test انجام بده و نسخه رو برای Release آماده کنه.

پس اگه تازه داری CI/CD رو یاد می‌گیری، لازم نیست اول وارد دنیای Docker یا Kubernetes بشی. اول همین Mental Model رو خوب بفهم؛ ابزارها بعداً سر جای خودشون قابل یادگیری‌ان.

سوالات متداول درباره CI/CD

جمع‌بندی CI/CD

اگه بخوای بعد از خوندن این مقاله فقط یه تصویر تو ذهنت نگه داری، این رو نگه دار: CI/CD یه رویکرد (Practice) برای کوتاه کردن فاصله بین تغییر کد، بررسی اون و آماده‌کردن نسخه برای Release یا Deployment هست. CI بیشتر روی Integration و Validation تمرکز داره. CD نسخه تأییدشده رو به سمت Delivery یا Deployment جلو می‌بره. Pipeline هم Workflow اجراییه که این مراحل رو با یه ترتیب مشخص پشت سر هم اجرا می‌کنه.

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

Code Change → Trigger → Build → Test → Delivery → Deployment

Developer فروشگاه یه تغییر تو سبد خرید داد. Pipeline با Trigger شروع شد، Build و Test انجام شدن، نسخه Ready for Release شد و بعد یا منتظر Manual Approval موند یا تا Production رفت. این همون فرق مهمه: CI/CD الزاماً Auto Deploy به Production نیست.

قدم بعدی: این مفاهیم رو روی یک پروژه واقعی لمس کن

حالا دیگه CI/CD برات فقط چند تا واژه نیست؛ می‌دونی یه تغییر کد چطور از Build و Test رد می‌شه و به Release یا Deployment می‌رسه. اگه می‌خوای قدم بعدی رو از سمت توسعه واقعی برداری، کار کردن روی یه پروژه MVC Core و Web API بهت Context می‌ده تا بعداً وقتی سراغ Pipeline و ابزارهای CI/CD می‌ری، دقیق‌تر بفهمی هر مرحله چرا وجود داره.

برای ادامه این مسیر، مسیر یادگیری MVC Core همراه با Web API رو ببین و ببین چطور می‌تونی از فهم مفاهیم به کار روی یه پروژه واقعی برسی.