קוד-רוויו Bitrix: היכן הסכמה סוטה מסביבת הייצור
סכמת הפרויקט נקייה כמעט תמיד מסביבת הייצור. בתיעוד הליבה מופרדת מהתבניות, מטפלי האירועים יושבים במודול, והשינויים עוברים דרך ניהול גרסאות — אבל בשרת הייצור חלק מהתיקונים הוכנסו ישירות לתבנית, חלק נעשו דרך ממשק הניהול, וחלק בסקריפט שמתחבר לבסיס הנתונים.
לכן קוד-רוויו Bitrix מתחיל לא בקריאת הנהלים, אלא בהשוואה: מה באמת רץ בסביבת הייצור ובמה זה שונה מהארכיטקטורה המתוארת.
הדבר הראשון שעולה בביקורת קוד הוא כפילויות וחפיפות. אירוע אחד נתפס על ידי שלושה מטפלים שנרשמו בזמנים שונים, ואת סדר הפעלתם איש לא בדק. לצידם — פעולות ידניות: עריכת מאפיין ישירות בממשק, הפעלת חישוב מחדש באופן ידני, עדכון מודול בלי הרצה על עותק. פעולות כאלה אינן משוחזרות בסביבת הבדיקות, וכל פיתוח נוסף הופך לניתוח של ההשלכות.
צווארי הבקבוק בביצועים כמעט אף פעם לא קשורים לאחסון "גרוע". אלה שאילתות בתוך לולאה על אלמנטים, מטמון שמתאפס בכל שינוי, סוכנים שתלויים בלוח הזמנים שנים, ואינדקסים שלא קיימים לשאילתות בפועל.
החוב הטכני של הפרויקט נמדד לא בהיקף הקוד אלא במחיר השינוי הבא: כמה קבצים צריך לגעת בהם כדי לשנות שדה אחד, וכמה צעדים ידניים מוטמעים בכך.
בהיעדר נוהל עדכונים, התיקונים מצטברים בשכבות, ואחרי כמה מהדורות איש כבר לא מעז לומר איזו גרסה של הליבה והמודולים מורכבת בסביבת הייצור. אנחנו מפרטים כיצד סוגרים זאת.
האפקט של הביקורת: מהירות תגובה, יציבות מהדורות
ביקורת ביצועים מסתיימת לא בדוח, אלא ברשימת בדיקות עם מספר לפני ואחרי: חציון זמן התגובה של האתר תחת עומס, מספר הפניות לבסיס הנתונים לעמוד, פגיעות במטמון, זמן בניית הממשק. את הרשימה סוגרים במדידה חוזרת על אותה סביבה ואותם תרחישים — אחרת אין מה להשוות.
| סוג הכשל | מה נראה בקוד | מה משתנה אחרי התיקונים |
|---|---|---|
| הידרדרות תחת עומס | שאילתות בתוך לולאה, המטמון של הקומפוננטה לא מחובר, שליפות בלי הגבלה | זמן התגובה מפסיק לגדול עם מספר המבקרים בו-זמנית |
| קריסות לא עקביות | אין פסקי זמן וטיפול בקריאות חיצוניות, שגיאות מושתקות | העמוד מחזיר תשובה או שגיאה מובנת במקום מסך ריק |
| עדכונים שנשברים | תיקונים בליבה, טלאים ידניים בתבניות, גרסאות ספריות משלכם | העדכון מותקן על עותק, והחזרה לאחור מחזירה את המצב הקודם |
| התפשטות הרשאות | לוגיקה בתבנית, כפילות, אין בדיקות | השינוי נסגר במערכת בדיקות, והמהדורה יוצאת באופן צפוי |
יציבות המהדורות נשענת על אותו קוד: אם התיקונים אינם נוגעים בליבה ומכוסים בבדיקות, המהדורה מפסיקה להיות פעולה כרוכה בסיכון. אנחנו עובדים על 1C-Bitrix ויודעים היכן הפלטפורמה מציעה פתרון מוכן, והיכן יש לתכנן אותו בעצמנו.
פורמטים של קוד-רוויו Bitrix: ביקורת חד-פעמית או בקרה שוטפת
את פורמט העבודה בוחרים לפי מצב בסיס הקוד ותדירות השינויים, ולא לפי גודל האתר. אם הפיתוחים מתבצעים אחת לרבעון, ולפני המהדורה מצטבר גוש גדול של תיקונים, די בביקורת חד-פעמית.
כאשר המהדורות יוצאות מדי שבוע ועל הקוד עובדים כמה אנשים, הדוח של בדיקה חד-פעמית מתיישן מהר יותר משהוא נכנס לעבודה — כאן דרוש נוהל קוד-רוויו קבוע. קונטור קריטי — אימות משתמשים, תשלומים, הרשאות גישה, החלפת נתונים עם 1C — נבדק בזרם נפרד ללא תלות בפורמט שנבחר.
| פורמט | מתי מתאים | מגבלות |
|---|---|---|
| ביקורת חד-פעמית | לפני שינוי גדול, הגירה או אחרי החלפת קבלן | חתך למועד מסוים: תיקונים אחרי הבדיקה אינם מכוסים |
| בקרת קוד שוטפת | מהדורות רציפות, כמה מפתחים באותו ענף | דרושים נוהל מוסכם וזמן לבדיקה בכל מחזור |
| ביקורת קונטור קריטי | תשלומים, אימות משתמשים, הרשאות גישה, החלפת נתונים עם 1C | אינו מכסה את שאר בסיס הקוד — החוב נשאר במודולים הסטנדרטיים |
| סקירת מורשת | היסטוריית תיקונים ארוכה, אין תיעוד מעודכן | מציג את החוב אך אינו מתקן אותו — דרושה תוכנית עבודה |
הפורמטים אינם שוללים זה את זה: ניתוח חד-פעמי מתווה את התוכנית, בקרה שוטפת שומרת על ביצועה, ובדיקת הקונטור הקריטי מכסה את האזורים שבהם המחיר של שגיאה שהוחמצה הוא הגבוה ביותר.
סדר העבודה: מאינבנטריזציה של הקוד ועד לנוהלים
ניתוח קוד מניב תוצאה רק אם הוא מתבצע לפי רצף קבוע: תחילה אינבנטריזציה של הקוד, אחר כך מפת תלויות, ורק לאחר מכן תיקונים. סדר הפוך הופך את הקוד-רוויו לרשימת הערות בלי סדרי עדיפויות — תיקון של מודול אחד שובר את המודול הסמוך, והסיבה להידרדרות נשארת בלתי מזוהה.
- אינבנטריזציה של הקוד. עוברים על עץ הפרויקט ומתעדים כל מה שנכתב ביד: מודולים וקומפוננטות משלכם, תבניות שנעקפו, מטפלי אירועים, משימות רקע, סקריפטים להחלפת נתונים. מפרידים בין קוד מותאם אישית לקוד הסטנדרטי — זה מיד מראה איזה חלק מהפרויקט חי מחוץ לעדכוני הליבה.
- מפת תלויות. בונים קשרים בין מודולים, קומפוננטות ושירותים חיצוניים: מי קורא למי, היכן הלוגיקה משוכפלת, היכן נקודת הכניסה אחת והיכן חמש. המפה קובעת את רדיוס השינויים — בלעדיה כל תיקון הוא הימור.
- ניתוח המודולים הקריטיים. הראשונים בתור הם אימות משתמשים והרשאות גישה, תשלומים, החלפת נתונים עם מערכת החשבונות, ייצוא וייבוא. בודקים שאילתות לבסיס הנתונים, עבודה עם מטמון, טיפול בשגיאות וקריאות חיצוניות.
- בדיקה על סביבת בדיקות. פורסים עותק של הפרויקט ומשחזרים את הבעיה לפני התיקון: אם ההתנהגות אינה חוזרת על עצמה, סימן שהסיבה אינה במקום שנדמה היה.
- טיפול בממצאים. את התיקונים משחררים במנות קטנות, כל אחת ניתנת להחזרה בנפרד — כך תקלה אינה חוסמת את שאר התוכנית.
- קבלת העבודה. הרצה חוזרת של התרחישים והשוואת מדידות לפני ואחרי: זמן תגובה, מספר שגיאות, שיעור העמודים תחת מטמון.
- העברת הנהלים. המפתחים מקבלים כללים לעדכונים, לעבודה עם מטמון ולתיקונים בתבניות — כדי שהמצב לא יחזור לאחור תוך חודשיים.
התוצאה של השלב היא לא רשימת הערות, אלא מפת קוד, סדרי עדיפויות והסכמות עבודה שלפיהן צוות הלקוח ממשיך לעבוד באופן עצמאי.
מקרה בוחן: איך הסרנו רגרסיה בעת עדכון מודולים
הלקוח — חנות מקוונת על 1C-Bitrix עם היסטוריה של תיקונים במודולים הסטנדרטיים: תהליך ביצוע ההזמנה וחישוב המשלוח פותחו ישירות בקוד של הקומפוננטות.
עדכוני האבטחה יצאו בקביעות, וכמעט כל עדכון שני שבר את תרחיש ביצוע ההזמנה — מהסל נעלמו הצעות מסחר (SKU), ואת השגיאה גילו רק לפי שיחות של הקונים. החזרה למהדורה הקודמת ארכה חצי יום עבודה: הקימו עותק, העבירו את התיקונים מחדש, והשוו ידנית בין התבניות.
ביקורת הקוד הראתה שהפיתוחים מעורבים בקוד הסטנדרטי, ולכן כל עדכון מוחק את הלוגיקה. הוצאנו את החישובים ואת כללי ביצוע ההזמנה למודולים ולעקיפות משלנו, והותרנו את הקבצים הסטנדרטיים ללא שינוי, וכן קבענו את חוזי ההחלפה עם מערכת החשבונות.
שלושה תרחישים מרכזיים — ביצוע ההזמנה, חישוב מחדש של הסל, ייצוא ההזמנות — כוסו בבדיקות אוטומטיות שמורצות לפני העברת המהדורה.
מדדים לפני ואחרי: שיעור הנתיבים המכוסים בבדיקות אוטומטיות עלה מכ-10% ל-85%, וההרצה עצמה אורכת דקות ואינה דורשת רשימת בדיקה ידנית. העדכון מותקן כעת קודם על עותק, עובר בדיקות ומועבר לסביבת הייצור במעבר אחד — כ-40 דקות במקום שש שעות.
במשך חצי שנה של תצפית — לא הייתה אף החזרה לאחור ואף תקלה לאחר עדכון. אם מהדורה אינה עוברת את הבדיקות, אנחנו חוזרים למהדורה הקודמת תוך דקות: ההתאוששות מכשל הפסיקה להיות פעולה נפרדת עם מיזוג תיקונים ידני והפכה לכפתור שגרתי בנוהל.
במה שונה ביקורת אבטחה מביקורת ביצועים?
שני הניתוחים עוברים על אותו קוד, אך במטרה שונה. ביקורת אבטחה מחפשת דרכים לעקוף את הבקרה: היכן נתונים מגיעים מהמשתמש בלי בדיקה, היכן הרשאות ניתנו באופן רחב מהנדרש, ומה בכלל נגיש מבחוץ.
ביקורת ביצועים מחשבת את המחיר של עיבוד בקשה: כמה עבודה המערכת עושה כדי להחזיר עמוד, ומה מהעבודה הזו אפשר לא לעשות כלל.
ביקורת אבטחה מתחילה בגבולות: תצורת השרת, הרשאות על קבצים ועל חשבון בסיס הנתונים, זמינות גיבויים, לוגים ופאנל הניהול. משם ממשיכים לקוד — טיפול בטפסים ובקבצים מועלים, עבודה עם הפעלות וטוקנים, סניטציה של הפלט, הפרדת הרשאות בין קבוצות משתמשים, עדכניות המודולים והספריות של צד שלישי. בפלט — תרחישים ניתנים לשחזור עם הערכת חומרה, ולא רשימה כללית של הערות.
ביקורת ביצועים נשענת על מדידות: זמן החזרת העמוד, מספר השאילתות עבורו, שליפות חוזרות בתוך לולאות, אינדקסים חסרים, שכבות מטמון ותדירות איפוסן, משימות רקע שמופעלות בכל פנייה.
תחילה מצלמים תמונה על תעבורת הייצור, אחר כך מתקנים את היקר ביותר — בדרך כלל מדובר בכמה תבניות וקומפוננטות שמייצרות את עיקר העומס.
התחומים נפגשים בתצורה: מטמון שמחזיר נתונים אישיים למשתמש הלא נכון, חשבון בסיס נתונים עם הרשאות עודפות, דיבאג פעיל בשרת הייצור. לכן סדר הבדיקות בפרויקט חי הוא כזה: אינבנטריזציה, אחר כך אבטחה — את הקריטי סוגרים מיד — ורק לאחריה ביצועים.
להאיץ צומת פתוח זה חסר טעם: העומס אותו עומס, רק לתוקף נוח יותר. מה לבחור: אם היו תקלות או חשדות — התחילו מאבטחה; אם מתלוננים על מהירות — מביצועים; אחרי שינויים גדולים בודקים את שני התחומים במעבר אחד על 1C-Bitrix.
ספקות טכניים בנוגע לניתוח הקוד ולהרשאות גישה
ביקורת קוד כמעט אף פעם לא מתחילה בפרויקט ריק: התעבורה זורמת, החלפות הנתונים עם 1C פועלות, ומהדורות יוצאות. לכן אנחנו בונים את הניתוח כך שלא יפריע לפרודקשן — קוראים את המאגר, את היסטוריית השינויים ואת תצורת הסביבה, ואת מדידות הביצועים מריצים על עותק של בסיס הנתונים.
אסור לעצור את הפרויקט — כיצד משלבים את הניתוח עם העבודה?
בסביבת הייצור אנחנו לא נוגעים: את סביבת הבדיקות מקימים מעותק של הקוד ומצילום של בסיס הנתונים, ואת הבדיקות עורכים עליה. את הממצאים מחלקים לפי חומרה — מפרצות אבטחה ועד הערות סגנון — כדי שהתיקונים ייצאו במנות ולא ישברו את מחזור המהדורות.
אפשר לבדוק רק חלק — למשל תשלומים או החלפת נתונים עם 1C?
כן. את הגבולות מסכמים מראש: מודול, קומפוננטה או תרחיש מסוים. ניתוח כזה מצביע על בעיות מקומיות ועל צווארי בקבוק, אך אינו מחליף הערכה מלאה של הארכיטקטורה — את זאת אנחנו מציינים במפורש במסקנות.
כיצד מועברות הרשאות הגישה וכיצד מבטלים אותן?
מספיקות הרשאות קריאה למאגר וגישה לעותק של בסיס הנתונים; הגדרות הייצור ונתונים אישיים אינם נדרשים. אנחנו עובדים מחשבון נפרד — אתם מבטלים אותו בפעולה אחת, ואת הסדר והמועד אנחנו מתעדים לפני ההתחלה.
מה לעשות עם עדכוני הליבה והתיקונים בתוכה?
אנחנו מסמנים את הקבצים שהשתנו בליבה ובקומפוננטות: לאחר עדכון תיקונים כאלה הולכים לאיבוד או מתנגשים. אנחנו מציעים להעביר את הפיתוחים למודולים ולתבניות משלנו, כדי שהעדכונים יותקנו שוב באופן שגרתי וצפוי.
נדון במשימה ונחזור עם תוכנית עבודה
כדי לדון במשימה באופן ענייני ולחזור עם הערכת לוחות זמנים ולא עם ניסוחים כלליים, די לנו במינימום: גישה למאגר במצב קריאה, סביבת בדיקות או עותק של הפרויקט שבו משוחזרת הבעיה, ותיאור התסמינים — אילו עמודים מחזירים שגיאה, היכן זמן התגובה עולה, ואילו מדורים בממשק הניהול מאטים.
אם מתנהלת היסטוריית שינויים, שלחו את הענף עם התיקונים האחרונים: לפיו רואים באיזה שלב הופיעה ההידרדרות, וזה מקצר באופן ניכר את הניתוח.
לפני ההתחלה אנחנו צריכים מכם:
- רשימה של האתרים והסביבות שנכללים במשימה;
- הרשאות גישה למאגר ולסביבת הבדיקות, או עותק של הקוד;
- תיאור התסמינים ומתי הם הופיעו;
- סדרי עדיפויות: אבטחה, ביצועים או ארכיטקטורה;
- מגבלות — מה אסור לשנות ומה כבר ניסיתם;
- איש קשר של מהנדס שיענה על שאלות הבהרה.
תוכנית העבודה מגיעה כמסמך: צווארי הבקבוק שנמצאו עם זיקה לקבצים ולמודולים, השלבים, לוחות הזמנים לכל שלב, והנקודות שבהן אנחנו מציגים תוצאה ביניים.
אופן מסירת התוצאה בסיום — אותו עיקרון של שקיפות: קוד שהשתנה עם הסברים, דוח על התיקונים, נוהל עדכון, מדריך למפתחים שלכם ופרוטוקול של בדיקה חוזרת על התרחישים המקוריים. תארו את המשימה — נחזור עם הערכה ותוכנית.