CI/CD چیست؟ یکپارچه‌سازی و تحویل پیوسته نرم‌افزار

CI/CD مخفف دو ایدهٔ به‌هم‌پیوسته است: Continuous Integration (یکپارچه‌سازی پیوسته) و Continuous Delivery یا Continuous Deployment (تحویل یا استقرار پیوسته). هدف کاهش فاصلهٔ بین تغییر کد و رسیدن ارزش به کاربر است — با خودکارسازی build، تست و در صورت آمادگی، انتشار — نه با عجلهٔ بی‌کنترل.

GitHub Actions را مستندات رسمی یک پلتفرم CI/CD می‌نامد که می‌تواند هر pull request را بسازد و تست کند یا تغییرات ادغام‌شده را به Production ببرد. Docker هم Container را برای جریان‌های CI/CD مناسب می‌داند چون محیط تست و اجرا یکنواخت می‌شود. Kubernetes تأکید می‌کند خودش CI را دیکته نمی‌کند؛ فرهنگ و نیاز سازمان مسیر را مشخص می‌کند.

این مقاله واژگان را جدا می‌کند، اجزای یک workflow را با زبان GitHub Actions توضیح می‌دهد، و به مقالهٔ استقرار (۰۵۰) و کانتینر (۱۰۵) وصل می‌شود.

پاسخ کوتاه

CI یعنی هر تغییر مهم (معمولاً با push یا pull request) به‌صورت خودکار ساخته و تست شود تا شکستن main زود دیده شود. Continuous Delivery یعنی همیشه یک artifact آماده‌ٔ انتشار داشته باشید که با یک تصمیم/تأیید به محیط واقعی برود. Continuous Deployment یعنی همان مسیر تا Production بدون تأیید دستی پیش برود — فقط وقتی تست، مشاهده‌پذیری و Rollback واقعاً پخته باشند دفاع‌پذیر است.

CI/CD ابزار جادویی کیفیت نیست؛ کیفیت را زودتر و تکرارپذیرتر بررسی می‌کند. بدون تست معنادار، pipeline فقط سرعت خرابکاری را بالا می‌برد.

اول CI سبز و قابل اعتماد بسازید؛ CD را وقتی Rollback و healthcheck دارید روشن کنید.

CI، Delivery و Deployment — سه لایه

• Continuous Integration: ادغام مکرر تغییرات در شاخهٔ مشترک + build/تست خودکار.
• Continuous Delivery: آماده‌بودن همیشگی برای انتشار؛ Deploy به Production معمولاً با تأیید.
• Continuous Deployment: هر تغییر پاس‌شده به‌طور خودکار به Production می‌رود.

در گفتگوی فارسی گاهی همه را «سی‌آی‌سی‌دی» می‌گویند. برای تصمیم، مشخص کنید کدام لایه را می‌خواهید امسال. بیشتر تیم‌های در حال رشد از CI قوی + Deploy خودکار به Staging + Deploy دستی/تأییدی به Production سود می‌برند.

اجزای GitHub Actions به‌عنوان مدل ذهنی

حتی اگر از GitLab CI یا Jenkins استفاده کنید، این واژه‌ها قابل نگاشت‌اند:

• Workflow: فرایند خودکار تعریف‌شده با YAML در مخزن (مثلاً `.github/workflows`).
• Event: رویداد تریگر — push، pull_request، زمان‌بندی، یا دستی.
• Job: مجموعه‌ای از stepها روی یک runner؛ jobها موازی یا وابسته.
• Step: اسکریپت یا action آماده‌ (checkout، setup زبان، build).
• Action: واحد قابل‌استفادهٔ مجدد برای کارهای تکراری.
• Runner: ماشینی که job را اجرا می‌کند (میزبان GitHub یا self-hosted).

مستندات GitHub می‌گوید هر job در VM یا Container تازه اجرا می‌شود و stepها روی همان runner به ترتیب به داده‌های هم دسترسی دارند. Matrix می‌تواند یک job را روی چند نسخهٔ زبان/OS تکرار کند.

پیوند با Container و Deployment

Docker سناریوی رایجی را توصیف می‌کند: توسعه محلی در Container، push به محیط تست، رفع باگ، و ارسال Image به‌روز به Production. CI این مسیر را از حافظهٔ فردی خارج می‌کند: همان Dockerfile، همان تست، همان Registry.

مقالهٔ ۰۵۰ مسیر Build / Release / Run را از Twelve-Factor گفت. CI معمولاً Build و تست را مالک می‌شود؛ CD Release را به محیط می‌رساند. Artifact یکسان بین Staging و Production همچنان طلایی است.

جدول تصمیم مرحله‌ای برای تیم کوچک

چه چیزهایی را در pipeline بگذارید؟

1. Checkout و نصب وابستگی با قفل نسخه.
2. Lint/format در صورت ارزش تیمی.
3. تست واحد و در صورت امکان تست یکپارچهٔ سبک.
4. Build artifact یا Image با تگ/digest.
5. اسکن آسیب‌پذیری اولیهٔ وابستگی/Image (در حد ظرفیت).
6. Deploy به Staging با Secret محیط.
7. تأیید و Deploy Production با concurrency تا روی هم نیفتند.

همه را روز اول لازم ندارید. یک PR سبز که تست را اجرا کند از صفر بهتر است؛ پیچیدگی را با درد اضافه کنید.

ضدالگوها

• Pipeline قرمز طولانی که همه Ignore می‌کنند.
• Deploy مستقیم از لپ‌تاپ در حالی که CI همان commit را نساخته.
• Secret در لاگ workflow یا در متغیر بدون محیط جدا.
• تست‌هایی که به شبکهٔ ناپایدار بیرون وابسته‌اند و flaky شده‌اند.
• Continuous Deployment بدون healthcheck و مالک on-call.

CI/CD و Kubernetes

K8s محل اجرای وضعیت مطلوب است نه کارخانهٔ build. منیفست‌ها Image را از Registry می‌کشند؛ ساخت Image کار CI است. مستندات Kubernetes صریحاً می‌گوید سورس را deploy و اپ را build نمی‌کند و CI/CD به ترجیح سازمان وابسته است. پس «روی K8s رفتیم» جایگزین طراحی pipeline نیست.

جمع‌بندی برای تصمیم

CI/CD مسیر خودکار از تغییر کد تا اطمینان و در نهایت انتشار است. CI یکپارچگی و تست مکرر می‌آورد؛ Delivery آمادگی انتشار؛ Deployment خودکارسازی کامل تا Production. با مدل workflow/job/runner فکر کنید، از مرحلهٔ ۱ جدول بلوغ شروع کنید، و artifact یکسان را حفظ کنید.

اگر یک بهبود این اسپرینت می‌خواهید: روی هر pull request به main، تست و build را اجباری کنید. بعد Deploy Staging را وصل کنید. Production را آخرین چراغ روشن کنید.

منابع و مراجع

• GitHub Docs — Understanding GitHub Actions — https://docs.github.com/en/actions/about-github-actions/understanding-github-actions
• Docker Docs — What is Docker? (CI/CD workflows) — https://docs.docker.com/get-started/docker-overview/
• Kubernetes Docs — What Kubernetes is not (CI/CD) — https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/

برای استقرار مقالهٔ ۰۵۰ و برای مشاهده بعد از انتشار مقالات ۱۱۳ و ۱۱۴ را ببینید.