CI/CD میں Production — یہ کیا ہے، ڈویلپمنٹ میں مراحل اور ماحول

CI/CD میں Production کیا ہے؟

CI/CD کے سیاق و سباق میں پروڈکشن ایپلیکیشن لائف سائیکل کا آخری مرحلہ ہے، جہاں بلڈ اور ٹیسٹنگ کے تمام مراحل کو کامیابی سے گزارنے کے بعد کوڈ آخر صارفین کے لیے دستیاب ہوتا ہے۔ ڈویلپمنٹ اور سٹیجنگ ماحول کے برعکس، پروڈکشن ماحول حقیقی ڈیٹا اور بوجھ کے ساتھ کام کرتا ہے، جو قابل اعتمادی اور کارکردگی پر خصوصی تقاضے عائد کرتا ہے۔

پروڈکشن ماحول کا کردار

پروڈکشن ماحول صرف ایک سرور نہیں ہے، بلکہ ایک مکمل انفراسٹرکچر ہے جس میں لوڈ بیلنسر، ڈیٹا بیس، کیشنگ پرتیں، CDN اور نگرانی کے نظام شامل ہیں۔ ہر جزو خرابی برداشت اور قابل توسیع ہونا چاہیے۔ موبائل ڈویلپمنٹ میں، پروڈکشن میں بیک اینڈ سروسز، API گیٹ ویز اور پش انفراسٹرکچر بھی شامل ہے جو کلائنٹ ایپلیکیشن کو سپورٹ کرتے ہیں۔

پروڈکشن ماحول کے تقاضے

پروڈکشن ماحول کو سخت معیارات پورے کرنے چاہئیں: 99.9% اور اس سے زیادہ دستیابی، API ردعمل کا وقت 200 ms سے زیادہ نہ ہو، ڈیزاسٹر ریکوری سپورٹ (SLA کے اندر RTO اور RPO)۔ موبائل ایپلیکیشنز کے لیے، کریش رپورٹنگ، استعمال کے تجزیات اور تجربات کے لیے A/B پلیٹ فارمز اضافی طور پر ضروری ہیں۔ CI/CD پائپ لائن ہر ڈیپلائمنٹ سے پہلے خودکار جانچ کے ذریعے ان تقاضوں کی تعمیل کو یقینی بناتی ہے۔

پروڈکشن میں ڈیپلائمنٹ کے مراحل

پروڈکشن میں ڈیپلائمنٹ ایک کثیر المراحل عمل ہے جو CI/CD پائپ لائن کے ذریعے خودکار ہوتا ہے۔ ہر مرحلے میں جانچیں شامل ہوتی ہیں جو خراب کوڈ کو پروڈکشن تک پہنچنے سے روکتی ہیں۔ آئیے ایک عام موبائل ایپلیکیشن پائپ لائن کی مثال استعمال کرتے ہوئے اہم مراحل کا جائزہ لیں۔

پروڈکشن کے لیے CI/CD پائپ لائن

پائپ لائن ریپوزٹری کی مرکزی شاخ میں کمٹ سے شروع ہوتی ہے۔ پش کے بعد، خودکار بلڈ اور یونٹ ٹیسٹ شروع کیے جاتے ہیں، اس کے بعد انٹیگریشن ٹیسٹ اور کوڈ کوالٹی چیکس ہوتے ہیں۔ تمام مراحل کی کامیاب تکمیل پر، آرٹیفیکٹ بلڈ رجسٹری میں شائع ہوتا ہے اور حتمی تصدیق کے لیے سٹیجنگ پر ڈیپلائے ہوتا ہے۔ سٹیجنگ پر تصدیق کے بعد ہی پائپ لائن پروڈکشن ڈیپلائمنٹ کی طرف بڑھتی ہے۔

@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"
            }
        }
    }
}

ڈیپلائمنٹ آٹومیشن

پروڈکشن میں خودکار ڈیپلائمنٹ زیرو ڈاؤن ٹائم ڈیپلائمنٹ حکمت عملی استعمال کرتی ہے: رولنگ اپ ڈیٹ، بلیو گرین ڈیپلائمنٹ یا کینری ریلیز۔ رولنگ اپ ڈیٹ میں، ایپلیکیشن کی نئی مثالیں سروس کو روکے پرانے کو آہستہ آہستہ تبدیل کرتی ہیں۔ بلیو گرین ڈیپلائمنٹ دو ایک جیسے ماحول برقرار رکھتا ہے اور ٹریفک کو فوری طور پر منتقل کرتا ہے، جس سے مسائل کی صورت میں فوری رول بیک ممکن ہوتا ہے۔ حکمت عملی کا انتخاب سروس کی اہمیت اور قابل قبول ڈاؤن ٹائم پر منحصر ہے۔ موبائل ایپلیکیشنز کے لیے، پروڈکشن میں ڈیپلائمنٹ میں مرحلہ وار رول آؤٹ کے ساتھ ایپ اسٹورز (App Store Connect، Google Play Console) میں اشاعت شامل ہے، جس کے لیے بائنری فائلیں اپ لوڈ کرنے، میٹا ڈیٹا بھرنے اور جائزے کے لیے جمع کرانے سمیت اشاعت کے عمل کو خودکار بنانے کے لیے اسٹور APIs کے ساتھ اضافی CI/CD انضمام کی ضرورت ہوتی ہے۔

