CI/CD کیا ہے؟ Continuous Integration اور Delivery آسان زبان میں

CI/CD سافٹ ویئر جاری کرنے کا ایسا طریقہ ہے جس میں ہر کوڈ تبدیلی خودکار طور پر بنائی، جانچی جاتی ہے اور، اگر پاس ہو، تو ریلیز کے لیے تیار یا جاری کی جاتی ہے۔ CI (continuous integration) کا مطلب ہے تبدیلیاں بار بار ملائی جائیں اور ہر بار خودکار ٹیسٹس سے جانچی جائیں۔ CD (continuous delivery یا deployment) کا مطلب ہے کہ جو تبدیلیاں پاس ہوں وہ کم یا بغیر دستی کام کے آپ کے صارفین تک پہنچائی جائیں۔

مقصد سادہ ہے: غلطی کو کئی ہفتوں بعد کسی گاہک کے پکڑنے کے بجائے، اسی وقت چند منٹ کے اندر پکڑ لینا۔

AI سے بنانے میں CI/CD کیوں اہم ہے

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

CI/CD ٹھیک اسی کا حفاظتی جال ہے۔ ہر تبدیلی پر یہ ماننے کے بجائے کہ وہ ٹھیک ہے، ایک پائپ لائن ہر بار وہی جانچیں چلاتی ہے:

• کیا ایپ اب بھی بغیر غلطی کے بنتی ہے؟
• کیا خودکار ٹیسٹس اب بھی پاس ہوتے ہیں؟
• کیا کوڈ پروجیکٹ کے قواعد پر پورا اترتا ہے (types، فارمیٹنگ، سیکیورٹی چیکس)؟

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

روزمرہ کی ایک مثال

تصور کریں ایک بیکری جو ہر صبح دکانوں کو ڈبل روٹی بیچتی ہے۔

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

جانچ باورچیوں کو بہتر نہیں بناتی۔ وہ ان کی غلطیوں کو سستا کر دیتی ہے۔

CI/CD پائپ لائن کیسے کام کرتی ہے

پائپ لائن مراحل کی وہ فہرست ہے جو ایک CI/CD سروس خودکار طور پر چلاتی ہے جب کچھ ہو، عموماً جب کوئی کوڈ کسی repository جیسے GitHub پر بھیجے۔ ایک عام پائپ لائن یوں لگتی ہے:

ہر مرحلہ کسی صاف مشین پر چلتا ہے، کسی کے لیپ ٹاپ پر نہیں، تو “میرے کمپیوٹر پر تو چل رہا تھا” کوئی عذر نہیں رہتا۔ اگر کوئی مرحلہ ناکام ہو تو پائپ لائن رک جاتی ہے اور تبدیلی کرنے والے کو بتاتی ہے۔

مراحل ایک کنفیگریشن فائل میں لکھے جاتے ہیں جو کوڈ کے ساتھ رہتی ہے۔ مثلاً GitHub Actions میں یہ repository کے فولڈر .github/workflows میں ایک YAML فائل ہوتی ہے۔

Continuous delivery بمقابلہ continuous deployment

“CD” مبہم ہے، اور لوگ اسے دونوں طرح استعمال کرتے ہیں:

Continuous deployment تبھی اچھی طرح کام کرتا ہے جب ٹیسٹس اچھے ہوں۔ اگر آپ کے ٹیسٹ چیک آؤٹ کو کور نہیں کرتے، تو continuous deployment خوشی سے ایک خراب چیک آؤٹ جاری کر دے گا۔

ایک عملی مثال: پائپ لائن کے ساتھ بکنگ ایپ

فرض کریں آپ کے پاس ایک سیلون بکنگ ایپ ہے، اور اس کا کوڈ GitHub repository میں ہے۔ آپ AI بلڈر سے کہتے ہیں: “پہلی بار آنے والے گاہکوں کے لیے 10% ڈسکاؤنٹ شامل کرو۔”

1. تبدیلی ایک نئی branch پر بھیجی جاتی ہے اور ایک pull request کھلتی ہے۔
2. پائپ لائن شروع ہوتی ہے۔ یہ پیکجز انسٹال کرتی ہے اور ایپ بناتی ہے، یہ پاس ہو جاتا ہے۔
3. یہ ٹیسٹس چلاتی ہے۔ ایک ٹیسٹ، “واپس آنے والا گاہک پورا کرایہ ادا کرتا ہے”، ناکام ہو جاتا ہے: ڈسکاؤنٹ ہر کسی پر لگ رہا ہے۔
4. Pull request پر سرخ نشان آتا ہے۔ تبدیلی merge نہیں ہو سکتی۔
5. آپ AI سے اسے ٹھیک کرنے کو کہتے ہیں۔ وہ ایک درستی بھیجتا ہے؛ پائپ لائن دوبارہ چلتی ہے اور سب پاس ہو جاتا ہے۔
6. تبدیلی merge ہو جاتی ہے۔ پائپ لائن اسے staging environment پر deploy کرتی ہے، جہاں آپ ایک ٹیسٹ بکنگ کرتے ہیں۔
7. آپ منظوری دیتے ہیں، اور وہ پروڈکشن پر deploy ہو جاتا ہے۔

پائپ لائن کے بغیر، مرحلہ 3 آپ کے گاہکوں کی جیبوں میں ہو جاتا۔

