بلڄ کو توڑنا: یہ کیا ہے، اسباب اور منصوبے میں اس سے کیسے بچیں

ترقی میں بلڄ کو توڑنا کیا ہے

بلڄ کو توڑنا ایک ایسی صورت حال ہے جہاں تبدیۄ لانے کے بعد منصوبہ تعمیر کرنا بند کر دیتا ہے۔ CI/CD کے سیاق میں، اس کا مطلب ہے که بلڄ پائپ لائن ناکام ہوتی ہے اور کئی آرٹی فیکٹ تخلیق نہیں ہوتا۔

موبائل اور ویب ڈیولپمنٹ کی دنیا میں، بلڄ مصدر کوڄ کو قابل ارجائی فائل یا پیکیج میں ترجمہ کرنے کا عمل ہے۔ Android کے لئے، یہ Gradle کے ذریعے APK یا AAB تیار کرنا ہے؛ iOS کے لئے، Xcode کے ذریعے ترتیب دینا؛ ویب منصوبوں کے لئے، Webpack یا Vite کے ذریعے بنڄلنگ کرنا۔ آپ ان میں سے کسی بھی مرحلے پر بلڄ کو توڑ سکتے ہیں۔

جدید ورشن کنٹرول سیسٹم اور Jenkins، GitHub Actions اور GitLab CI جیسے CI/CD آلات خودبخود ٹوٹے بلڄ کا پتا لگاتے ہیں اور ٹیم کو مطلع کرتے ہیں۔ زیادہ تر منصوبوں میں ایک قاعدہ ہے: اگر بلڄ ٹوٹا ہوا ہے، تو بلڄ کے ٹھیک ہونے تک دیگر تمام کاموں کی ترجیح کم کر دی جاتی ہے۔

fun main() {
    val message: String = "Build successful"
    println(message)
    
    // یہ سطر بلڄ کو توڑتا ہے
    val number: Int = "not a number"
}

اس مثال میں، Int قسم کے متغیر میں سٹرنگ منسوب کرنا ترتیب کی غلطی کا سبب بنتا ہے۔ قسم کی بے ملانساتی ستاٹک ٹائپ زبانوں میں بلڄ ٹوٹنے کی سب سے عام وجوۄات میں سے ایک ہے۔

بلڄ کی ناکامی کے اہم وجوۄات

کئی قسموں کی غلطیاں ہیں جو ٹوٹے بلڄ کا سبب بنتی ہیں۔ 2024 کے GitLab تجزیے کے مطابق، وجوۄات کی تقسیم اس پر ہے۔

سب سے مکار زمرہ انحصارات کے مسائل ہے۔ ایک ماڈیول میں لائبری کو اپڈیٹ کرنا پڑوسی ماڈیول میں بلڄ توڑ سکتا ہے اگر API یا طریقوں کا رویہ تبدیل ہو جائے۔

دوسری جانب، نحوی غلطیاں جلدی پکڑی جاتی ہیں — مرتب عین سطر اور غلطی کی قسم کی اشارہ کرتا ہے۔ یہی وجہ ہے کہ ستاٹک ٹائپ زبانوں کو بلڄ اسٹیبلٹی کے لحاظ سے ڈائنامک ٹائپ زبانوں کے مقابلے زیادہ قابل اعتماد سمجھا جاتا ہے۔

ٹوٹا ہوا بلڄ ٹیم کو کیسے متاثر کرتا ہے

ٹوٹا ہوا بلڄ براہ راست ٹیم کی پاداوری کو متاثر کرتا ہے۔ جب بلڄ ناکام ہوتا ہے، ڈیولپرز ریپوزٹری سے منصوبے کا ترتیب ویرشن حاصل نہیں کر سکتے، اور CI پائپ لائن بعد کی تمام تبدیلیوں کے لئے بلوک ہو جاتی ہے۔

Atlassian کا 2023 کا ایک مطالعہ ظاہر کرتا ہے که وہ منصوبے جن میں بلڄ چار گھنٹے سے زیادہ ٹوٹا رہتا ہے، وہ ٹیم کے پاداورانہ وقت کا اوسط 25% کھو دیتے ہیں۔ ڈیولپرز اپنے کام مکمل کرنے کے بجائے مسئلے کی تشخیص میں اپنی توجہ لگانے پر مجبور ہیں۔

