استقرار روی سرور خودتان بهمعنای دادن دسترسی شبهSSH به یک ایجنت روی جعبهای است که برایش پول میدهید، جعبهای که ممکن است از قبل چیزهای دیگری روی آن باشد. این سطح اعتمادی متفاوت از انتشار روی یک زیردامنهٔ رایگان است، و راهاندازی این را نشان میدهد — چند فیلد، یکبار پرشده، و از آن پس هر ساختی یک دکمه است. اینها چیزهایی است که مردم واقعاً قبل و بعد از راهاندازی میپرسند.
برای ساختن یک مقصد به چه چیزی نیاز دارم؟
پنج چیز، در تنظیمات → استقرار:
- نامی که بعداً بهیادش میآورید — «prod-vps»، «client-hostgator»، هرچه در فهرست کشویی ساعت ۱۱ شب زنده بماند
- میزبان و پورت
- اطلاعات ورود SFTP
- مسیر webroot
بدون توکن API، بدون CLI برای نصب روی سرور، بدون کرونجابی که نیاز به مراقبت داشته باشد. اگر میزبان شما دسترسی SFTP میدهد — که تقریباً هر هاست اشتراکی، هر VPS، هر جعبهٔ مدیریتشدهٔ وردپرس را شامل میشود — در حدود دو دقیقه کارتان تمام است.
رمز عبور یا کلید؟
کلید، اگر میزبانتان پشتیبانی میکند. رمزهای عبور هم خوب کار میکنند و ما آنها را محدود به حساب شما ذخیره میکنیم، اما کلید یک راز کمتر است که جایی نشسته باشد — تفاوت بین «باطلکردن یک کلید» و «تغییر رمز عبور در همهجایی که آن رمز بهطور اتفاقی دوباره استفاده شده» اگر بعداً مشکلی پیش بیاید. بسیاری از تنظیمات ارزان SFTP هاست اشتراکی فقط احراز هویت با رمز عبور ارائه میدهند، و آن هم اشکالی ندارد. فقط آن رمز را جای دیگری استفاده نکنید.
چطور مسیر درست webroot را پیدا کنم؟
این همان فیلدی است که افراد بار اول اشتباه میگیرند، چون جواب اشتباه هم قابلقبول به نظر میرسد. این پوشهی خانگی شما نیست، این /var/www — دقیقاً همان پوشهای است که وبسرور شما برای سرو کردن از آن پیکربندی شده.
| سرور | webroot معمول |
|---|---|
| Apache / cPanel | public_html |
| Nginx | /var/www/mysite/html — یا یک مسیری که یک توسعهدهندهی قبلی سه سال پیش به دلایلی که کسی یادش نیست نامگذاری کرده |
اگر مطمئن نیستید، یک فایل آزمایشی test.txt را با هر کلاینت SFTP در پوشهای که فکر میکنید درست است بگذارید، سپس بررسی کنید که آیا در yoursite.com/test.txt بار میشود. اگر این را اشتباه بگیرید، دیپلوی همچنان موفقیت گزارش میدهد — ایجنت با وفاداری فایلها را در پوشهی اشتباه مینویسد، و شما در حال نگاه کردن به یک سایت زنده هستید که تغییری نکرده و تعجب میکنید چرا.
آیا یک مقصد میتواند بیش از یک دامنه را پوشش دهد؟
بله، و این همان بخشی است که بعد از اولین سایتتان زمان واقعی صرفهجویی میکند. یک مقصد یک سرور و یک مجموعه اطلاعات ورود است — به یک دامنهٔ واحد گره نخورده است. در مدیریت دامنه هر دامنه را با یک بازنویسی webroot مخصوص خودش به یک مقصد متصل میکنید. سه سایت را روی یک VPS با بلوکهای سرور Nginx اجرا میکنید؟
site-a→/var/www/site-asite-b→/var/www/site-bsite-c→/var/www/site-c
یک مقصد، سه اتصال. لازم نیست یک رمز عبور SSH را سه بار وارد کنید، و سه مقصد تقریباً یکسان را نگه ندارید که روزی تغییر کلید بدهید و ناهماهنگ شوند و یکیشان فراموش شود. روی استقرار هر یک از این سه دامنه کلیک کنید و از پیش میداند کدام سرور و کدام پوشه — هرگز در زمان استقرار انتخاب نمیکنید.
وقتی متصل میشود ایجنت واقعاً چهکار میکند؟
اول، اطراف را نگاه میکند — فقط خواندنی، هنوز چیزی نوشته نشده. این بررسی بهدنبال اینهاست:
- یک پوشهٔ خالی
- یک نسخهٔ قبلی از همین ساخت دقیق
- یک نصب قدیمی وردپرس
- یک نگهدارندهٔ «بهزودی» که میزبانتان بهطور پیشفرض آنجا گذاشته
این استراتژی را تعیین میکند. یک webroot خالی آپلود سادهای میگیرد. یک webroot که از قبل چیزی در آن هست با احتیاط بیشتری مدیریت میشود، چون بسیاری از تنظیمات واقعی چیزهایی دارند که کنار سایت زندگی میکنند و نباید ناپدید شوند:
- A
.well-knownپوشه برای اعتبارسنجی SSL - یک
uploadsدایرکتوری که کسی آن را در git قرار نداده - A
wp-config.phpکه کسی نمیخواهد به آن دست بزنید
کار در اینجا به «تشخیص چه چیزی تغییر کرده و تطبیقدادنش» نزدیکتر است تا «پاک کردن و جایگزینی».
سپس، پیش از آنکه حتی یک بایت رونویسی شود، webroot موجود بهعنوان یک نسخه روی خود میزبانتان ضبط میشود. نه یک رکورد پایگاهداده، نه یک تفاوتی که ما محاسبه میکنیم و امید داریم درست باشد — بلکه یک عکس فوری واقعی از آنچه آنجا بوده. این در اولین استقرار روی هر مقصد بیشترین اهمیت را دارد، چون آن استقرار همیشه روی چیزی فرود میآید، حتی اگر آن چیز هیچ باشد. پوشهٔ خالی، عکسفوریِ خالی. سایت استاتیک پنجسالهای که کسی ساختنش را بهیاد نمیآورد — دقیقاً حفظ میشود، رایگان، پیش از آنکه دست بخورد. آن اولین استقرار همچنین همانی است که کمترین اطمینان را دربارهٔ آن دارید، پس همانی است که این موضوع بیشترین اهمیت را دارد.
آیا کد منبع من را آپلود میکند یا سایت ساختهشده را؟
همیشه سایت ساختهشده. برای یک سایت استاتیک، این صفحات تولیدشده است. برای یک ساخت فریمورک — Next.js، Vite، هرچه نوع سایت باشد — خروجی کامپایلشده است، پوشهی dist یا build ، هرگز درخت سورس. فکر میکنم این تصمیم درستی است حتی اگر یعنی نمیتوانید SSH بزنید و npm run dev را در برابر آنچه روی سرور است اجرا کنید. آپلود سورس یعنی webroot تولید شما باید یک رانتایم Node و یک زنجیره ابزار ساخت داشته باشد فقط برای سرو کردن HTML — تبدیل یک باکس هاست اشتراکی که هرگز برای اجرای یک پایپلاین ساخت طراحی نشده به یکی از آنها، و تبدیل هر دیپلوی به «امید که سرور حافظهی کافی برای تکمیل npm install داشته باشد». ارسال فقط خروجی کامپایلشده، webroot را دقیقاً همان چیزی نگه میدارد که یک سرور فایل استاتیک انتظار دارد. کسلکننده. کسلکننده همان چیزی است که ساعت ۲ بامداد، وقتی چیزی خراب است و به آن پوشه نگاه میکنید تا بفهمید واقعاً چه چیزی سرو میشود، میخواهید.
چطور بفهمم دیپلوی واقعاً کار کرده؟
بعد از آپلود، ایجنت به URL زنده میزند و بررسی میکند که آیا resolve میشود — نه یک خطای ۵۰۰، نه یک صفحهی خالی. هر چه پیدا کند، بههمراه هر چیزی که در حین بازرسی متوجه شده و میخواهد نظر شما را بگیرد («این webroot یک پوشهی wp-content دارد که دستنخورده رهایش کردم، تأیید کنید که این مورد انتظار است»)، در ریسهی گفتگوی همان ساخت قرار میگیرد. این الگویی است که در سراسر این پلتفرم رعایت میشود: نه موفقیت بیصدا، نه شکست بیصدا که به یک تیکت پشتیبانی تبدیل شود. ایجنت به شما میگوید چه دیده و چه تصمیمی گرفته، در همان ریسهای که ساخت را درخواست کردهاید.
واقعاً چه چیزی در تاریخچه نسخهها ثبت میشود؟
هر دیپلوی یک نسخه به تاریخچه اضافه میکند — نه فقط اولین دیپلوی. پس تاریخچه فقط ساختهای شما در برابر یک خط زمانی انتزاعی نیست؛ توالی واقعی چیزی است که از آن webroot سرو شده، به ترتیب، از همان چیزی که قبل از حضور شما آنجا بوده. نسخه یک همیشه همان وضعیت پیش از استفاده از پلتفرم است که بهطور خودکار ثبت میشود. لازم نیست به آن فکر کنید.
بازگردانی (revert) واقعاً چه چیزی را بازمیگرداند؟
دقیقاً همان نسخهی زندهی قبلی — نه یک اجرای دوبارهی یک ساخت قدیمی، نه یک تقریب. همان فایلهای واقعی که ترافیک را سرو میکردند. این تضمینی بهطور معناداری قویتر از اکثر ویژگیهای «rollback» است که در جاهای دیگر دیدهام، که معمولاً یعنی «دوباره دیپلوی کن از یک commit قدیمی» و بیصدا فرض میکند فرآیند ساخت شما قطعی است و محیط شما از آن زمان تغییر نکرده. اینجا revert یعنی بازیابی یک snapshot سالم و شناختهشده، به همین دلیل است که در لحظات فشار میتوان با اطمینان به آن رجوع کرد — لازم نیست به این فکر کنید که آیا rollback ممکن است رفتاری متفاوت از چیزی که به آن برمیگردد داشته باشد.
و لحظهای که واقعاً به آن نیاز دارید هرگز لحظهی آرامی نیست؛ همیشه «ساخت جدید تسویهحساب را خراب کرده و همین الان ترافیک زنده است» است.
یک کلیک، نسخهی قبلی بازگردانده میشود، تمام. دلیل اینکه این را یک ویژگی درجهیک در نظر گرفتیم و نه یک افزودهی حاشیهای، در تکرار بدون ترس آمده — یکبار قبل از اینکه به آن نیاز پیدا کنید بخوانید ارزشش را دارد. هم تاریخچه و هم کنترل بازگردانی، هم روی کارت ساخت و هم در نمای تاریخچهی خود هدف موجود هستند.
آیا این از پایگاهدادهی من هم پشتیبان میگیرد؟
نه، و ترجیح میدهم این را صریح بگویم تا کسی چیز دیگری فرض نکند. تاریخچهی نسخهها روی هاست، فقط چیزی را پوشش میدهد که این پایپلاین دیپلوی در webroot قرار داده. اگر سایت شما پایگاهداده، آپلودهای کاربر، یا هر چیز دیگری خارج از دیپلویها تغییر میکند، این کاملاً یک موضوع جداست — revert به آن دست نمیزند و نباید با یک استراتژی پشتیبانگیری که آن را هم پوشش دهد اشتباه گرفته شود.
