סביבת Docker עבור 1C-Bitrix: PHP 8.1, Xdebug, MySQL, Redis

הגדרת סביבת פיתוח לפרויקט על Bitrix

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

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

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

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

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

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

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

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

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

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

אפשרויות סביבה: קונטיינרים, שרת משותף, בנייה ידנית

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

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

שלבי ההטמעה: מאודיט המאגר ועד מסירה לצוות

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

1. אודיט תלויות. מתקבעים גרסאות PHP, MySQL ו-Redis, רשימת ההרחבות, חבילות עם בנייה מקורית, סקריפטים של cron ופניות ל-API חיצוניים. הפלט — מפה: מה עולה בסביבות ומה נשאר בחוץ.
2. סכמת סביבה. מגדירים הרכב שירותים, כרכים למסד הנתונים ולקבצים שהועלו, רשת, משתני סביבה ודרך הזרקת סודות. את הסכמה מתאמים לפני שורת הקונפיגורציה הראשונה.
3. בניית תמונות. בונים תמונות ניתנות לשחזור של האפליקציה והשירותים, מטמיעים מטמון בשכבות ומקבעים את תמונות הבסיס לפי סכום ביקורת — אצל המהנדסים ובסביבת הבדיקות מתקבלת סביבה זהה.
4. דיבוג ומטמון. מפעילים Xdebug במצב לפי דרישה, מגדירים העברת פורטים, opcache ו-Redis. בודקים שהדיבאגר לא מאט בקשות רגילות.
5. תרחישי קבלה. מריצים תרחישים אמיתיים: התקנה מאפס, פריסת דאמפ של מסד הנתונים, מיגרציות, שליחת דואר, תקשורת עם 1С. סביבה שעוברת את הבדיקות האלה על מכונה נקייה נחשבת מוכנה.
6. מסירה לצוות. מוסרים מאגר עם קונפיגורציה, סט פקודות, נהל לעדכון תמונות הבסיס ודיון עם המפתחים והתמיכה.

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

מה נשאר במאגר ובתיעוד לאחר העבודה

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

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

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

מקרה בוחן: כיצד בפרויקט הפסיקו לתפוס פערי גרסאות

לפני: בנייה ידנית ופערי גרסאות

פרויקט על 1C-Bitrix נוהל בהרכב מפוזר: חלק מהמהנדסים עבדו באופן מקומי, חלק — על סביבת בדיקות משותפת. גרסאות PHP, MySQL ו-Redis במכונות היו שונות, ולכן התנהגות המטמון וההרחבות הייתה שונה מזו שבסביבת הבדיקות. מהנדס חדש העלה סביבה ידנית — עד שלוש שעות, ועוד אותו זמן הלך על השוואה עם הקונפיגורציה של העמיתים.

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

אחרי: סביבה כקוד

תיארנו את הסביבה בסט קונפיגורציות: תמונות עם גרסאות major מקובעות של PHP, MySQL ו-Redis, פרופיל Xdebug משותף ורשימת הרחבות אחידה. מצב הדיבוג מופעל במשתנה — באופן מקומי הדיבוג פעיל, בסביבת הבדיקות כבוי, ובכל זאת הבנייה אחת ויחידה.

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

מה לעשות אם שרת הבדיקות המשותף כבר פרוס

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

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

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

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

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

שאלות על הסביבה ששואלים לפני ההתחלה

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

מה עושים עם שירותים חיצוניים — תשלומים, תפוצות דיוור, תקשורת עם 1С?

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

האם דיבוג בתוך הבידוד בכלל אפשרי?

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

עבור 1C-Bitrix סכמה כזו נותנת התנהגות זהה של הקוד בכל המכונות: הפער "אצלי זה עובד" מפסיק להיות טיעון בדיון.

נדון במשימה: מה נדרש מכם כדי להתחיל בעבודה

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

• קישור למאגר ולענף שממנו אנחנו מחשבים: לפי המבנה רואים את שיטת הבנייה, האם כבר יש קונפיגורציות מוכנות או רק הוראות מקומיות ב-README.
• תיאור השירותים שצריכים לעלות יחד עם הפרויקט: שרת ווב, PHP, מסד נתונים, מטמון, תורים, חיפוש — עם ציון אילו מהם חיצוניים ואילו פורסים בקונטיינרים.
• רשימת הפרויקטים, אם במאגר אחד חיים כמה אתרים או מהדורות: מכך תלויה סכמת הכרכים המשותפים וסדר ההפעלה.
• דרישות גישה: מה צריך להיות נגיש מבחוץ, האם נדרשים מנהורים למסדי נתונים של בדיקות, האם יש מגבלות של רשת ארגונית ומדיניות אבטחה.
• רשימת תלויות מחוץ למנהל החבילות: הרחבות PHP, כלים בינאריים, מודולים לתקשורת עם 1С.
• דאמפ של מסד הנתונים או דוגמאות נתונים, אם הדיבוג מתבצע על תרחישים אמיתיים — שחזוריות חשובה יותר ממהירות ההפעלה הראשונה.
• איש קשר של המהנדס האחראי על הפרויקט: שיחה אחת מסירה יותר שאלות מהתכתבות.

תארו את המשימה בדרך הנוחה לכם — בקישור, במייל או בהודעה. נחזור עם הערכה ותוכנית עבודה: הרכב הסביבה, השלבים, לוחות הזמנים ומה שיידרש מצדכם בכל צעד.