مقاله 06 / استقرار خودکار
راه‌اندازی CI/CD با GitHub Actions؛ مسیر انتشار قابل تکرار
مشخصات پیشنهادی انتشار
- عنوان سئو
- راه‌اندازی CI/CD با GitHub Actions | نگهبان وب
- توضیح متا
- مسیر CI/CD را از تست و ساخت خروجی تا staging و production طراحی کنید؛ مدیریت secrets، انتشار هم‌زمان، migration و بازگشت نسخه را بشناسید.
- مسیر پیشنهادی
- /blog/github-actions-cicd
- عبارت اصلی
- راه‌اندازی CI/CD
- تصویر
- github-actions-cicd.webp
- یادداشت انتشار
- تصویر را در CMS بارگذاری و تاریخ واقعی انتشار و URL تصویر را ثبت کنید.
CI/CD زمانی به تیم کمک می‌کند که انتشار نسخه جدید به مجموعه‌ای از فرمان‌های حفظ‌شده در ذهن یک نفر وابسته نباشد. کد باید بررسی شود، خروجی مشخصی ساخته شود و همان خروجی با تنظیمات کنترل‌شده به محیط مقصد برسد. اگر انتشار شکست خورد، تیم باید بداند چه نسخه‌ای فعال است و چگونه به وضعیت سالم برگردد.
GitHub Actions یکی از ابزارهای اجرای این مسیر است. اما داشتن یک فایل workflow به معنی کامل بودن فرایند انتشار نیست. مسئولیت secrets، دسترسی runner، تغییرات دیتابیس و بررسی سلامت همچنان باید طراحی و مستند شود.
در CI، تغییرات کد مرتب بررسی و با آزمون‌های مناسب ترکیب می‌شوند. در تحویل پیوسته، خروجی آماده انتشار تولید می‌شود و ورود آن به محیط واقعی می‌تواند با تصمیم انسانی انجام شود. در استقرار پیوسته، تغییر واجد شرایط می‌تواند بدون تصمیم دستی جداگانه منتشر شود.
انتخاب این مدل‌ها به ریسک تغییر، توان آزمون و نیاز تیم بستگی دارد. برای محصولی با migration حساس یا فرایند تأیید مشخص، توقف کنترل‌شده پیش از production می‌تواند منطقی باشد. هدف، کوتاه و قابل اعتماد شدن مسیر است، نه حذف هر نوع بررسی.
ابتدا فرایند فعلی را بنویسید
مراحل نصب وابستگی، اجرای تست، ساخت خروجی، تغییر دیتابیس و شروع سرویس را فهرست کنید. هر فرمانی که به‌صورت دستی روی سرور اجرا می‌شود باید صاحب، ورودی و نتیجه مشخص داشته باشد. اگر مرحله‌ای هنوز نامعلوم است، خودکار کردن آن ابهام را سریع‌تر تکرار می‌کند.
برای هر محیط نیز آدرس، پیکربندی و دسترسی مستقل تعریف کنید. staging نباید ناخواسته پیامک یا پرداخت واقعی ایجاد کند. داده آزمایشی باید مناسب همان محیط باشد و استفاده از داده واقعی نیازمند کنترل‌های مربوط به حریم خصوصی است.
پنج مرحله پیشنهادی برای مسیر انتشار
| مرحله | خروجی مورد انتظار | شرط ادامه |
|---|---|---|
| بررسی کد | خطاهای قابل شناسایی و نتیجه تست | عبور از بررسی‌های لازم پروژه |
| ساخت | image یا artifact با شناسه ثابت | امکان ردیابی به commit |
| آزمون staging | نتیجه تست مسیرهای اصلی | تأیید آمادگی نسخه |
| انتشار production | نسخه فعال ثبت‌شده | دسترسی مجاز و شروط محیط |
| تأیید پس از انتشار | سلامت سرویس و شاخص‌ها | تصمیم تثبیت یا بازگشت |
خروجی ساخته‌شده را با شناسه تغییرناپذیر نگه دارید. ساخت دوباره در هر سرور می‌تواند نتیجه متفاوتی از نسخه آزمایش‌شده تولید کند. نسخه image، commit و زمان انتشار باید در گزارش ثبت شوند تا عیب‌یابی بعدی امکان‌پذیر باشد.
secrets و مجوزها را محدود کنید
اعتبارنامه انتشار را داخل کد یا لاگ ننویسید. دسترسی workflow را به حد نیاز کاهش دهید و secrets محیط production را از محیط آزمایشی جدا کنید. قابلیت‌های environment و قواعد محافظت GitHub بسته به نوع مخزن و پلن متفاوت‌اند؛ پیش از طراحی تأییدکننده اجباری، دسترسی واقعی حساب را بررسی کنید.
runner خودمیزبان نیازمند نگهداری و کنترل دسترسی مستقل است. اجرای کد غیرقابل اعتماد روی ماشینی که دسترسی انتشار دارد می‌تواند به منابع production آسیب بزند. کارهای بررسی عمومی و کارهای دارای دسترسی حساس را با مرز روشن طراحی کنید.
انتشارهای هم‌زمان را مدیریت کنید
اگر دو workflow هم‌زمان یک محیط را تغییر دهند، ممکن است نسخه‌ها و migrationها با هم تداخل کنند. برای هر محیط ترتیب اجرا و قفل انتشار تعریف کنید. لغو خودکار انتشار قبلی هم همیشه مناسب نیست؛ توقف وسط تغییر دیتابیس می‌تواند وضعیت نیمه‌کاره بسازد.
سیاست باید مشخص کند کدام کارها قابل لغوند و کدام‌ها باید تا پایان امن ادامه یابند. برای نمونه، ساخت آزمایشی یک commit قدیمی با اجرای migration روی production یکسان نیست. این تفاوت را در طراحی concurrency و اسکریپت‌ها لحاظ کنید.
migration و بازگشت را با هم طراحی کنید
برگشت image الزاماً تغییر دیتابیس را برنمی‌گرداند. اگر نسخه جدید ستونی را حذف کرده باشد، اجرای نسخه قدیمی ممکن است شکست بخورد. تغییرات سازگار و مرحله‌ای، مانند اضافه کردن ساختار جدید پیش از حذف قدیمی، مسیر کم‌ریسک‌تری ایجاد می‌کنند.
پیش از تغییر حساس، وضعیت بکاپ و برنامه بازیابی را بررسی کنید. معیار شکست هم باید روشن باشد: خطای مسیر اصلی، افت سلامت یا افزایش مشخص خطاها براساس خط پایه پروژه. چک‌لیست انتشار نگهبان وب برای ثبت این تصمیم‌ها مفید است.
چه چیزی در تحویل پروژه CI/CD باید وجود داشته باشد؟
workflow و اسکریپت‌ها، راهنمای افزودن secret، روش اجرای دستی کنترل‌شده، ثبت نسخه و دستورالعمل بازگشت را تحویل بگیرید. یک نفر دیگر از تیم باید بتواند با مستندات، مسیر انتشار را بفهمد. سپس با یک تغییر کم‌اثر و قابل برگشت، زنجیره را در محیط مناسب آزمایش کنید.
پرسش‌های رایج
آیا CI/CD حتماً به Kubernetes نیاز دارد؟
خیر. برای بسیاری از پروژه‌ها می‌توان مسیر قابل تکرار روی یک سرور یا Docker Compose طراحی کرد. انتخاب ابزار باید متناسب با نیاز باشد.
آیا عبور تست‌ها سلامت production را تضمین می‌کند؟
خیر. تنظیمات، داده و وابستگی‌های محیط واقعی متفاوت‌اند. بررسی پس از انتشار و پایش لازم است.
برای طراحی این مسیر، درخواست راه‌اندازی CI/CD را همراه فناوری پروژه، روش فعلی انتشار و مشکلات تکرارشونده ثبت کنید.