ڈیپلائمنٹ کے بعد کی جانچ

پروڈکشن میں کامیاب ڈیپلائمنٹ کے بعد، CI/CD پائپ لائن اسموک ٹیسٹ کا ایک سیٹ شروع کرتی ہے جو بنیادی سروس فعالیت کی تصدیق کرتی ہے: اینڈ پوائنٹ کی دستیابی، API کے جوابات کی درستگی، معمول کی حدود میں ردعمل کا وقت۔ موبائل ایپلیکیشنز کے لیے، اجازت نامے کی صلاحیت، ڈیٹا سنکرونائزیشن اور ادائیگی کے انضمام کے درست کام کی اضافی جانچ کی جاتی ہے۔ اگر اسموک ٹیسٹ ناکام ہوتے ہیں تو پائپ لائن خود بخود پچھلے مستحکم ورژن پر رول بیک شروع کرتی ہے اور ٹیم کو اطلاع بھیجتی ہے۔ ڈیپلائمنٹ کے بعد کی نگرانی بڑھی ہوئی الرٹ سطح کے ساتھ 30-60 منٹ تک جاری رہتی ہے — یہ خودکار ٹیسٹوں کے ذریعے احاطہ نہ ہونے والے مسائل کا پتہ لگانے کی کھڑکی ہے۔

پروڈکشن اور ٹیسٹ ماحول کے درمیان فرق

پروڈکشن اور کم سخت ماحول کے درمیان بنیادی فرق حقیقی صارف ڈیٹا اور بوجھ کے ساتھ کام کرنا ہے۔ سٹیجنگ ماحول ریلیز سے پہلے حتمی جانچ کے لیے ڈیزائن کیا گیا ہے لیکن مصنوعی یا گمنام ڈیٹا استعمال کرتا ہے۔ دوسری طرف، پروڈکشن لائیو لین دین، ذاتی ڈیٹا اور انتہائی اہم آپریشنز پر کارروائی کرتا ہے، جس کے لیے انتظام میں بنیادی طور پر مختلف نقطہ نظر کی ضرورت ہوتی ہے۔

ترتیب اور انفراسٹرکچر

پروڈکشن ماحول کی ترتیب دوسرے ماحول سے سختی سے الگ تھلگ ہونی چاہیے۔ اس کا اطلاق ماحولیاتی متغیرات، ڈیٹا بیس کنکشن سٹرنگز، API چابیاں اور سرٹیفکیٹس پر ہوتا ہے۔ پروڈکشن انفراسٹرکچر عام طور پر خرابی برداشت کو یقینی بنانے کے لیے متعدد دستیابی زونز میں نقل کیا جاتا ہے۔ موبائل ایپلیکیشنز کے لیے، پروڈکشن میں Apple App Store اور Google Play کنفیگریشنز بھی شامل ہیں جو ٹیسٹ بلڈز میں موجود نہیں ہیں۔

ڈیٹا مینجمنٹ

پروڈکشن میں، جانچ کے لیے حقیقی ڈیٹا استعمال کرنا سختی سے ممنوع ہے — اس مقصد کے لیے سٹیجنگ اور ڈویلپمنٹ ماحول موجود ہیں۔ ڈیٹا بیس کے ڈھانچے میں تمام تبدیلیاں مائیگریشن کے ذریعے ہونی چاہئیں جو CI/CD پائپ لائن خود بخود لاگو کرتی ہے۔ پروڈکشن ڈیٹا کا بیک اپ خودکار سالمیت کی تصدیق کے ساتھ ایک شیڈول پر کیا جاتا ہے۔ برقرار رکھنے کی پالیسی GDPR ضروریات اور دیگر ضوابط کے مطابق بیک اپ کی ذخیرہ کرنے کی مدت کا تعین کرتی ہے۔

پروڈکشن انفراسٹرکچر کی نگرانی

پروڈکشن نگرانی میٹرکس، لاگز اور ٹریسز کو جمع کرنے اور تجزیہ کرنے کا ایک مسلسل عمل ہے۔ جامع نگرانی کے بغیر، SLA کی ضمانت دینا اور بروقت واقعات کا پتہ لگانا ناممکن ہے۔ نگرانی کا جدید نقطہ نظر تین ستونوں پر مبنی ہے: میٹرکس (عددی اشارے)، لاگز (ساختی واقعہ ریکارڈ) اور ٹریسز (درخواستوں کا سراغ لگانا)۔

