رجعت — کیا ہے، کیوں ہوتی ہے اور کیسے ٹیسٹ کریں

ڈویلپمنٹ میں رجعت کیا ہے

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

یہ اصطلاح ٹیسٹنگ سے آئی ہے: رجعت ٹیسٹنگ ہر تبدیلی کے بعد موجودہ ٹیسٹوں کو دوبارہ چلانے کا عمل ہے تاکہ تصدیق کی جا سکے کہ پرانی فعالیت نہیں ٹوٹی۔ اگر پہلے پاس ہونے والا ٹیسٹ ناکام ہو جائے، تو رجعت واقع ہو گئی ہے۔ وسیع تر معنوں میں، رجعت صرف ٹیسٹ کی ناکامی نہیں ہے، بلکہ رویے میں کوئی بھی تنزلی ہے جسے صارف یا QA نوٹس کرتا ہے۔ Tricentis State of Testing 2023 کے مطابق، پروڈکشن میں ملنے والے تمام بگ کا 35–45% رجعت ہوتے ہیں۔

رجعت کو عام بگ سے ممتاز کرنے والی چیز زمانی سیاق و سباق ہے: ایک عام بگ شروع سے موجود ہو سکتا ہے، جبکہ رجعت ہمیشہ کسی تبدیلی کا نتیجہ ہوتی ہے۔ یہ ایک اہم فرق ہے کیونکہ رجعت کی وجہ تلاش کرنا اس تجزیے سے شروع ہوتا ہے کہ «کام کر رہا تھا» اور «کام کرنا بند کر دیا» کے درمیان کیا تبدیل ہوا۔ Git bisect رجعت پیدا کرنے والے کمٹ کو تلاش کرنے کا معیاری آلہ ہے۔

رجعت کی اقسام اور مثالیں

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

دوردرسی رجعت — ماڈیول A میں تبدیلی ماڈیول B میں فعالیت توڑ دیتی ہے، جو کوڈ سے براہ راست منسلک نہیں ہے لیکن ڈیٹا یا وقت سے منسلک ہے۔ مثال: «صارفین» ماڈیول میں ڈیٹا بیس سکیما تبدیل کرنا «تجزیات» ماڈیول میں رپورٹ توڑ دیتا ہے جو ایک ہی ٹیبل استعمال کرتا ہے۔ دوردرسی رجعت سب سے خطرناک ہوتی ہے: ڈویلپر کو شک نہیں ہوتا کہ اس کی تبدیلی کسی دوسرے ماڈیول کو متاثر کرے گی۔

ضمنی اثر کی رجعت — ضمنی اثر (لاگنگ، کیشنگ، نوٹیفکیشن بھیجنا) میں تبدیلی متوقع رویہ توڑ دیتی ہے۔ مثال: ڈویلپر رفتار بڑھانے کے لیے کیشنگ شامل کرتا ہے، لیکن پرانے کیش کی وجہ سے صارفین پرانا ڈیٹا دیکھتے ہیں۔ ضمنی اثر کی رجعت کو خودکار ٹیسٹوں سے پکڑنا مشکل ہے کیونکہ ضمنی اثرات اکثر ٹیسٹوں سے کور نہیں ہوتے۔

کارکردگی کی رجعت — کوڈ فعالی طور پر درست کام کرتا رہتا ہے لیکن پہلے سے سست ہوتا ہے۔ مثال: نیا انکرپشن الگورتھم وہی نتائج دیتا ہے، لیکن عملدرآمد کا وقت 2 ms سے بڑھ کر 200 ms ہو گیا۔ کارکردگی کی رجعت عام یونٹ ٹیسٹوں سے نہیں پکڑی جاتی — بینچ مارک اور پروفائلنگ کی ضرورت ہوتی ہے۔

رجعت کیوں ہوتی ہے

