اسٹیجنگ ماحول کیا ہے؟ لائیو جانے سے پہلے ٹیسٹ کریں

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

AI کے ساتھ بناتے وقت اسٹیجنگ کیوں اہم ہے

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

ایک ایسی جگہ جہاں تبدیلیاں لائیو جانے سے پہلے دیکھی جائیں، آپ کو یہ کرنے میں مدد دیتی ہے:

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

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

کسی تھیٹر کی ڈریس ریہرسل کا تصور کریں۔

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

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

تین عام ماحول

ہر ماحول بنیادی طور پر اپنی کنفیگریشن میں مختلف ہوتا ہے: کون سے ڈیٹا بیس سے جڑتا ہے، کون سی keys استعمال کرتا ہے، کس URL پر ہے۔ اسی لیے اچھی ایپس یہ سیٹنگز environment variables اور secrets سے پڑھتی ہیں، کوڈ میں سخت لکھنے کی بجائے۔ اس طرح ایک ہی کوڈ ہر ماحول میں مختلف سیٹنگز کے ساتھ چل سکتا ہے۔

ایک عملی مثال: بکنگ ایپ کے منسوخی کے قواعد بدلنا

آپ ایک سیلون بکنگ ایپ چلاتے ہیں جس کے ادائیگی کرنے والے گاہک ہیں۔ آپ قاعدہ بدلنا چاہتے ہیں تاکہ گاہک 48 گھنٹے کی بجائے 24 گھنٹے پہلے منسوخ کر سکیں، اور رقم کی واپسی خودکار ہو۔

1. ڈویلپمنٹ میں بنائیں۔ آپ اپنے AI بلڈر سے تبدیلی مانگتے ہیں۔ وہ منسوخی کی منطق اور آپ کے پیمنٹ فراہم کنندہ کو رقم واپسی کی کال اپڈیٹ کرتا ہے۔

2. اسٹیجنگ میں جاری کریں۔ اسٹیجنگ وہی کوڈ چلاتا ہے، ایک اسٹیجنگ ڈیٹا بیس سے جڑا ہوا، جس میں ٹیسٹ بکنگز ہیں، اور آپ کے پیمنٹ فراہم کنندہ کی ٹیسٹ موڈ keys ہیں۔

3. حقیقی فلوز ٹیسٹ کریں۔ آپ اور ایک ساتھی:

• کل کے لیے ایک ٹیسٹ اپائنٹمنٹ بک کرتے ہیں اور اسے 30 گھنٹے پہلے منسوخ کرتے ہیں، رقم واپس ہونی چاہیے؛
• 10 گھنٹے پہلے منسوخ کرنے کی کوشش کرتے ہیں، واضح پیغام کے ساتھ انکار ہونا چاہیے؛
• دیکھتے ہیں کہ رقم کی واپسی پیمنٹ فراہم کنندہ کے ٹیسٹ ڈیش بورڈ میں ظاہر ہوتی ہے؛
• تصدیقی ای میل میں 24 گھنٹے لکھا ہے، 48 نہیں۔

4. خرابی ڈھونڈیں۔ اسٹیجنگ میں آپ دیکھتے ہیں کہ قاعدہ سرور کا ٹائم زون استعمال کرتا ہے، سیلون کا نہیں، اس لیے کٹ آف ایک گھنٹہ غلط ہے۔ آپ اسے ٹھیک کرتے ہیں اور دوبارہ ٹیسٹ کرتے ہیں۔

5. پروڈکشن میں جاری کریں۔ اب ہی تبدیلی حقیقی گاہکوں تک پہنچتی ہے، ٹائم زون کی خرابی پہلے ہی پکڑی جا چکی ہے۔

اسٹیجنگ کے بغیر، مرحلہ 4 کسی حقیقی گاہک کی رقم کی واپسی پر ہوتا۔

اہم اصطلاحات

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

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

اپنے AI بلڈر سے کیا مانگیں

• “ہر ماحول کی مخصوص سیٹنگ، یعنی ڈیٹا بیس، API keys اور سائٹ URL، environment variables سے لیں۔”
• “ایک seed اسکرپٹ شامل کریں جو غیر پروڈکشن ڈیٹا بیس کو حقیقت سے قریب ٹیسٹ ڈیٹا سے بھرے۔”
• “جب تک میں لانچ کا نہ کہوں، ادائیگی فراہم کنندہ کا ٹیسٹ موڈ استعمال کریں۔”
• “اس تبدیلی کے لائیو جانے سے پہلے، بتائیں کہ مجھے کون سے فلوز ٹیسٹ کرنے ہیں اور ہر ایک میں کیا ہونا چاہیے۔”
• “کیا اس تبدیلی سے موجودہ ڈیٹا متاثر ہوگا؟ پہلے مائیگریشن دکھائیں۔”
• “یقینی بنائیں کہ سائٹ کی غیر پروڈکشن نقلیں سرچ انجنز کے ذریعے انڈیکس نہ ہوں۔”

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

Mythex میں ریلیز سے پہلے ٹیسٹنگ

Mythex میں “اسٹیجنگ بمقابلہ پروڈکشن” کا کوئی الگ سوئچ نہیں؛ publish کرنے سے آپ کو ایک لائیو عوامی URL ملتا ہے، اور docs یہ صاف بتاتے ہیں (multi-service apps)۔ جو یہ دیتا ہے وہ تعمیر اور لائیو جانے کے درمیان واضح لکیر ہے:

• Preview آپ کی ایپ کو تعمیر کے دوران ایک نجی کلاؤڈ سینڈ باکس میں چلاتا ہے۔ تبدیلیاں پہلے وہاں ظاہر ہوتی ہیں، لائیو ایپ پر نہیں۔
• Share پریویو لنکس بناتا ہے تاکہ کلائنٹ یا ساتھی بغیر Mythex اکاؤنٹ کے، اور آپ کے publish کیے بغیر، جاری کام کا جائزہ لے سکیں۔ لنک سینڈ باکس کو اسی حالت میں دکھاتا ہے جیسا وہ ابھی ہے، تعمیر کے دوران کی تبدیلیوں سمیت، اور آپ اسے کسی بھی وقت حذف کر سکتے ہیں۔
• Publish پروجیکٹ کا snapshot لے کر اسے deploy کرتا ہے۔ جب تک آپ دوبارہ publish نہ کریں، لائیو ایپ ویسی ہی رہتی ہے۔
• Checkpoints ایجنٹ کی ہر کامیاب باری کے بعد محفوظ ہوتے ہیں، تاکہ کوئی تبدیلی غلط ہو تو آپ پروجیکٹ فائلیں واپس لا سکیں۔

Preview کو اپنی ریہرسل سمجھیں: ادائیگی فراہم کنندگان کو لانچ تک ٹیسٹ موڈ میں رکھیں، اور ہر publish سے پہلے اپنے اہم فلوز چلا لیں۔ جب حقیقی گاہک شامل ہوں، تو کوئی ایسی چیز آزمانے سے پہلے جو ڈیٹا لکھے یا حذف کرے، ایجنٹ سے پوچھیں کہ آپ کا Preview کون سا ڈیٹا بیس اور keys استعمال کرتا ہے۔ اگر آپ کو اپنے ڈیٹا بیس کے ساتھ مکمل طور پر الگ اسٹیجنگ سیٹ اپ چاہیے، تو ایجنٹ سے اپنے پروجیکٹ کے آپشنز سمجھنے کو کہیں، یا Pro پر پروجیکٹ export کریں یا GitHub سے sync کر کے اسے اپنے کنٹرول والے انفراسٹرکچر پر چلائیں۔

سوالات