Production در CI/CD — چیست، مراحل و محیط در توسعه

Production در CI/CD چیست

Production در زمینه CI/CD — مرحله نهایی چرخه حیات اپلیکیشن است، جایی که کد پس از گذراندن تمام مراحل ساخت و تست برای کاربران نهایی در دسترس قرار می‌گیرد. برخلاف محیط‌های توسعه و staging، محیط production با داده‌ها و بارهای واقعی کار می‌کند که الزامات ویژه‌ای برای قابلیت اطمینان و عملکرد ایجاد می‌کند.

نقش محیط production

محیط production فقط یک سرور نیست، بلکه یک زیرساخت کامل شامل load balancerها، پایگاه‌های داده، لایه‌های کش، CDN و سیستم‌های نظارت است. هر مؤلفه باید مقاوم در برابر خطا و مقیاس‌پذیر باشد. در توسعه موبایل، production همچنین شامل سرویس‌های بک‌اند، دروازه‌های API و زیرساخت پوش است که عملکرد اپلیکیشن کلاینت را تضمین می‌کند.

الزامات محیط production

محیط production باید معیارهای سختگیرانه‌ای را برآورده کند: دسترسی ۹۹.۹٪ و بالاتر، زمان پاسخ API بیش از ۲۰۰ میلی‌ثانیه نباشد، پشتیبانی از بازیابی اضطراری (RTO و RPO در محدوده SLA). برای اپلیکیشن‌های موبایل، نظارت بر crash (گزارش خطا)، تحلیل استفاده و پلتفرم‌های A/B برای آزمایش‌ها نیز الزامی است. CI/CD pipeline با بررسی‌های خودکار قبل از هر استقرار، انطباق با این الزامات را تضمین می‌کند.

مراحل استقرار در production

استقرار در production — فرآیندی چندمرحله‌ای است که از طریق CI/CD pipeline خودکار شده است. هر مرحله شامل بررسی‌هایی است که از ورود کد معیوب به تولید جلوگیری می‌کند. مراحل کلیدی را با مثال یک pipeline معمولی برای اپلیکیشن موبایل بررسی می‌کنیم.

CI/CD pipeline برای production

Pipeline با commit به شاخه اصلی مخزن آغاز می‌شود. پس از push، ساخت خودکار و تست‌های واحد، سپس تست‌های یکپارچه‌سازی و بررسی کیفیت کد اجرا می‌شوند. پس از عبور موفق از تمام مراحل، artefact در ثبت buildها منتشر شده و برای بررسی نهایی در staging مستقر می‌شود. تنها پس از تأیید در staging، pipeline به استقرار در production می‌رود.

@Library("shared-lib") _

pipeline {
    agent any

    stages {
        stage("Build") {
            steps {
                sh "cd app && ./gradlew assembleRelease"
            }
        }
        stage("Test") {
            steps {
                sh "cd app && ./gradlew testRelease"
            }
        }
        stage("Deploy to Staging") {
            steps {
                sh "deploy-staging.sh"
            }
        }
        stage("Deploy to Production") {
            input "Deploy to production?"
            steps {
                sh "deploy-production.sh"
            }
        }
    }
}

خودکارسازی استقرار

استقرار خودکار در production از استراتژی‌های zero-downtime deployment استفاده می‌کند: rolling update، blue-green deployment یا canary release. در rolling update، نمونه‌های جدید اپلیکیشن به تدریج جایگزین نمونه‌های قدیمی بدون توقف سرویس می‌شوند. Blue-green deployment دو محیط یکسان را حفظ کرده و ترافیک را فوراً جابجا می‌کند که امکان بازگشت سریع در صورت بروز مشکل را فراهم می‌کند. انتخاب استراتژی به بحرانی بودن سرویس و زمان توقف مجاز بستگی دارد. برای اپلیکیشن‌های موبایل، استقرار در production شامل انتشار در فروشگاه‌های اپلیکیشن (App Store Connect، Google Play Console) با rollout تدریجی است که نیاز به یکپارچه‌سازی اضافی CI/CD با API فروشگاه‌ها برای خودکارسازی فرآیند انتشار، از جمله آپلود فایل‌های باینری، پر کردن metadata و ارسال برای بررسی دارد.

بررسی‌های پس از استقرار

پس از استقرار موفق در production، CI/CD pipeline مجموعه‌ای از smoke-testها را اجرا می‌کند که عملکرد پایه سرویس را بررسی می‌کنند: دسترسی endpointها، صحت پاسخ‌های API، زمان پاسخ در محدوده نرمال. برای اپلیکیشن‌های موبایل، additionally امکان احراز هویت، همگام‌سازی داده‌ها و عملکرد صحیح یکپارچه‌سازی‌های پرداخت بررسی می‌شود. اگر smoke-testها عبور نکنند، pipeline به طور خودکار rollback به نسخه پایدار قبلی را آغاز کرده و به تیم اخطار می‌دهد. نظارت پس از استقرار به مدت ۳۰-۶۰ دقیقه با سطح alert بالاتر ادامه می‌یابد — این پنجره‌ای برای کشف مشکلاتی است که توسط تست‌های خودکار پوشش داده نشده‌اند.

تفاوت production با محیط‌های تست

تفاوت کلیدی بین production و محیط‌های کمتر سختگیرانه — کار با داده‌ها و بارهای واقعی کاربران است. محیط staging برای بررسی نهایی قبل از انتشار در نظر گرفته شده، اما از داده‌های مصنوعی یا ناشناس‌سازی شده استفاده می‌کند. Production اما تراکنش‌های زنده، داده‌های شخصی و عملیات بحرانی را پردازش می‌کند که نیازمند رویکرد اساساً متفاوتی به مدیریت است.