اہم اصطلاحات

عام غلط فہمیاں

• “CI/CD کا مطلب ہے میری ایپ جانچی ہوئی ہے۔” پائپ لائن صرف وہی ٹیسٹ چلاتی ہے جو آپ کے پاس ہیں۔ اگر کوئی ٹیسٹ نہیں تو CI صرف یہ ثابت کرتا ہے کہ ایپ بنتی ہے، اس سے زیادہ کچھ نہیں۔ اپنے AI سے ان فلوز کے لیے ٹیسٹ لکھوائیں جو سب سے زیادہ اہم ہیں۔
• “CI/CD صرف بڑی کمپنیوں کے لیے ہے۔” GitHub Actions جیسے ہوسٹڈ ٹولز کو سیٹ اپ کرنے کے لیے ایک مختصر کنفیگریشن فائل چاہیے، اور چھوٹی ٹیمیں انہیں ہر وقت استعمال کرتی ہیں۔ محنت ٹولز کی نہیں، ٹیسٹوں کی ہوتی ہے۔
• “خودکار deployment کا مطلب ہے کوئی کچھ چیک نہیں کرتا۔” اچھی پائپ لائنیں چیک بڑھاتی ہیں، کم نہیں کرتیں۔ بہت سی ٹیمیں پروڈکشن سے پہلے ایک انسانی منظوری کا مرحلہ رکھتی ہیں۔
• “اگر پائپ لائن سبز ہے تو ایپ کام کر رہی ہے۔” اس کا مطلب ہے خودکار چیکس پاس ہوئے۔ پھر بھی آپ کو تبدیلی خود آزمانی چاہیے، ترجیحاً پریویو یا staging پر۔
• “CI/CD backups کی جگہ لیتا ہے۔” ایسا نہیں۔ ایک خراب ڈیٹابیس مائیگریشن جو ٹیسٹ پاس کر لے، پھر بھی اصل ڈیٹا کو نقصان پہنچا سکتی ہے۔ Backups اور rollback کا طریقہ رکھیں۔

اپنے AI بلڈر سے کیا پوچھیں

• “سائن اَپ، لاگ اِن اور چیک آؤٹ کے لیے خودکار ٹیسٹ لکھو، اور دکھاؤ کہ انہیں کیسے چلایا جائے۔”
• “ایک GitHub Actions workflow سیٹ کرو جو ہر pull request پر dependencies انسٹال کرے، ایپ بنائے اور ٹیسٹ چلائے۔”
• “پائپ لائن میں type check اور linter شامل کرو، اور غلطیوں پر اسے ناکام کرو۔”
• “سادہ زبان میں بتاؤ کہ پائپ لائن کا ہر مرحلہ کیا کرتا ہے۔”
• “اگر deploy آدھے راستے پر ناکام ہو جائے تو کیا ہوگا؟ میں واپس کیسے جاؤں؟”
• “یقینی بناؤ کہ repository میں یا پائپ لائن لاگز میں کوئی secret ہارڈ کوڈ شدہ یا چھپا ہوا نہیں۔”

اگر آپ کی ایپ API keys استعمال کرتی ہے تو پائپ لائن کو بھی انہیں چاہیے، جو CI ٹول میں خفیہ شدہ secrets کے طور پر رکھی جائیں، کبھی کنفیگریشن فائل میں نہیں۔ دیکھیں environment variables اور secrets۔

CI/CD اور Mythex

Mythex آپ کے لیے CI پائپ لائن نہیں چلاتا، مگر وہ اپنے طریقے سے کچھ اسی ضرورت کو پورا کرتا ہے:

• Checkpoints۔ ایجنٹ کی ہر کامیاب باری کے بعد Mythex ایک git checkpoint محفوظ کرتا ہے، اور Revert to this point اگر کوئی تبدیلی غلط ہو جائے تو پروجیکٹ کو واپس لے جاتا ہے۔ دیکھیں Chat۔
• App Testing۔ /test لکھیں تو ایجنٹ آپ کے لائیو پریویو پر صارف کی طرح کلک کرتا ہے اور ٹوٹے فلوز کی رپورٹ دیتا ہے، ہر publish سے پہلے مفید۔ دیکھیں App Testing۔
• Publishing ایک سوچا سمجھا قدم ہے۔ تبدیلیاں پہلے نجی پریویو میں ظاہر ہوتی ہیں؛ آپ کی عوامی ایپ صرف اس وقت اپ ڈیٹ ہوتی ہے جب آپ دوبارہ publish کریں۔ یہ continuous deployment سے زیادہ continuous delivery کے قریب ہے۔
• GitHub sync (Pro)۔ پروجیکٹ کو GitHub repository سے sync کریں تو آپ ہر push پر ٹیسٹ چلانے کے لیے اپنے GitHub Actions workflows شامل کر سکتے ہیں۔ دیکھیں GitHub اور export۔

لائیو جانے سے پہلے ہاتھ سے کیا جانچنا ہے، اس کی چیک لسٹ کے لیے لانچ سے پہلے اپنی ایپ کیسے جانچیں، اور ورژن کنٹرول کے ساتھ کام کرنے کے لیے AI سے بنی ایپ میں Git کیسے استعمال کریں دیکھیں۔

سوالات