CI/CD چیست؟ یکپارچه‌سازی و تحویل مداوم به زبان ساده
CI/CD روشی برای انتشار نرم‌افزار است که در آن هر تغییر کد خودکار ساخته و تست می‌شود و — اگر قبول شود — برای انتشار آماده یا منتشر می‌شود. CI (یکپارچه‌سازی مداوم) یعنی تغییرات اغلب ادغام می‌شوند و هر بار با تست‌های خودکار بررسی می‌شوند. CD (تحویل یا استقرار مداوم) یعنی تغییراتی که قبول می‌شوند با کمترین یا بدون کار دستی بسته‌بندی شده و به سمت کاربران شما فرستاده می‌شوند.
نکته ساده است: اشتباهات را چند دقیقه بعد از ایجادشان بگیرید، نه هفته‌ها بعد وقتی یک مشتری آن‌ها را پیدا می‌کند.
چرا CI/CD وقتی با هوش مصنوعی می‌سازید مهم است
سازنده‌های برنامه با هوش مصنوعی تغییرات کد را سریع انجام می‌دهند. یک پرامپت می‌تواند ده فایل را تحت تأثیر قرار دهد. این سرعت عالی است تا وقتی که تغییری در صفحه پرداخت، بی‌سروصدا صفحه ورود را خراب کند و کسی متوجه نشود تا وقتی یک کاربر برایتان ایمیل بزند.
CI/CD دقیقاً برای همین، تور ایمنی است. به‌جای اینکه به درستی هر تغییر اعتماد کنید، یک خط لوله هر بار همان بررسی‌ها را اجرا می‌کند:
- آیا برنامه هنوز بدون خطا ساخته می‌شود؟
- آیا تست‌های خودکار هنوز قبول می‌شوند؟
- آیا کد از قواعد پروژه پیروی می‌کند (نوع‌ها، قالب‌بندی، بررسی‌های امنیتی)؟
اگر هر بررسی شکست بخورد، تغییر پیش از رسیدن به کاربران متوقف می‌شود. هرچه تغییرات کد شما سریع‌تر باشد، بررسی‌ای که هرگز خسته نمی‌شود یا مرحله‌ای را جا نمی‌اندازد ارزشمندتر است.
یک تشبیه روزمره
نانوایی‌ای را تصور کنید که هر صبح نان به مغازه‌ها می‌فروشد.
- بدون CI/CD، هر نانوا یک هفته روی تغییرات دستور پخت خودش کار می‌کند، سپس صبح جمعه همه آن‌ها را با هم ترکیب می‌کنند و امیدوارند نان هنوز پف کند. وقتی نمی‌کند، کسی نمی‌داند تغییر کدام نفر باعث آن شده.
- با CI، هر تغییر کوچک دستور پخت فوراً در یک نان آزمایشی پخته و بررسی می‌شود — طعم، وزن، شکل. یک تغییر بد همان روز گرفته می‌شود و دقیقاً می‌دانید کدام بوده.
- با CD، نان‌هایی که از بازرسی رد شوند مستقیم روی ماشین تحویل می‌روند، هر بار با همان بسته‌بندی و برچسب، به‌جای اینکه کسی ساعت ۵ صبح جعبه‌ها را دستی بسته‌بندی کند.
بازرسی نانوایان را بهتر نمی‌کند. اشتباهاتشان را ارزان می‌کند.
خط لوله CI/CD چطور کار می‌کند
خط لوله (pipeline) فهرستی از مراحل است که یک سرویس CI/CD وقتی اتفاقی می‌افتد خودکار اجرا می‌کند — معمولاً وقتی کسی کد را به یک مخزن مثل GitHub push می‌کند. یک خط لوله معمولی این شکل را دارد:
| مرحله | چه اتفاقی می‌افتد | چه چیزی را پیدا می‌کند |
|---|---|---|
| ۱. محرک | کد push می‌شود یا یک درخواست ادغام (pull request) باز می‌شود | — |
| ۲. نصب | یک ماشین تازه کد و وابستگی‌هایش را دانلود می‌کند | بسته‌های گمشده یا خراب |
| ۳. ساخت | برنامه کامپایل یا بسته‌بندی می‌شود | خطاهای نحوی و نوع، importهای خراب |
| ۴. تست | تست‌های خودکار اجرا می‌شوند | ویژگی‌هایی که دیگر کار نمی‌کنند |
| ۵. بررسی‌ها | لینتینگ، قالب‌بندی، اسکن‌های امنیتی | مشکلات سبک کدنویسی، بسته‌های آسیب‌پذیر شناخته‌شده، کلیدهای نشت‌شده |
| ۶. استقرار در محیط آزمایشی (staging) | برنامه به یک نسخه آزمایشی از محیط واقعی می‌رود | مشکلاتی که فقط در یک محیط واقعی ظاهر می‌شوند |
| ۷. استقرار در محیط واقعی (production) | برنامه زنده می‌شود — خودکار یا بعد از تأیید | — |
هر مرحله روی یک ماشین تمیز اجرا می‌شود، نه لپ‌تاپ کسی، پس بهانه «روی کامپیوتر من کار می‌کند» دیگر پذیرفته نیست. اگر یک مرحله شکست بخورد، خط لوله متوقف می‌شود و به کسی که تغییر را انجام داده خبر می‌دهد.
مراحل در یک فایل پیکربندی تعریف می‌شوند که کنار کد قرار دارد. برای مثال در GitHub Actions، این یک فایل YAML در پوشه .github/workflows مخزن است.
تحویل مداوم در برابر استقرار مداوم
کلمه «CD» مبهم است و مردم آن را به هر دو شکل به کار می‌برند:
| تحویل مداوم | استقرار مداوم | |
|---|---|---|
| تست‌ها خودکار اجرا می‌شوند | بله | بله |
| انتشار خودکار بسته‌بندی می‌شود | بله | بله |
| خودکار زنده می‌شود | خیر — یک نفر دکمه «انتشار» را می‌زند | بله — هر تغییر قبول‌شده منتشر می‌شود |
| مناسب برای | بیشتر تیم‌های کوچک، برنامه‌هایی با کاربران پرداخت‌کننده | تیم‌هایی با پوشش تست قوی و پایش |
استقرار مداوم فقط وقتی خوب کار می‌کند که تست‌ها خوب باشند. اگر تست‌های شما پرداخت را پوشش ندهند، استقرار مداوم با خوشحالی یک پرداخت خراب را منتشر می‌کند.
یک مثال کامل: یک برنامه رزرو با خط لوله
فرض کنید یک برنامه رزرو آرایشگاه دارید و کدش در یک مخزن GitHub است. از یک سازنده برنامه با هوش مصنوعی می‌خواهید «۱۰٪ تخفیف برای مشتری‌های اولین بار اضافه کن».
۱. تغییر روی یک شاخه جدید push می‌شود و یک درخواست ادغام (pull request) باز می‌شود. ۲. خط لوله شروع می‌شود. بسته‌ها را نصب و برنامه را می‌سازد — این قبول می‌شود. ۳. تست‌ها را اجرا می‌کند. یک تست، «مشتری برگشتی قیمت کامل می‌پردازد»، شکست می‌خورد: تخفیف برای همه اعمال شده. ۴. درخواست ادغام یک علامت قرمز نشان می‌دهد. تغییر نمی‌تواند ادغام شود. ۵. از هوش مصنوعی می‌خواهید آن را درست کند. اصلاح را push می‌کند؛ خط لوله دوباره اجرا می‌شود و همه‌چیز قبول می‌شود. ۶. تغییر ادغام می‌شود. خط لوله آن را به یک محیط آزمایشی (staging) مستقر می‌کند، جایی که یک رزرو آزمایشی انجام می‌دهید. ۷. تأیید می‌کنید و به محیط واقعی مستقر می‌شود.
بدون خط لوله، مرحله ۳ در کیف پول مشتری‌های شما اتفاق می‌افتاد.
واژه‌های کلیدی
| واژه | معنی |
|---|---|
| خط لوله (Pipeline) | توالی خودکار مراحلی که روی هر تغییر اجرا می‌شود. |
| ساخت (Build) | تبدیل کد منبع به چیزی که می‌تواند اجرا شود. |
| تست خودکار (Automated test) | کدی که بررسی می‌کند کد دیگر کار درستش را انجام می‌دهد. |
| درخواست ادغام (Pull request / PR) | یک تغییر پیشنهادی که دیگران (و خط لوله) پیش از ادغام بررسی می‌کنند. ببینید گیت‌هاب چیست. |
| شاخه (Branch) | یک خط جداگانه از تغییرات، تا کار در حال انجام روی کد اصلی اثر نگذارد. |
| محیط آزمایشی (Staging) | یک کپی خصوصی از برنامه که محیط واقعی را تقلید می‌کند، برای بررسی تغییرات پیش از دیدن کاربران. |
| محیط واقعی (Production) | برنامه زنده‌ای که کاربران شما از آن استفاده می‌کنند. |
| بازگشت به نسخه قبلی (Rollback) | برگشتن به آخرین نسخه کارکنده وقتی یک انتشار مشکل پیدا می‌کند. |
| ساخت سبز / قرمز (Green / red build) | یک اجرای خط لوله که قبول شد / شکست خورد. |
برداشت‌های غلط رایج
- «CI/CD یعنی برنامه من تست شده است.» خط لوله فقط تست‌هایی را اجرا می‌کند که شما دارید. اگر تستی نباشد، CI فقط ثابت می‌کند برنامه ساخته می‌شود — نه بیشتر. از هوش مصنوعی بخواهید تست برای جریان‌های مهم بنویسد.
- «CI/CD فقط برای شرکت‌های بزرگ است.» ابزارهای میزبانی‌شده مثل GitHub Actions برای راه‌اندازی به یک فایل پیکربندی کوتاه نیاز دارند و تیم‌های کوچک دائم از آن‌ها استفاده می‌کنند. تلاش اصلی برای تست‌ها است، نه ابزار.
- «استقرار خودکار یعنی هیچ کس چیزی را بررسی نمی‌کند.» خط لوله‌های خوب بررسی اضافه می‌کنند، نه اینکه حذف کنند. بسیاری از تیم‌ها پیش از محیط واقعی یک مرحله تأیید انسانی نگه می‌دارند.
- «اگر خط لوله سبز است، برنامه کار می‌کند.» یعنی بررسی‌های خودکار قبول شده‌اند. باید خودتان هم تغییر را امتحان کنید، ترجیحاً در پیش‌نمایش یا روی محیط آزمایشی.
- «CI/CD جایگزین پشتیبان‌گیری است.» نیست. یک مهاجرت بد پایگاه داده که تست‌ها را رد کند همچنان می‌تواند داده واقعی را آسیب بزند. پشتیبان و راهی برای بازگشت نگه دارید.
از سازنده هوش مصنوعی خود چه بپرسید
- «برای ثبت‌نام، ورود و پرداخت تست‌های خودکار بنویس و نشان بده چطور اجرایشان کنم.»
- «یک workflow برای GitHub Actions تنظیم کن که وابستگی‌ها را نصب کند، برنامه را بسازد و در هر درخواست ادغام تست‌ها را اجرا کند.»
- «یک بررسی نوع و یک linter به خط لوله اضافه کن و آن را روی خطاها شکست بده.»
- «هر مرحله از خط لوله را با زبان ساده توضیح بده.»
- «اگر استقرار وسط کار شکست بخورد چه می‌شود؟ چطور برگردم به نسخه قبلی؟»
- «بررسی کن هیچ رازی در مخزن به‌صورت ثابت در کد نوشته نشده یا در لاگ‌های خط لوله چاپ نمی‌شود.»
اگر برنامه شما از کلیدهای API استفاده می‌کند، خط لوله هم به آن‌ها نیاز دارد — به‌صورت رازهای رمزنگاری‌شده در ابزار CI ذخیره شوند، نه در فایل پیکربندی. ببینید متغیرهای محیطی و رازها.
CI/CD و Mythex
Mythex یک خط لوله CI برای شما اجرا نمی‌کند، اما بعضی از همین نیازها را به روش خودش پوشش می‌دهد:
- نقاط بازرسی (Checkpoints). بعد از هر نوبت موفق عامل، Mythex یک نقطه بازرسی git ذخیره می‌کند و بازگشت به این نقطه (Revert to this point) پروژه را برمی‌گرداند اگر یک تغییر اشتباه بوده باشد. ببینید گفت‌وگو.
- آزمایش برنامه (App Testing). تایپ کنید
/testو عامل مثل یک کاربر روی پیش‌نمایش زنده شما کلیک می‌کند و جریان‌های خراب را گزارش می‌دهد — قبل از هر انتشار مفید است. ببینید App Testing. - انتشار یک مرحله عمدی است. تغییرات ابتدا در پیش‌نمایش خصوصی ظاهر می‌شوند؛ برنامه عمومی شما فقط وقتی به‌روز می‌شود که دوباره منتشر کنید — به تحویل مداوم نزدیک‌تر است تا استقرار مداوم.
- همگام‌سازی با GitHub (Pro). پروژه را با یک مخزن GitHub همگام کنید و می‌توانید workflowهای GitHub Actions خودتان را برای اجرای تست‌ها در هر push اضافه کنید. ببینید GitHub و خروجی گرفتن.
برای فهرست آنچه پیش از رفتن به محیط واقعی باید دستی تست کنید، چطور برنامه‌تان را قبل از راه‌اندازی تست کنید را ببینید، و برای کار با کنترل نسخه، چطور از Git با یک برنامه ساخته‌شده با هوش مصنوعی استفاده کنید.
پرسش‌ها
CI/CD مخفف چیست؟
CI مخفف continuous integration (یکپارچه‌سازی مداوم) است: هر تغییر کد اغلب ادغام می‌شود و خودکار ساخته و تست می‌شود. CD مخفف continuous delivery (تحویل مداوم) یا continuous deployment (استقرار مداوم) است: تغییراتی که تست‌ها را رد می‌کنند، به‌طور خودکار برای انتشار آماده (تحویل) یا بدون مرحله دستی به کاربران منتشر (استقرار) می‌شوند.
تفاوت تحویل مداوم و استقرار مداوم چیست؟
در تحویل مداوم، هر تغییری که خط لوله را قبول کند آماده انتشار است، اما هنوز یک نفر تصمیم می‌گیرد کی آن را زنده کند. در استقرار مداوم، هر تغییر قبول‌شده خودکار زنده می‌شود و هیچ مرحله تأیید انسانی ندارد.
آیا برای یک برنامه کوچک ساخته‌شده با هوش مصنوعی به CI/CD نیاز دارم؟
روز اول نه. یک برنامه کوچک با تعداد کمی کاربر می‌تواند با تست در پیش‌نمایش و انتشار دستی کار کند. CI/CD وقتی ارزشش را نشان می‌دهد که چند نفر کد را تغییر دهند، مشتری‌های واقعی به برنامه وابسته شوند، یا مدام چیزهایی را که قبلاً کار می‌کردند خراب کنید.
برای CI/CD از چه ابزارهایی استفاده می‌شود؟
ابزارهای رایج شامل GitHub Actions، GitLab CI/CD، CircleCI و Jenkins هستند، به‌علاوه خط لوله‌های استقرار داخلی پلتفرم‌های میزبانی. همه کار پایه یکسانی انجام می‌دهند: هر وقت کد تغییر کند، فهرستی از مراحل را خودکار اجرا می‌کنند.