پیکربندی و زیرساخت

پیکربندی محیط production باید به شدت از سایر محیط‌ها ایزوله باشد. این شامل متغیرهای محیطی، رشته‌های اتصال به پایگاه داده، کلیدهای API و گواهی‌ها می‌شود. زیرساخت production معمولاً در چندین منطقه دسترسی (availability zones) برای تضمین تحمل‌پذیری در برابر خطا تکرار می‌شود. برای اپلیکیشن‌های موبایل، production همچنین شامل پیکربندی‌های Apple App Store و Google Play است که در buildهای تستی وجود ندارند.

مدیریت داده‌ها

در production استفاده از داده‌های واقعی برای تست اکیداً ممنوع است — برای این منظور محیط‌های staging و development وجود دارند. تمام تغییرات ساختار پایگاه داده باید از طریق مهاجرت‌هایی انجام شود که به طور خودکار توسط CI/CD pipeline اعمال می‌شوند. پشتیبان‌گیری از داده‌های production بر اساس برنامه با بررسی خودکار یکپارچگی backupها انجام می‌شود. Retention policy مدت نگهداری نسخه‌های پشتیبان را مطابق با الزامات GDPR و سایر نهادهای نظارتی تعیین می‌کند.

نظارت بر زیرساخت production

نظارت بر production — فرآیند مستمر جمع‌آوری و تحلیل metricها، logها و traceها است. بدون نظارت کامل نمی‌توان SLA را تضمین کرد و حوادث را به موقع کشف کرد. رویکرد مدرن به نظارت بر سه ستون استوار است: metricها (شاخص‌های عددی)، logها (ثبت‌های ساختاریافته رویدادها) و traceها (ردیابی درخواست‌ها).

metricهای کلیدی

metricهای اصلی محیط production شامل: uptime (دسترسی سرویس)، latency (تأخیر پاسخ)، error rate (درصد خطاها)، throughput (ظرفیت عبوری) و saturation (سطح بار منابع) است. برای اپلیکیشن‌های موبایل، metricهای زمان راه‌اندازی، فراوانی crash (نرخ crash-free) و زمان همگام‌سازی داده‌ها حیاتی هستند. alertها بر اساس SLO (Service Level Objectives) پیکربندی می‌شوند تا تیم قبل از نقض SLA اخطار دریافت کند.

ابزارهای نظارت

برای نظارت بر زیرساخت production از پلتفرم‌های تخصصی استفاده می‌شود: Datadog, New Relic، Grafana + Prometheus برای جمع‌آوری metricها، Sentry و Crashlytics برای ردیابی خطاها در اپلیکیشن‌های موبایل. logها از طریق ELK stack (Elasticsearch, Logstash, Kibana) یا Splunk متمرکز می‌شوند. ردیابی درخواست‌ها با Jaeger یا Zipkin انجام می‌شود. همه ابزارها با CI/CD pipeline برای ایجاد خودکار dashboardها هنگام استقرار سرویس جدید یکپارچه می‌شوند. سیستم incident response (PagerDuty, Opsgenie) alertها را از همه ابزارهای نظارت دریافت کرده و به طور خودکار مسئول شیفت را بر اساس چرخش و قوانین escalation تعیین می‌کند. Runbook برای هر نوع حادثه در مخزن ذخیره شده و همراه با کد نسخه‌بندی می‌شود که به‌روزرسانی دستورالعمل‌های بازیابی را تضمین می‌کند.

امنیت محیط production

امنیت محیط production — یک سیستم حفاظتی چندلایه است که زیرساخت، داده‌ها، دسترسی و فرآیند استقرار را پوشش می‌دهد. هر لایه باید به گونه‌ای پیکربندی شود که به خطر افتادن یکی منجر به به خطر افتادن کل سیستم نشود. CI/CD pipeline نقش کلیدی در تضمین امنیت از طریق بررسی‌های خودکار، اسکن آسیب‌پذیری‌ها و کنترل انطباق در هر مرحله از pipeline ایفا می‌کند.

دسترسی و نقش‌ها

دسترسی به محیط production بر اساس اصل کمترین دسترسی به شدت محدود شده است. توسعه‌دهندگان دسترسی مستقیم به سرورهای production ندارند — همه تغییرات از طریق CI/CD pipeline با مکانیزم تأیید انجام می‌شود. برای دسترسی اضطراری از اعتبارنامه‌های موقت با چرخش خودکار و ثبت کامل اقدامات استفاده می‌شود. اصل چهار چشم (هر عملیات نیاز به تأیید دو نفر دارد) استاندارد عملیات production است.

حسابرسی تغییرات

هر تغییر در production در سیستم حسابرسی ثبت می‌شود: چه کسی استقرار را آغاز کرد، چه commitای مستقر شد، چه بررسی‌هایی انجام شد، استقرار چقدر طول کشید. یکپارچه‌سازی CI/CD با سیستم‌های مدیریت حادثه (PagerDuty, Opsgenie) امکان ایجاد خودکار ticket هنگام شکست استقرار یا نقض SLO را فراهم می‌کند. همه logهای production در ذخیره‌گاه تغییرناپذیر با دوره نگهداری حداقل ۹۰ روز مطابق با الزامات SOC2 و ISO 27001 ذخیره می‌شوند.