پہلی وجہ کوڈ کپلنگ ہے۔ ماڈیول جتنا زیادہ ایک دوسرے پر انحصار کرتے ہیں، اتنا ہی زیادہ امکان ہے کہ ایک میں تبدیلی دوسرے میں رجعت پیدا کرے گی۔ کلاسک اینٹی پیٹرن: God Object (ایک آبجیکٹ جو سب کچھ کرتا ہے)، Shotgun Surgery (ایک جگہ تبدیلی کے لیے درجنوں جگہوں پر ترمیم کی ضرورت)، سرکلر ڈیپنڈنسی۔ کپلنگ کم کرنا آرکیٹیکچر کا معاملہ ہے: SOLID اصول، ڈیپنڈنسی انجیکشن، ہیکساگونل آرکیٹیکچر۔

دوسری وجہ تبدیل شدہ فعالیت کے لیے ٹیسٹوں کی کمی ہے۔ اگر کوڈ ٹیسٹوں سے کور نہیں ہے، تو ڈویلپر کو رجعت کے بارے میں صرف QA یا صارفین سے پتہ چلتا ہے۔ Google Testing Blog کے مطابق، >75% ٹیسٹ کوریج والے پروجیکٹس میں <25% کوریج والے پروجیکٹس کے مقابلے میں 5 گنا کم رجعت ہوتی ہے۔ TDD (ٹیسٹ ڈریون ڈویلپمنٹ) اس بات کو یقینی بناتا ہے کہ ٹیسٹ کوڈ سے پہلے لکھے جائیں، نہ کہ «جب وقت ملے گا»۔

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

رجعت ٹیسٹنگ اور اس کا کردار

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

دستی رجعت ٹیسٹنگ سب سے مہنگی اور غیر موثر طریقہ ہے۔ جیسے جیسے پروجیکٹ بڑھتا ہے، رجعت ٹیسٹ منظرناموں کی تعداد لکیری طور پر بڑھتی ہے، جبکہ دستی عملدرآمد کا وقت تیزی سے بڑھتا ہے۔ 2–3 سال کی ڈویلپمنٹ کے بعد، دستی رجعت میں 2–3 ہفتے لگ سکتے ہیں، جس سے بار بار ریلیز ناممکن ہو جاتی ہے۔ واحد حل آٹومیشن ہے۔

خودکار رجعت ٹیسٹنگ ٹیسٹ پیرامڈ کے مطابق سطحوں میں تقسیم ہوتی ہے:

• یونٹ ٹیسٹ — تیز، الگ تھلگ، انفرادی فنکشنز اور میتھڈز کو کور کرتے ہیں
• انٹیگریشن ٹیسٹ — ماڈیولز، ڈیٹا بیسز، بیرونی سروسز کے درمیان تعامل کی تصدیق کرتے ہیں
• E2E ٹیسٹ — UI یا API کے ذریعے مکمل صارف منظرناموں کی تصدیق کرتے ہیں
• سنہا شاٹ ٹیسٹ — کسی جزو کے موجودہ آؤٹ پٹ کا حوالہ سے موازنہ کرتے ہیں

Google Testing Blog کے مطابق، بہترین تناسب 70% یونٹ ٹیسٹ، 20% انٹیگریشن ٹیسٹ، 10% E2E ہے۔ اس تناسب سے انحراف رجعت ٹیسٹنگ کی تاثیر کو کم کرتا ہے: بہت زیادہ E2E ٹیسٹ پائپ لائن کو سست کرتے ہیں، بہت کم یونٹ ٹیسٹ مائیکرو بگ کو بغیر پکڑے چھوڑ دیتے ہیں۔

رجعت ٹیسٹنگ کو خودکار بنانے کی حکمت عملی

پہلی حکمت عملی مکمل رجعت ہے۔ پروجیکٹ کے تمام ٹیسٹ چلائے جاتے ہیں۔ سب سے قابل اعتماد لیکن سب سے سست طریقہ۔ چھوٹے پروجیکٹس (10,000 ٹیسٹوں تک، چلنے کا وقت <30 منٹ) کے لیے موزوں۔ بڑے پروجیکٹس کے لیے، مکمل رجعت میں گھنٹے لگ سکتے ہیں، جس سے CI/CD پائپ لائن ناقابل عمل ہو جاتی ہے۔

