פריסה לשרת שלך פירושה למסור לסוכן גישה קרובה ל-SSH לתיבה שעליה אתה משלם, ושייתכן שדברים אחרים חיים בה כבר. זו רמת אמון שונה מפרסום לתת-דומיין חינמי, וההגדרה משקפת זאת - כמה שדות, שמולאים פעם אחת, ואחר כך כל בנייה לאחר מכן היא כפתור אחד. אלו השאלות שאנשים שואלים בפועל לפני ואחרי שהם מגדירים אחד.
מה אני צריך כדי ליצור יעד?
חמישה דברים, בהגדרות → פריסה:
- שם שתזכור אחר כך - "prod-vps", "client-hostgator", כל מה ששורד תפריט נפתח בשעה 11 בלילה
- מארח ופורט (Host ו-Port)
- פרטי גישת SFTP
- נתיב webroot
אין אסימוני API, אין CLI להתקין על השרת, אין משימת cron לעקוב אחריה. אם האחסון שלך מעניק גישת SFTP - וזה כולל כמעט כל אחסון משותף, כל VPS, כל תיבת WordPress מנוהלת - אתה מסיים בערך בתוך שתי דקות.
סיסמה או מפתח?
מפתח, אם האחסון שלך תומך בכך. סיסמאות עובדות מצוין ואנו שומרים אותן מוגבלות לחשבון שלך, אבל מפתח הוא סוד אחד פחות שמתגורר בכל מקום - ההבדל בין "לבטל מפתח" לבין "לאפס סיסמה בכל מקום שבו הסיסמה הזו במקרה שימשה" אם משהו ישתבש בהמשך. הרבה הגדרות SFTP של אחסון משותף זול מציעות רק אימות בסיסמה, וזה גם בסדר. רק אל תשתמש באותה סיסמה במקום אחר.
איך אני מוצא את נתיב ה-webroot הנכון?
זהו השדה שאנשים טועים בו בפעם הראשונה, כי התשובה השגויה עדיין נראית סבירה. זו לא תיקיית הבית שלך, זו לא /var/www — זו התיקייה המדויקת שהשרת שלך מוגדר להגיש ממנה.
| שרת | webroot טיפוסי |
|---|---|
| Apache / cPanel | public_html |
| Nginx | /var/www/mysite/html — או נתיב כלשהו שמפתח קודם קרא לו לפני שלוש שנים מסיבות שאף אחד לא זוכר |
אם אתה לא בטוח, שים קובץ חד-פעמי test.txt לתוך התיקייה שאתה חושב שנכונה באמצעות כל לקוח SFTP, ואז בדוק אם הוא נטען ב- yoursite.com/test.txt. תטעה כאן והדיפלוי עדיין ידווח על הצלחה — הסוכן כותב נאמנה קבצים לתיקייה הלא נכונה, ואתה נשאר מביט באתר חי שלא השתנה, ותוהה למה.
יכול יעד אחד לכלול יותר מדומיין אחד?
כן, וזה החלק שחוסך זמן ממשי כשאתה עוקף את האתר הראשון שלך. יעד הוא שרת אחד וסט אחד של פרטי גישה - הוא לא קשור לדומיין בודד. בניהול דומיינים אתה מצרף כל דומיין ליעד עם override נתיב webroot משלו. מריץ שלושה אתרים על VPS אחד עם בלוקי שרת Nginx?
site-a→/var/www/site-asite-b→/var/www/site-bsite-c→/var/www/site-c
יעד אחד, שלושה צירופים. אתה לא מזין שוב סיסמת SSH שלוש פעמים, ואתה לא מתחזק שלושה יעדים דומים שסוחפים זה מזה ביום שתסבב מפתח ותשכח אחד מהם. לחץ על פריסה באחד משלושת הדומיינים והוא יודע כבר איזה שרת ואיזו תיקייה - אתה אף פעם לא בוחר בזמן הפריסה.
מה הסוכן עושה בפועל כשהוא מתחבר?
ראשית, הוא מסתובב - בקריאה בלבד, בלי לכתוב עדיין שום דבר. הבדיקה הזו מחפשת:
- תיקייה ריקה
- גרסה קודמת של הבנייה הזו עצמה
- התקנת WordPress ישנה
- מציין מקום של "בקרוב" שהאחסון שלך השאיר שם כברירת מחדל
זה קובע את האסטרטגיה. webroot ריק מקבל העלאה פשוטה. webroot שיש בו כבר משהו מטופל בקפידה יותר, כי הרבה הגדרות אמיתיות כוללות דברים שחיים לצד האתר ולא צריכים להיעלם:
- A
.well-knownתיקיית לאימות SSL - תיקיית
uploadsשאף אחד לא הכניס ל-git - A
wp-config.phpשאף אחד לא רוצה שייגעו בה
המשימה כאן קרובה יותר ל"להבין מה השתנה ולתאם זאת" מאשר ל"למחוק ולהחליף".
לאחר מכן, לפני שבייט אחד נכתב עליו מחדש, ה-webroot הקיים נלכד כגרסה על האחסון שלך עצמך. לא רשומת מסד נתונים, לא diff שאנחנו מחשבים ומקווים שהוא נכון - אלא תמונת מצב ממשית של מה שהיה שם. זה חשוב ביותר בפריסה הראשונה ביותר לכל יעד, כי הפריסה הזו תמיד נוחתת על משהו, אפילו אם אותו משהו הוא כלום. תיקייה ריקה, תמונת מצב ריקה. אתר סטטי בן חמש שנים שאף אחד לא זוכר שבנה - נשמר בדיוק כמו שהוא, בחינם, לפני שנוגעים בו. הפריסה הראשונה הזו היא גם זו שאתה הכי פחות בטוח בה, אז זו זו שבה הדבר הזה חשוב ביותר.
האם היא מעלה את קוד המקור שלי או את האתר הבנוי?
האתר הבנוי, תמיד. עבור אתר סטטי אלו הדפים שנוצרו. עבור בילד של פריימוורק — Next.js, Vite, מה שסוג האתר דורש — זו הפלט המקומפל, תיקיית ה- dist או build , לעולם לא עץ המקור. אני חושב שזו ההחלטה הנכונה למרות שהיא אומרת שאתה לא יכול להתחבר ב-SSH ולהריץ npm run dev מול מה שנמצא על השרת. העלאת מקור הייתה אומרת שה-webroot בפרודקשן שלך צריך זמן ריצה של Node וכלי בילד רק כדי להגיש HTML — הופך שרת אחסון משותף שמעולם לא נועד להריץ צינור בילד לכזה, והופך כל דיפלוי ל"תקווה שלשרת יש מספיק זיכרון לסיים npm install." שילוח רק פלט מקומפל שומר על ה-webroot בדיוק כמו שרת קבצים סטטי מצפה. משעמם. משעמם זה מה שאתה רוצה בשתיים בלילה כשמשהו לא בסדר ואתה מביט בתיקייה ההיא מנסה להבין מה בעצם מוגש.
איך אני יודע שדיפלוי אכן הצליח?
אחרי ההעלאה, הסוכן פונה לכתובת ה-URL החיה ובודק אם היא נטענת — לא 500, לא דף ריק. מה שהוא מוצא, בתוספת כל דבר שהוא שם לב אליו במהלך הבדיקה שהוא רוצה את הקלט שלך עליו ("ל-webroot הזה יש תיקיית wp-content שהשארתי ללא שינוי, אשר שזה מצופה"), נוחת בשרשור הצ'אט של הבילד. זה הדפוס בכל הפלטפורמה הזו: אין הצלחה שקטה, אין כישלון שקט שהופך לכרטיס תמיכה. הסוכן מספר לך מה הוא ראה ומה הוא החליט, באותו שרשור שבו ביקשת את הבילד.
מה בעצם נמצא בהיסטוריית הגרסאות?
כל דיפלוי מוסיף גרסה — לא רק הראשון. אז ההיסטוריה היא לא הבילדים שלך מוצגים על ציר זמן מופשט; זו הרצף המילולי של מה שהוגש בפועל מאותו webroot, לפי הסדר, החל ממה שהיה שם לפני שהגעת. גרסה אחת היא תמיד אותו מצב טרום-הפלטפורמה, שנלכד אוטומטית. אתה לא צריך לחשוב על זה.
מה בדיוק חזרה לאחור (revert) משחזרת?
את הגרסה הפעילה הקודמת, בדיוק כפי שהייתה — לא הרצה מחדש של בילד ישן, לא קירוב. הקבצים ממש שהגישו את התעבורה לפני כן. זו ערבות משמעותית וחזקה יותר ממה שרוב תכונות ה-"rollback" שהשתמשתי בהן במקומות אחרים מציעות, שבדרך כלל אומרות "פרוס מחדש מקומיט ישן" ומניחות בשקט שתהליך הבילד שלך דטרמיניסטי ושהסביבה שלך לא סטתה מאז. כאן, revert הוא שחזור של תמונת מצב ידועה כתקינה, ולכן בטוח לפנות אליו תחת לחץ — אתה לא צריך לתהות אם ה-rollback עשוי להתנהג אחרת ממה שהוא משחזר.
והרגע שבו אתה באמת צריך את זה אף פעם לא רגוע; זה "הבילד החדש שבר את הצ'קאאוט והתעבורה חיה עכשיו."
לחיצה אחת, הגרסה הקודמת משוחזרת, סיימת. ההיגיון מאחורי הטיפול בזה כתכונה מרכזית ולא כאפטרתפקט נמצא ב-איטרציה ללא פחד — שווה קריאה פעם אחת, לפני שתצטרך את זה. גם ההיסטוריה וגם פקד השחזור נמצאים בכרטיס הבילד וגם בתצוגת ההיסטוריה של היעד עצמו.
זה מגבה גם את מסד הנתונים שלי?
לא, ואני מעדיף לומר את זה בפירוש מאשר לתת למישהו להניח אחרת. היסטוריית הגרסאות בהוסט מכסה את מה שצינור הדיפלוי הזה שם ב-webroot. אם לאתר שלך יש מסד נתונים, או העלאות משתמשים, או כל דבר אחר שמשתנה מחוץ לדיפלויים, זהו עניין נפרד לגמרי — revert לא נוגע בו ולא צריך להיחשב כאסטרטגיית גיבוי שכן.