اہم میٹرکس

پروڈکشن ماحول کے اہم میٹرکس میں شامل ہیں: اپ ٹائم (سروس کی دستیابی)، تاخیر (ردعمل میں تاخیر)، غلطی کی شرح (غلطیوں کا فیصد)، تھرو پٹ (بینڈوتھ) اور سنترپتی (وسائل کے بوجھ کی سطح)۔ موبائل ایپلیکیشنز کے لیے، شروع ہونے کے وقت کے میٹرکس، کریش سے پاک شرح اور ڈیٹا سنکرونائزیشن کا وقت اہم ہیں۔ الرٹس SLO (سروس لیول آبجیکٹیوز) کی بنیاد پر ترتیب دیے جاتے ہیں تاکہ SLA کی خلاف ورزی سے پہلے ٹیم کو اطلاع مل جائے۔

نگرانی کے اوزار

پروڈکشن انفراسٹرکچر کی نگرانی کے لیے خصوصی پلیٹ فارم استعمال کیے جاتے ہیں: میٹرکس جمع کرنے کے لیے Datadog, New Relic, Grafana + Prometheus، موبائل ایپلیکیشنز میں خرابیوں کو ٹریک کرنے کے لیے Sentry اور Crashlytics۔ لاگز ELK اسٹیک (Elasticsearch, Logstash, Kibana) یا Splunk کے ذریعے مرکزی بنائے جاتے ہیں۔ درخواستوں کا سراغ Jaeger یا Zipkin کا استعمال کرتے ہوئے لاگو کیا جاتا ہے۔ تمام اوزار ایک نئی سروس ڈیپلائے کرتے وقت خودکار ڈیش بورڈ تخلیق کے لیے CI/CD پائپ لائن کے ساتھ مربوط ہیں۔ واقعہ رسپانس سسٹم (PagerDuty, Opsgenie) تمام نگرانی کے اوزاروں سے الرٹس وصول کرتا ہے اور گردش اور ایسکلیشن قوانین کی بنیاد پر خود بخود آن کال ذمہ دار شخص مقرر کرتا ہے۔ ہر قسم کے واقعے کے لیے ایک رن بک ریپوزٹری میں محفوظ اور کوڈ کے ساتھ ورژن کی جاتی ہے، جو بحالی کی ہدایات کی مطابقت کو یقینی بناتی ہے۔

پروڈکشن ماحول کی حفاظت

پروڈکشن ماحول کی حفاظت ایک کثیر سطحی تحفظ کا نظام ہے جو انفراسٹرکچر، ڈیٹا، رسائی اور ڈیپلائمنٹ کے عمل کا احاطہ کرتا ہے۔ ہر سطح کو اس طرح ترتیب دیا جانا چاہیے کہ ایک سے سمجھوتہ پورے نظام سے سمجھوتہ کا باعث نہ بنے۔ CI/CD پائپ لائن ہر پائپ لائن مرحلے پر خودکار جانچ، کمزوری اسکیننگ اور تعمیل کنٹرول کے ذریعے حفاظت کو یقینی بنانے میں کلیدی کردار ادا کرتی ہے۔

رسائی اور کردار

پروڈکشن ماحول تک رسائی کم سے کم استحقاق کے اصول سے سختی سے محدود ہے۔ ڈویلپرز کو پروڈکشن سرورز تک براہ راست رسائی نہیں ہے — تمام تبدیلیاں منظوری کے طریقہ کار کے ساتھ CI/CD پائپ لائن کے ذریعے ہوتی ہیں۔ ہنگامی رسائی کے لیے، خودکار گردش اور مکمل کارروائی لاگنگ کے ساتھ عارضی اسناد استعمال کی جاتی ہیں۔ چار آنکھوں کا اصول (کسی بھی آپریشن کے لیے دو افراد کی منظوری درکار ہے) پروڈکشن آپریشنز کے لیے معیار ہے۔

تبدیلی کا آڈٹ

پروڈکشن میں ہر تبدیلی آڈٹ سسٹم میں ریکارڈ کی جاتی ہے: ڈیپلائمنٹ کس نے شروع کیا، کون سا کمٹ ڈیپلائے کیا گیا، کون سی جانچیں پاس ہوئیں، ڈیپلائمنٹ میں کتنا وقت لگا۔ CI/CD کا واقعہ مینجمنٹ سسٹمز (PagerDuty, Opsgenie) کے ساتھ انضمام ڈیپلائمنٹ ناکام ہونے یا SLO کی خلاف ورزی پر خودکار ٹکٹ تخلیق کی اجازت دیتا ہے۔ تمام پروڈکشن لاگز SOC2 اور ISO 27001 کی ضروریات کے مطابق کم از کم 90 دنوں کی برقراری کے ساتھ ایک ناقابل تغیر ذخیرے میں محفوظ کیے جاتے ہیں۔