دوسری حکمت عملی انتخابی رجعت ہے۔ صرف تبدیل شدہ کوڈ سے متعلق ٹیسٹ چلائے جاتے ہیں۔ تعلقات کا تعین کرنے کے لیے کوڈ ڈیپنڈنسی گراف استعمال کیا جاتا ہے۔ اوزار: Bazel (Google)، Nx (JavaScript)، sbt (Scala)۔ انتخابی رجعت 60–80% چلنے کا وقت بچاتی ہے لیکن درست ڈیپنڈنسی گراف تعمیر کی ضرورت ہوتی ہے — غلطیاں چھوٹی ہوئی رجعت کا باعث بنتی ہیں۔

تیسری حکمت عملی ترجیحی رجعت ہے۔ تمام ٹیسٹوں کو ترجیح کے مطابق درجہ بندی کیا جاتا ہے: اہم راستہ (سب سے اہم صارف منظرنامے)، زیادہ خطرہ (بگ ہسٹری والا کوڈ)، تبدیل شدہ کوڈ (تبدیلی سے متاثر کوڈ)۔ سب سے زیادہ ترجیحی ٹیسٹ پہلے چلائے جاتے ہیں — اگر وہ پاس ہو جائیں، تو ڈویلپر کو فوری فیڈ بیک ملتا ہے۔ وقت کی پابندی والا چلانا: اہم ٹیسٹ 10 منٹ میں چیک کیے جاتے ہیں، باقی پس منظر میں چلتے ہیں۔

پروجیکٹ میں رجعت کو کیسے روکیں

پہلا اور سب سے اہم قدم ٹیسٹ لکھنے کی ثقافت ہے۔ ہر تبدیلی کے ساتھ ایک ٹیسٹ ہونا چاہیے جو تصدیق کرے کہ تبدیلی کام کرتی ہے اور ایک ٹیسٹ جو تصدیق کرے کہ کچھ نہیں ٹوٹا۔ TDD (ٹیسٹ ڈریون ڈویلپمنٹ) بہترین نتائج دیتا ہے: ڈویلپر پہلے ایک ناکام ٹیسٹ لکھتا ہے، پھر کوڈ جو اسے پاس کراتا ہے۔ یہ ضمانت دیتا ہے کہ ٹیسٹ کوڈ سے پہلے موجود ہے۔

دوسرا قدم لازمی ٹیسٹ عملدرآمد والا CI/CD پائپ لائن ہے۔ جب تک تمام ٹیسٹ پاس نہ ہو جائیں، پل ریکویسٹ کو مرج نہیں کیا جا سکتا۔ عجلت کی وجہ سے ٹیسٹوں کو «چھوڑا» نہیں جا سکتا — فوری تبدیلیاں تیز لیکن لازمی ٹیسٹ سوٹ سے گزرتی ہیں۔ Google DevOps Research کے مطابق، لازمی CI/CD والی ٹیموں میں پروڈکشن میں 3 گنا کم رجعت ہوتی ہے۔

تیسرا قدم پروڈکشن مانیٹرنگ ہے۔ بہترین ٹیسٹ بھی رجعت کے خلاف 100% تحفظ کی ضمانت نہیں دیتے۔ آبزرویبلٹی اوزار (Sentry، Datadog، New Relic) کو ہر ڈیپلائیمنٹ کے بعد اہم میٹرکس ٹریک کرنی چاہیے: خرابی کی شرح، تاخیر، تھرو پٹ۔ حدوں سے تجاوز کرنے پر خودکار رول بیک ایک حفاظتی جال ہے اگر رجعت پروڈکشن تک پہنچ جائے۔

چوتھا قدم رجعت ذہنیت کے ساتھ کوڈ ریویو ہے۔ جائزہ لینے والے کو پوچھنا چاہیے: «اس تبدیلی سے کون سے دوسرے ماڈیول ٹوٹ سکتے ہیں؟». صرف کوڈ کے درست ہونے کی جانچ کرنا کافی نہیں ہے — یہ جانچنا ضروری ہے کہ یہ متعلقہ فعالیت کو متاثر نہیں کرے گا۔ کوڈ ریویو چیک لسٹ میں «متعلقہ ماڈیولز میں رجعت کی جانچ» آئٹم شامل ہونا چاہیے۔