دستی ہدایات: ڈیپلائے ٹارگٹس اور آپ کا اپنا ڈومین

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

ٹارگٹ بنانے کے لیے مجھے کیا چاہیے؟

پانچ چیزیں، Settings → Deploy میں:

1. ایک نام جسے آپ بعد میں پہچان لیں گے — "prod-vps"، "client-hostgator"، جو بھی رات 11 بجے ڈراپ ڈاؤن میں سمجھ آ جائے
2. ہوسٹ اور پورٹ
3. SFTP کریڈینشلز
4. ایک ویب روٹ پاتھ

کوئی API ٹوکن نہیں، سرور پر انسٹال کرنے کے لیے کوئی CLI نہیں، کوئی cron job نہیں سنبھالنی۔ اگر آپ کا ہوسٹ SFTP رسائی دیتا ہے — جو تقریباً ہر شیئرڈ ہوسٹ، ہر VPS، ہر منیجڈ ورڈپریس بکس پر ہوتا ہے — تو آپ تقریباً دو منٹ میں مکمل ہو جائیں گے۔

پاس ورڈ یا کی؟

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

صحیح ویب روٹ پاتھ کیسے تلاش کروں؟

یہ وہ فیلڈ ہے جسے لوگ پہلی بار غلط سمجھتے ہیں، کیونکہ غلط جواب بھی قابلِ یقین لگتا ہے۔ یہ آپ کی ہوم ڈائریکٹری نہیں، یہ نہیں ہے /var/www — یہ عین وہی فولڈر ہے جسے آپ کا ویب سرور سرو کرنے کے لیے کنفیگر کیا گیا ہے۔

اگر آپ کو یقین نہیں، تو کسی بھی SFTP کلائنٹ کے ذریعے test.txt کو اُس فولڈر میں ڈالیں جسے آپ درست سمجھتے ہیں، پھر چیک کریں کہ آیا یہ yoursite.com/test.txtپر لوڈ ہوتا ہے۔ اگر یہ غلط ہو جائے تو ڈپلائے پھر بھی کامیابی کی رپورٹ دے گا — ایجنٹ وفاداری سے غلط فولڈر میں فائلیں لکھ دیتا ہے، اور آپ ایک لائیو سائٹ کو گھورتے رہ جاتے ہیں جو تبدیل نہیں ہوئی، یہ سوچتے ہوئے کہ آخر کیوں۔

کیا ایک ٹارگٹ ایک سے زیادہ ڈومینز کو کور کر سکتا ہے؟

جی ہاں، اور یہ وہ حصہ ہے جو آپ کی پہلی سائٹ کے بعد اصل وقت بچاتا ہے۔ ایک ٹارگٹ ایک سرور اور کریڈینشلز کا ایک مجموعہ ہے — یہ کسی ایک ڈومین سے بندھا نہیں ہوتا۔ Domain Management میں آپ ہر ڈومین کو اپنے ویب روٹ اوور رائیڈ کے ساتھ ایک ٹارگٹ سے اٹیچ کرتے ہیں۔ Nginx سرور بلاکس والے ایک VPS سے تین سائٹس چلا رہے ہیں؟

• site-a → /var/www/site-a
• site-b → /var/www/site-b
• site-c → /var/www/site-c

ایک ٹارگٹ، تین اٹیچمنٹس۔ آپ SSH پاس ورڈ تین بار دوبارہ درج نہیں کر رہے، اور آپ تین تقریباً یکساں ٹارگٹس نہیں سنبھال رہے جو اس دن ہم آہنگی کھو دیں جب آپ کوئی کی گھمائیں اور ان میں سے ایک کو بھول جائیں۔ تینوں میں سے کسی بھی ڈومین پر ڈیپلائے پر کلک کریں اور یہ پہلے سے جانتا ہے کہ کون سا سرور اور کون سا فولڈر — آپ ڈیپلائے کے وقت کبھی انتخاب نہیں کرتے۔

کنیکٹ ہوتے وقت ایجنٹ اصل میں کیا کرتا ہے؟

پہلے، یہ ارد گرد دیکھتا ہے — صرف پڑھنے کے لیے، ابھی کچھ نہیں لکھا جاتا۔ یہ معائنہ چیک کرتا ہے:

• ایک خالی فولڈر
• اسی بلڈ کا ایک پرانا ورژن
• ایک پرانی ورڈپریس تنصیب
• ایک "جلد آ رہا ہے" پلیس ہولڈر جو آپ کے ہوسٹ نے بطور ڈیفالٹ وہاں ڈال دیا

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