پاداوری کے علاوہ، ٹیم کا معنوی ماحول بھی متاثر ہوتا ہے۔ وہ ڈیولپر جیسنے بلڄ توڑا ہے، ساتھیوں سے دباؤ محسوس کرتا ہے۔ تک دیم ٹیم میں قاعدہ ہے: ٹوٹے بلڄ کی سزا نہیں، بلکہ فوری تصدیق کا مطالبہ کروں۔ بلام لیس کلچر ایک نظریہ ہے جس میں واقعے کا تجزیہ کسی کی غلطی کے بجائے ایک نظامی مسئلے کے طور پر کیا جاتا ہے۔

منتشر ٹیم میں، ٹوٹا ہوا بلڄ دوسرے طول البلد میں ساتھیوں کے کام کو روک سکتا ہے۔ اگر یورپ کا ایک ڈیولپر جانے سے پہلے بلڄ توڑ دیتا ہے، تو ایشیا کی ٹیم تصدیق کے انتظار میں پورا کام کا دن کھو سکتی ہے۔

ٹوٹے بلڄ کو کیسے روکا جائے

ٹوٹے بلڄ کی حفاظت کمٹ سے پہلے مقامی جانچ سے شروع ہوتی ہے۔ ہر ڈیولپر کو تبدیۄ دھکنے سے پہلے ٹیسٹ اور بلڄ چلانا چاہئے۔ حفاظتی اقدامات کا بنیادی طریقے کئی سطحوں میں تقسیم کیے گئے ہیں۔

• پری کمٹ ہوکز — لنٹرز اور فارمیٹرز سمیت کمٹ تخلیق سے پہلے خودکار جانچ
• مقامی بلڄ — خاصطور ستاٹک ٹائپ زبانوں کے لئے، دھکے سے پہلے ترتیب چلانا
• اکائی ٹیسٹ — ابتدائی ریگریشن کا پتا لگانے کے لئے اہم ماڈیولز کو ٹیسٹوں سے چک کرنا
• کوڄ کا جائزہ — مین شاخ میں ضم کرنے سے پہلے کسی ساتھی کا تبدیۄ کا جائزہ

دوسرا سطح CI/CD پائپ لائن ترتیب ہے۔ ہر پل ریکویسٹ کو ضم سے پہلے خودکار بلڄ اور ٹیسٹ پاس کرنے ہوں گے۔ اگر بلڄ ناکام ہوتا ہے، تو PR تصدیق تک بلوک رہتا ہے۔ اس نظریے کو گیٹیڄ کمٹ کہا جاتا ہے اور زیادہ تر جدید منصوبوں میں استعمال ہوتا ہے۔

تیسرا سطح نگرانی اور شمارات ہے۔ ٹیمیں MTTR (اوسط مرمت کا وقت) کے میٹرک کو ٹریک کرتی ہیں۔ یہ اشارہ جتنا کم ہوگا، ٹیم ٹوٹے بلڄ پر اتنی تیزی سے رد عمل کرے گی، ہدف کی قیمت 30 منٹ سے زیادہ نہیں ہے۔

اگر بلڄ ٹوٹ گیا ہے تو کیا کریں

جب بلڄ ٹوٹ جاتا ہے، پہلا قدم یہ پتا کرنا ہے که کس ڈیولپر نے آخری تبدیۄ کی تھیں۔ Git آلا کرتا ہے git bisect جو دوئی تلاش کے ذریعے بلڄ توڑنے والے کمٹ کو تلاش کر سکتا ہے۔

# معلوم اچھے اور بُرے کمٹس کے ساتھ bisect شروع کریں
git bisect start
git bisect bad HEAD
git bisect good abc1234

# Git درمیان میں ایک کمٹ چیک کرتا ہے
# تعمیر کریں اور ٹیسٹ کریں، پھر نشان لگائیں:
git bisect good  # if build passes
git bisect bad   # if build fails

# ~log2(n) مراحل کے بعد، Git مجرم کو دیکھاتا ہے
git bisect reset

مسئلہ کے کمٹ کو تلاش لینے کے بعد، کاروائی کے دو ممکن طریقے ہیں۔ پہلا ہے git revert استعمال کرتے ہوئے تبدیۄ کو واپس کرنا اگر تصدیق میں وقت لگتا ہے۔ یہ سب سے محفوظ نظریہ ہے، خاصطور جب بلڄ پوری ٹیم کو بلوک کرتا ہے۔

دوسرا اختیار ایک نئے کمٹ کے ساتھ فوری تصدیق ہے۔ یہ نظریہ اس وقت بہتر ہے جب مسئلہ مقامی اور واضح ہو۔ تصدیق کے بعد، تبدیۄ دھکیں اور تصدیق کریں که بلڄ کامیاب ہی۔ کسی بھی صورت میں، بلڄ بحالی کا وقت ایک گھنٹے سے زیادہ نہیں ہونا چاہئے۔