هر دیپلوی یک استرس است و فقط یک نفر بلد است
انتشار نسخه جدید با اتصال SSH، git pull و ریستارت دستی انجام میشود. اگر آن فرد در دسترس نباشد انتشار متوقف است و اگر مرحلهای فراموش شود، سرویس از کار میافتد.
DevOps و امنیت پیشرفته · CI/CD
پیاده سازی CI/CD و اتوماسیون دیپلوی
پیادهسازی CI/CD یعنی هر تغییر کد بهطور خودکار build و تست شود و از یک مسیر مشخص و قابل برگشت به سرور برسد. کانفیگ سرور pipelineهای GitLab CI، Jenkins و GitHub Actions را طراحی میکند و روی زیرساخت شما راه میاندازد.
GitLab CI · Runner
Jenkins
GitHub Actions
Docker · Harbor
چه زمانی به این خدمت نیاز دارید؟
نشانههایی که انتشار نرمافزار شما به CI/CD نیاز دارد
باگها بعد از انتشار پیدا میشوند
تستها نوشته شدهاند، اما کسی پیش از انتشار اجرایشان نمیکند. در CI، هر merge request پیش از ادغام بهطور خودکار build و تست میشود.
pipeline روی سرویس خارجی به دلیل محدودیتها متوقف شد
دسترسی کاربران و سرورهای ایران به سرویسهایی مثل GitHub و GitLab.com در سالهای اخیر با محدودیتهای ناشی از تحریم و اختلال اینترنت همراه بوده است. GitLab و runner روی زیرساخت خودتان این ریسک را کم میکند.
خدمات CI/CD
راهاندازی CI/CD شامل چه کارهایی است؟
کار شامل انتخاب ابزار متناسب با تیم، راهاندازی runner یا GitLab داخلی، نوشتن pipeline از build تا deploy و مستندسازی مسیر بازگشت به نسخه قبلی است.
طراحی CI/CD pipeline
مسیری روشن از commit تا production طراحی میکنیم.
- مراحل build، تست، ساخت ایمیج و deploy متناسب با پروژه
- قواعد شاخهبندی و merge برای محیطهای تست و production
- تأیید دستی پیش از انتشار روی production در صورت نیاز
GitLab CI/CD و GitLab داخلی
کد، pipeline و رجیستری روی زیرساخت خودتان میماند.
- راهاندازی GitLab خودمیزبان روی سرور سازمان
- نصب و ثبت GitLab Runner با executor مناسب، مثل Shell یا Docker
- نوشتن فایل gitlab-ci.yml با cache و artifact برای سرعت بیشتر
Jenkins
برای تیمهایی است که Jenkins دارند یا به انعطاف آن نیاز دارند.
- راهاندازی Jenkins و agentهای اجرای job
- pipeline بهصورت کد با Jenkinsfile
- مدیریت credentialها و بهروزرسانی کنترلشده پلاگینها
GitHub Actions با runner خودمیزبان
jobها روی سرورهای خودتان اجرا میشوند.
- نوشتن workflow برای build، تست و deploy
- راهاندازی self-hosted runner برای دسترسی به سرورهای داخلی
- مدیریت secretها و محدود کردن دسترسی runner
ساخت ایمیج و رجیستری
هر نسخه خروجی قابل ردیابی دارد.
- build ایمیج Docker در pipeline و تگگذاری با شماره نسخه یا commit
- push ایمیج به Harbor یا رجیستری GitLab
- استفاده از میرور و cache برای کاهش وابستگی به Docker Hub
دیپلوی خودکار و بازگشت
انتشار قابل تکرار است و به نسخه قبلی برمیگردد.
- استقرار خودکار روی سرور با Docker Compose یا اسکریپت کنترلشده روی SSH
- بررسی healthcheck پس از انتشار و توقف در صورت خطا
- بازگشت سریع به نسخه قبلی با تگ ایمیج قبلی
راهنمای کامل
راهنمای پیادهسازی CI/CD برای تیم نرمافزار
CI یعنی هر تغییر کد پس از push بهطور خودکار build و تست شود و CD یعنی نسخهای که از این مراحل گذشته، با یک تأیید دستی یا کاملاً خودکار از مسیر مشخصی به سرور برسد. pipeline مجموعه همین مراحل است و اگر یکی از آنها شکست بخورد، نسخه خراب به production نمیرسد. پیادهسازی CI/CD برای تیم کوچک هم فایده دارد، چون انتشار را از حافظه یک نفر جدا میکند و قابل تکرار میکند. نکتههای زیر انتخاب ابزار، طراحی pipeline، امنیت و مسیر بازگشت را توضیح میدهد.
انتخاب ابزار: GitLab CI، Jenkins یا GitHub Actions
محل نگهداری کد اولین معیار انتخاب است. اگر کد در GitLab است یا میخواهید مخزن، pipeline و رجیستری در یک سامانه باشند، GitLab CI سادهترین مسیر است. Jenkins انعطاف و پلاگینهای بیشتری دارد و برای pipelineهای پیچیده یا ابزارهای متنوع مناسب است، اما بهروزرسانی Jenkins و پلاگینهایش کار منظمی میخواهد. GitHub Actions با runner خودمیزبان jobها را روی سرورهای شما اجرا میکند، ولی خود runner همچنان به github.com وصل میشود.
دسترسی کاربران و سرورهای ایران به GitHub و GitLab.com با محدودیتهای ناشی از تحریم و اختلال اینترنت همراه بوده و این محدودیتها ممکن است بدون اطلاع قبلی تغییر کنند. برای سازمانی که انتشار نرمافزارش نباید متوقف شود، GitLab خودمیزبان همراه GitLab Runner روی سرورهای خود سازمان پایدارترین گزینه است. اگر تیم Jenkins دارد و با آن راحت است، معمولاً مرتب کردن همان Jenkins کمهزینهتر از عوض کردن ابزار است.
طراحی pipeline از build تا deploy
pipeline خوب زود شکست میخورد: تستها و بررسیهای کوتاه اول اجرا میشوند تا خطا پیش از ساخت ایمیج و استقرار معلوم شود. cache وابستگیها و artifact مراحل قبلی زمان اجرا را کم میکنند. برای پروژهای که روی Docker اجرا میشود، مراحل معمول اینهاست:
- دریافت کد و نصب وابستگیها با cache
- اجرای تستها و بررسیهای خودکار
- ساخت ایمیج Docker و تگگذاری با شماره نسخه یا commit
- push ایمیج به Harbor یا رجیستری GitLab
- استقرار روی محیط تست
- تأیید دستی، استقرار روی production و اجرای healthcheck
قواعد شاخهبندی را هم کنار pipeline تعیین کنید: merge request فقط وقتی ادغام شود که pipeline آن موفق بوده و استقرار روی production فقط از شاخه محافظتشده انجام شود. اگر اپلیکیشن هنوز Dockerfile ندارد، کانتینرسازی آن پیش از pipeline در خدمات Docker و کانتینرسازی انجام میشود. برای کم کردن وابستگی به Docker Hub، ایمیجهای پایه را از میرور یا cache داخلی بگیرید.
امنیت runner و secretها
runner کدی را اجرا میکند که در مخزن نوشته شده و معمولاً به سرورهای production هم دسترسی دارد، پس یکی از حساسترین سرورهای زیرساخت است. runner را روی سرور یا ماشین مجازی جدا نصب کنید و در صورت امکان executor از نوع Docker را انتخاب کنید تا هر job در محیط تمیز و جدا اجرا شود. رمزها و کلیدهای SSH را در متغیرهای محافظتشده CI یا مدیریت credential در Jenkins نگه دارید و فقط در اختیار jobهای شاخههای محافظتشده بگذارید.
کاربری که pipeline با آن روی سرور مقصد دیپلوی میکند، باید فقط به همان سرویس دسترسی داشته باشد. دسترسی runner خودمیزبان GitHub Actions را هم به مخزنهای مشخص محدود کنید. خود سرورهای مقصد دیپلوی باید جداگانه سختسازی شوند و این کار در امنسازی سرور انجام میشود.
دیپلوی قابل بازگشت و پایش بعد از انتشار
چون هر نسخه با تگ مشخص ساخته میشود، بازگشت یعنی deploy دوباره تگ قبلی. این بازگشت را پیش از تحویل یک بار آزمایش میکنیم تا روز مشکل اولین اجرای آن نباشد. تغییرات دیتابیس بازگشت را سختتر میکنند، پس migration را طوری بنویسید که نسخه قبلی اپلیکیشن هم با ساختار جدید کار کند؛ مثلاً ستون جدید اضافه شود و حذف ستون قدیمی به انتشار بعدی بماند. پس از هر انتشار healthcheck اجرا میشود و اگر شکست بخورد، pipeline متوقف میشود.
healthcheck فقط زنده بودن سرویس را نشان میدهد. نرخ خطا و زمان پاسخ نسخه جدید را در سامانه پایش دنبال کنید تا مشکلی که در تست دیده نشده زود پیدا شود؛ این بخش در خدمات مانیتورینگ و Observability طراحی میشود. روی یک یا چند سرور، استقرار با Docker Compose روی SSH کافی است و وقتی سرویسها روی کلاستر اجرا شوند، دیپلوی در استقرار و مدیریت Kubernetes ادامه پیدا میکند.
زمان و هزینه پیادهسازی CI/CD به چه بستگی دارد؟
تعداد پروژهها و سرویسها، وضعیت تستهای موجود، نیاز به راهاندازی GitLab خودمیزبان، تعداد محیطها و مقصدهای دیپلوی پایه برآورد هستند. pipeline را اول برای یک پروژه نمونه اجرا میکنیم تا تیم با روند جدید آشنا شود و بعد به پروژههای دیگر گسترش میدهیم، پس زمان کل به تعداد پروژههای بعدی هم بستگی دارد. نوشتن تستهای نرمافزاری جزو این خدمت نیست. برای برآورد، محل نگهداری کد، زبان اپلیکیشن، روش فعلی انتشار و سرورهای مقصد را بفرستید.
رمزها و کلیدهای SSH را در فایل gitlab-ci.yml، Jenkinsfile یا workflow ننویسید. هر کسی که به مخزن دسترسی دارد تاریخچه این فایلها را هم میبیند و رمزی که یک بار commit شده، با پاک کردن در commit بعدی از تاریخچه حذف نمیشود.
فرآیند اجرای کار
پیادهسازی CI/CD در چهار گام
بررسی روند فعلی توسعه و انتشار
مخزن کد، شاخهها، تستهای موجود، محیطها و روش فعلی انتشار را بررسی میکنیم و گلوگاهها و ریسکها را فهرست میکنیم.
انتخاب ابزار و طراحی pipeline
بر اساس محل نگهداری کد و شرایط دسترسی، ابزار و محل اجرای runnerها را انتخاب میکنیم و مراحل pipeline را با تیم توسعه شما نهایی میکنیم.
اجرا روی یک پروژه نمونه
pipeline را اول برای یک سرویس اجرا، تست و بهینه میکنیم تا تیم با روند جدید آشنا شود و بعد آن را به پروژههای دیگر گسترش میدهیم.
تحویل و مستندسازی
فایلهای pipeline در مخزن کد، راهنمای افزودن پروژه جدید و روش بازگشت به نسخه قبلی را به تیم شما تحویل میدهیم.
محدوده خدمت پیادهسازی CI/CD
شامل این خدمت
- طراحی pipeline برای build، تست و deploy
- راهاندازی GitLab خودمیزبان و GitLab Runner
- راهاندازی Jenkins یا runner خودمیزبان GitHub Actions
- ساخت ایمیج Docker در pipeline و اتصال به Harbor
- دیپلوی خودکار با امکان بازگشت و مستندسازی
خارج از این خدمت
- کانتینرسازی اولیه اپلیکیشن و نوشتن Dockerfile در خدمات Docker و کانتینرسازی
- پایش سرویس پس از انتشار در خدمات مانیتورینگ و Observability
- امنسازی سرورهای مقصد دیپلوی در امنسازی سرور
- استقرار روی Kubernetes، که خدمت مستقل استقرار و مدیریت Kubernetes است
- نوشتن تستهای نرمافزاری یا تغییر کد اپلیکیشن
چرا کانفیگ سرور؟
CI/CD متناسب با واقعیت زیرساخت در ایران
این خدمت بخشی از خدمات DevOps و امنیت کانفیگ سرور است. Pipelineی که به دسترسی بیوقفه به سرویسهای خارجی وابسته باشد، در روز اختلال متوقف میشود، پس محل کد، runnerها و ایمیجها را از ابتدا با در نظر گرفتن این ریسک طراحی میکنیم.
01
GitLab CI، Jenkins و GitHub Actions
ابزار را بر اساس تیم و محل نگهداری کد شما انتخاب میکنیم و اگر تیم ابزاری دارد، تا جای ممکن همان را نگه میداریم.
02
زیرساخت خودمیزبان
GitLab، runnerها و Harbor را روی سرورهای سازمان راه میاندازیم تا وابستگی به سرویسهای خارجی کم شود.
03
دیپلوی با مسیر بازگشت
هر انتشار نسخهدار است و بازگشت به نسخه قبلی را پیش از تحویل تست میکنیم.
04
مشاوره اولیه رایگان
روش فعلی انتشار را در تلگرام شرح دهید تا ابزار و pipeline پیشنهادی را پیش از هر تعهدی با شما مرور کنیم.
سوالات متداول
پرسشهای رایج درباره پیادهسازی CI/CD
CI/CD چیست؟
CI یا یکپارچهسازی مداوم یعنی هر تغییر کد بهطور خودکار build و تست شود. CD دو معنای نزدیک دارد: تحویل مداوم (Continuous Delivery) که نسخه همیشه آماده انتشار است و انتشار با یک تأیید انجام میشود، و استقرار مداوم (Continuous Deployment) که انتشار هم بدون دخالت دستی انجام میشود.
CI/CD pipeline چیست؟
pipeline مجموعه مراحل پشتسرهمی است که پس از هر push اجرا میشود و معمولاً build، تست، ساخت ایمیج و deploy را شامل میشود. اگر مرحلهای شکست بخورد، مراحل بعدی اجرا نمیشوند و نسخه خراب به production نمیرسد.
GitLab CI بهتر است یا Jenkins؟
اگر کد شما در GitLab است یا میخواهید کد، pipeline و رجیستری را در یک سامانه داشته باشید، GitLab CI سادهتر است. Jenkins انعطاف و پلاگینهای بیشتری دارد و برای pipelineهای پیچیده یا ابزارهای متنوع مناسب است، اما نگهداری پلاگینها و بهروزرسانی آن کار بیشتری میخواهد.
آیا GitHub Actions از ایران قابل استفاده است؟
استفاده از سرویسهای GitHub برای کاربران ایران تحت محدودیتهای تحریمی است و این محدودیتها ممکن است بدون اطلاع قبلی تغییر کنند. runner خودمیزبان کمک میکند jobها روی سرورهای شما اجرا شوند، اما همچنان به ارتباط با GitHub وابسته است. برای کاهش ریسک، GitLab خودمیزبان گزینه پایدارتری است.
راهاندازی گیت لب داخلی چه نیازهایی دارد؟
راهاندازی GitLab داخلی یک سرور لینوکس با منابع کافی، فضای ذخیرهسازی برای مخازن و artifactها و یک یا چند سرور یا ماشین مجازی برای GitLab Runner لازم دارد. بکاپ منظم و بهروزرسانی امنیتی GitLab هم باید از ابتدا برنامهریزی شود.
آیا CI/CD برای تیمهای کوچک هم لازم است؟
بله؛ حتی برای یک توسعهدهنده، یک pipeline ساده build و deploy خطای انسانی را کم میکند و انتشار را قابل تکرار میکند. طراحی را متناسب با اندازه تیم ساده نگه میداریم تا نگهداری آن خودش سربار نشود.
اگر نسخه جدید مشکل داشت چه میشود؟
چون هر نسخه با تگ مشخص ساخته میشود، بازگشت یعنی deploy دوباره تگ قبلی. پس از انتشار healthcheck اجرا میشود و تغییرات دیتابیس طوری برنامهریزی میشوند که با نسخه قبلی سازگار بمانند. اگر قطعی جدی رخ دهد، پاسخ اضطراری و رفع قطعی سرور (24/7) در دسترس است.
انتشار نسخههای شما را خودکار کنیم؟
بگویید کد کجا نگهداری میشود، اپلیکیشن با چه زبانی نوشته شده و الان چگونه منتشر میشود. در مشاوره اولیه رایگان، ابزار و pipeline پیشنهادی را با شما مرور میکنیم.