• A .well-known SSL توثیق کے لیے فولڈر
• ایک uploads ڈائریکٹری جسے کسی نے git میں نہیں ڈالا
• A wp-config.php جسے کوئی چھونا نہیں چاہتا

یہاں کام "مٹا کر بدل دو" سے زیادہ "جو بدلا اسے پتا کرو اور ہم آہنگ کرو" کے قریب ہے۔

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

کیا یہ میرا سورس کوڈ اپلوڈ کرتا ہے یا بلٹ سائٹ؟

بلٹ سائٹ، ہمیشہ۔ سٹیٹک سائٹ کے لیے یہ جنریٹ شدہ صفحات ہوتے ہیں۔ فریم ورک بلڈ کے لیے — Next.js، Vite، سائٹ کی قسم جو بھی مانگے — یہ کمپائل شدہ آؤٹ پٹ ہے، dist یا build فولڈر، کبھی سورس ٹری نہیں۔ میرے خیال میں یہ صحیح فیصلہ ہے حالانکہ اس کا مطلب یہ ہے کہ آپ SSH کر کے سرور پر موجود چیز کے خلاف npm run dev نہیں چلا سکتے۔ سورس اپلوڈ کرنے کا مطلب یہ ہوگا کہ آپ کے پروڈکشن ویب روٹ کو صرف HTML سرو کرنے کے لیے Node رن ٹائم اور بلڈ ٹول چین کی ضرورت پڑے — ایک شیئرڈ ہوسٹنگ باکس، جو کبھی بلڈ پائپ لائن چلانے کے لیے نہیں بنا تھا، کو ایسا بنانا، اور ہر ڈپلائے کو "امید ہے کہ سرور کے پاس ختم کرنے کے لیے کافی میموری ہے" میں بدلنا npm install۔ صرف کمپائل شدہ آؤٹ پٹ شپ کرنا ویب روٹ کو عین وہی رکھتا ہے جو ایک سٹیٹک فائل سرور توقع کرتا ہے۔ بورنگ۔ رات دو بجے جب کچھ غلط ہو اور آپ اُس فولڈر کو گھور کر سمجھنے کی کوشش کر رہے ہوں کہ اصل میں کیا سرو ہو رہا ہے، تب بورنگ ہی وہ چیز ہے جو آپ چاہتے ہیں۔

مجھے کیسے پتا چلے گا کہ ڈپلائے واقعی کامیاب رہا؟

اپلوڈ کے بعد، ایجنٹ لائیو URL پر جاتا ہے اور چیک کرتا ہے کہ آیا یہ resolve ہوتا ہے — نہ 500، نہ خالی صفحہ۔ جو کچھ اسے ملے، اور معائنے کے دوران جو کچھ اس نے نوٹ کیا اور جس پر وہ آپ کی رائے چاہتا ہے ("اس ویب روٹ میں ایک wp-content فولڈر ہے جسے میں نے نہیں چھیڑا، تصدیق کریں کہ یہ متوقع ہے")، وہ بلڈ کی چیٹ تھریڈ میں آتا ہے۔ یہی پیٹرن پورے پلیٹ فارم میں چلتا ہے: نہ خاموش کامیابی، نہ خاموش ناکامی جو سپورٹ ٹکٹ بن جائے۔ ایجنٹ آپ کو بتاتا ہے کہ اس نے کیا دیکھا اور کیا فیصلہ کیا، اسی تھریڈ میں جہاں آپ نے بلڈ مانگا تھا۔

ورژن ہسٹری میں دراصل کیا ہوتا ہے؟

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

revert دراصل کیا بحال کرتا ہے؟

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

اور جس لمحے آپ کو اس کی اصل ضرورت پڑتی ہے وہ کبھی پرسکون نہیں ہوتا؛ یہ "نیا بلڈ چیک آؤٹ توڑ چکا ہے اور ٹریفک اس وقت لائیو ہے" جیسا ہوتا ہے۔

ایک کلک، پچھلا ورژن بحال، ختم۔ اسے ایک ضمنی فیچر کے بجائے فرسٹ کلاس فیچر سمجھنے کی وجہ Iterating without fear میں موجود ہے — ضرورت پڑنے سے پہلے ایک بار پڑھنے کے قابل۔ ہسٹری اور ریسٹور کنٹرول دونوں بلڈ کارڈ اور ٹارگٹ کی اپنی ہسٹری ویو میں موجود ہیں۔

کیا یہ میرے ڈیٹا بیس کا بیک اپ بھی لیتا ہے؟

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