ידע מעשי של CyberFixCrew

למה צריך סביבת staging לוורדפרס לפני עדכונים

סביבת staging לוורדפרס היא עותק נפרד שבו בודקים שינויים לפני החלתם באתר הפעיל. היא מועילה רק אם מבודדים ממנה מידע רגיש, חיובים, דיוור וחיבורים אמיתיים. הצלחה בבדיקה מפחיתה אי-ודאות, אך אינה מבטלת בדיקה לאחר העלאה לאוויר.

מה ההבדל בין סביבת בדיקה לאתר הפעיל

Production הוא האתר שמשרת לקוחות; staging משמשת לבדיקת שינוי מוגדר. רצוי לשחזר בה את תנאי התוכנה הרלוונטיים, כגון גרסאות PHP, תוספים ומבנה המטמון, אבל אין צורך להעביר אליה כל מידע אישי או כל הרשאה של האתר הפעיל.

WooCommerce ממליצה לבדוק עדכונים בסביבת staging לפני החלתם בחנות. בתכנון הבדיקה צריך לדעת גם מה שונה בין הסביבות, כדי שלא לפרש הצלחה בסביבה חלקית כהוכחה שכל החיבורים בייצור יפעלו.

WooCommerce: הכנה לעדכון ובדיקתו

איך מבודדים את הסביבה לפני הפעלתה

לפני שמפעילים עותק, הגדירו מי יכול להיכנס ואילו פעולות הוא מורשה לבצע. חסימת גישה באמצעות אימות עדיפה על הסתמכות על כתובת שקשה לנחש. noindex ובקשה לא לסרוק אינם מנגנון הגנה על מידע פרטי.

השתמשו בנתוני בדיקה או צמצמו מידע מועתק לפי הצורך. מפתחות, חשבונות וחיבורים נפרדים מאפשרים לבדוק שינוי בלי לבצע פעולה בשם העסק. ודאו את הבידוד לפני הבקשה הראשונה שעלולה להפעיל משימה אוטומטית.

בדיקות בידוד לפני פתיחת סביבת הבדיקה
רכיבהגדרה מומלצתאיך מאמתים
סליקהחשבונות ומפתחות בדיקה של הספקעסקת בדיקה מופיעה רק במצב הבדיקה
דואר ו-SMSלכידה מקומית או נמעני בדיקה מורשיםאף הודעה אינה נשלחת ללקוחות
Webhooks וחיבורי CRMיעדים נפרדים או ניתוק מתועדאין אירוע בדיקה במערכת הפעילה
משימות ותשלומים מחזורייםמניעת ביצוע פעולות אמתאין חיוב או משימה כפולים
גישה ומידעגישה מוגבלת ומינימום נתוניםבדיקה ממשתמש לא מורשה נכשלת

מה בודקים אחרי העדכון

כתבו תרחישי קבלה לפי המטרה העסקית של האתר. באתר לידים: טופס, הודעת אישור והעברת הפנייה ליעד הבדיקה. בחנות: מוצר, סל, משלוח ותשלום בדיקה. בדקו גם נייד, משתמש לא מחובר ושגיאות שנרשמו בלוגים.

השוו לתוצאה לפני השינוי ושמרו תיעוד של הגרסאות שנבדקו. אם נבדק שילוב מסוים של תוסף ותבנית, אין להוסיף שינוי נוסף בזמן ההעלאה בלי להעריך מחדש את ההשפעה. אישור צריך לכלול תוצאות, לא רק את המשפט האתר נראה תקין.

איך מעבירים שינוי בלי לדרוס הזמנות חדשות

העבירו רק את השינוי שאושר, בתהליך המתאים למערכת. העתקה מלאה של מסד נתוני staging על האתר הפעיל יכולה למחוק הזמנות, פניות או חשבונות שנוספו מאז יצירת העותק. אם השינוי דורש עדכון מסד נתונים, תכננו אותו במפורש עם גיבוי ונקודת חזרה.

בדקו את סוג הפעולה שמבצע כלי האחסון: קבצים בלבד, מסד נתונים או שניהם. הגדירו חלון ביצוע ואחראי לאימות אחרי העלאה. אל תחזירו להגדרות הפעילות בטעות מפתחות בדיקה, חסימת גישה או הגדרות שמונעות אינדוקס.

מה עושים אם צריך לחזור לאחור

תוכנית חזרה צריכה להתייחס גם לנתונים שנוצרו בזמן השינוי. חזרה לקובץ תוסף ישן אינה תמיד מתאימה למסד נתונים שכבר השתנה. WooCommerce מזהירה מפער כזה בהנחיות החזרה לגרסה קודמת.

תעדו מה מוחזר, איך נשמרים הנתונים החדשים ומי בודק את התוצאה. כשהעדכון סגר חולשת אבטחה, חזרה לגרסה הקודמת עלולה להחזיר את החשיפה. במקרה כזה יש לשקול בידוד זמני או תיקון חלופי, ולא לבחור בשחזור אוטומטי רק משום שהוא מהיר.

WooCommerce: מגבלות חזרה לגרסה קודמת
מקור מקצועי: WooCommerce: הכנה לעדכון ובדיקתומקור מקצועי: WooCommerce: מגבלות חזרה לגרסה קודמת

תשובות ברורות

שאלות שעולות בנושא

האם staging מחליפה גיבוי?

לא, סביבת בדיקה מיועדת להערכת שינוי; גיבוי מיועד לשחזור מידע ומערכת. עותק staging עשוי להיות ישן, חלקי או שונה מהאתר הפעיל. צריך גיבוי מתאים ובדיקת שחזור נפרדת, במיוחד כאשר העדכון משנה מסד נתונים או תהליך עסקי.

מספיק לסמן לא לאנדקס את אתר הבדיקה?

לא, ההגדרה מיועדת למנועי חיפוש ואינה מונעת מאדם להגיע לתוכן. סביבת בדיקה שיש בה נתונים או הרשאות צריכה הגבלת גישה ממשית. בעת העלאה לאוויר חשוב לבדוק גם שלא הועתקו בטעות לאתר הפעיל הגדרות החוסמות גישה או אינדוקס.

למה תשלום בדיקה הצליח אבל התשלום באתר נכשל?

ספק תשלום, הרשאות, מפתחות, כתובות חזרה ותנאי רשת עשויים להיות שונים בין הסביבות. לכן בדיקת staging אינה סוף התהליך. לאחר ההעלאה צריך אימות מבוקר בהתאם להנחיות ספק התשלום, ללא חיוב לקוחות או ניסויי תשלום בלתי מתואמים.

מתקדמים לפי הצורך

רוצים לבדוק עדכונים לפני שהלקוחות ירגישו אותם?

נוכל לתאם הקמת תהליך בדיקה, בידוד חיבורים ובדיקות קבלה לפי תפקידי האתר. היקף העבודה נקבע לפי האחסון והמערכות המחוברות.

לתיאום בדיקה