שירותי תיעוד מקיפים לפרויקטים של 1C-Bitrix

תיעוד לפרויקטים של 1C-Bitrix

המפתח עזב. המפתח החדש פותח את init.php עם 2000 שורות. הוא מגלה 47 מטפלי אירועים דרך AddEventHandler, שרשרת סוכנים ב-b_agent, ומודול מותאם אישית ללא הערה אחת. להבין את זה לוקח חודש. תיעוד הופך את החודש הזה לשלושה ימים. אנחנו יוצרים אותו עבור פרויקטים של 1C-Bitrix: מתרשימי ארכיטקטורה ועד הוראות שלב-אחר-שלב למנהל התוכן.

התיעוד מקצר את זמן קליטת מפתחים חדשים ב-60% — משלושה שבועות לשבוע אחד. בלעדיו, כל פרויקט שני חווה השבתה בעדכון הליבה או כשהחלפת 1C נכשלת. מעל 10 שנות פיתוח Bitrix ויותר מ-50 פרויקטים מתועדים מגבים את הסטנדרט שלנו. קבלו ייעוץ: אנו מעריכים את היקף העבודה תוך יום אחד.

למה תיעוד הוא קריטי?

מצבים ספציפיים שאנו רואים בכל פרויקט שני:

• עדכון ליבה — המפתח מריץ bitrix/tools/upgrade.php. העדכון דורס קבצים ששונו ב-/bitrix/components/bitrix/. אף אחד לא יודע אילו רכיבים שונו. האתר נופל. שחזור מגיבוי לוקח 4 שעות.
• החלפה עם 1C — הסוכן CCatalogImport::PreGenerateXML נכשל עם שגיאה. ההגדרה אינה סטנדרטית. מי שינה את מיפוי המאפיינים? ללא תיעוד — חצי יום של הנדסה לאחור.
• קבלן חדש — הצוות מקבל פרויקט עם 12 בלוקים בעלי עומס גבוה ללא תיאור, טבלאות מותאמות אישית b_custom_order_log ו-b_product_sync_history. מטרתם והקשרים שלהם לבלוקי מידע אינם מתועדים. זה מעכב את הקליטה בשבועיים.
• גידול צוות — כל מפתח חדש מבזבז שלושה שבועות במרדף אחרי "זה שיודע" במקום לפתוח את התיעוד ולעבוד.

מדריך התיעוד של Bitrix מציין שפרויקטים מתועדים היטב חווים 50% פחות תקלות קריטיות. תיעוד מובנה מקצר את זמן הניפוי ב-40% בהשוואה להערות אד-הוק. הוא גם חוסך ללקוחות בממוצע 8,000 דולר בשנה על קליטת מפתחים ומקצץ עלויות הקשורות להשבתה ב-3,000 דולר לכל תקרית.

איך לבנות תיעוד למפתחים?

בצעו את השלבים הבאים ליצירת תיעוד מקיף:

1. בדיקת הפרויקט — בדקו sale, catalog, קריאות iblock, רכיבים מותאמים אישית וקבצי ליבה ששונו.
2. מיפוי מבני נתונים — תיעוד כל בלוקי המידע, בלוקים בעלי עומס גבוה, טבלאות מותאמות אישית והקשרים ביניהם.
3. תיעוד קוד מותאם אישית — רכיבים, מודולים, אירועים, סוכנים ואינטגרציות.
4. כתיבת מדריכי משתמש — מדריכים שלב-אחר-שלב למנהלי תוכן ומנהלי מערכת.
5. הפקת תקנות תפעוליות — פריסה, גיבויים, עדכון ליבה ותגובה לתקלות.

תיעוד טכני

למפתחים ו-DevOps — המבנה הפנימי של הפרויקט: ארכיטקטורה:

• מודולי Bitrix בשימוש (main, urlrewrite.php, IBlock::TYPE_ID, PROPERTY_CODE, מותאמים אישית)
• נתיב בקשה: HTTP → nginx → b_hlblock_entity → רכיב → תבנית → תגובה
• תשתית שרת: תצורה, טופולוגיה, איזון עומסים

מבנה נתונים — החלק הקריטי ביותר:

• בלוקי מידע: סוגים (UF_*), סעיפים, מאפיינים (b_iblock_element), קשרים בין בלוקי מידע דרך מאפיין מסוג "קישור לאלמנטים"
• בלוקים בעלי עומס גבוה: טבלת b_sale_order, מטרת כל בלוק, מבנה שדות, שדות משתמש (b_catalog_group), אינדקסים
• טבלאות מותאמות אישית במסד הנתונים — למה נוצרו, DDL, קשרים עם b_catalog_store, b_sale_discount וטבלאות סטנדרטיות אחרות
• קטלוג מסחרי: סוגי מחירים (/local/components/), מחסנים (class.php), כללי סל (.parameters.php)

פיתוחים מותאמים אישית:

• רכיבים ב-/local/modules/ — מטרה, AddEventHandler, פרמטרי קלט (registerEventHandler), תבניות, תלויות
• מודולים ב-b_agent — API, אירועים, סקריפטי התקנה
• מטפלי אירועים — רשימה של כל bitrix//catalog עם תיאור: איזה אירוע, מה הוא עושה, קריטיות
• סוכנים (CCatalogImport) — לוח זמנים, פונקציונליות, אילו אסור לעצור (החלפת 1C, ניוזלטרים, ניקוי עגלה)
• קבצי ליבה ששונו — רשימה מלאה. בעדכון import.xml קבצים אלה יידרסו

אינטגרציות:

• החלפה עם 1C: הגדרות מודול sale.handlers → "החלפה עם 1C", פורמט CommerceML, לוח זמנים של sale.delivery, מיפוי מאפיינים, מלכודות (קידודים, טיימאאוטים, גודל DETAIL_PICTURE)
• מערכות תשלום: מטפלים ב-PROPERTY_GALLERY, מצבי פעולה (בדיקה/חי), כתובות callback
• שירותי משלוח: פרופילים ב-b_group, אלגוריתמי חישוב, מפתחות API
• CRM, שווקים מקוונים, APIs חיצוניים: נקודות קצה, מנגנוני אימות, תדירות סנכרון

הוראות משתמש

למנהלי תוכן ומנהלי מערכת: מדריך מנהל תוכן:

• ניהול קטלוג: יצירת אלמנטים של בלוק מידע, מילוי מאפיינים, עבודה עם סעיפים. אילו שדות חובה, אילו משפיעים על התצוגה באתר
• תמונות: גדלים מותרים (האם שינוי גודל אוטומטי מוגדר?), פורמטים, תהליך העלאה עבור b_sale_status ו-/local/
• מבצעים והנחות — איך להגדיר כלל סל ב"שיווק" → "כללי סל" מבלי לשבור את התמחור. בדיקה דרך הזמנת בדיקה

מדריך מנהל מערכת:

• משתמשים: קבוצות (b_iblock_element), זכויות גישה למודולים ובלוקי מידע
• עיבוד הזמנות: סטטוסים (b_sale_order), תשלום, החזרות
• גיבוי דרך "הגדרות" → "גיבוי" — עם הערה שלפרויקטים גדולים הגיבוי הסטנדרטי עשוי לא להספיק

פורמט:

• שלב-אחר-שלב עם מספור
• צילומי מסך עם הערות — חיצים, הדגשות, כיתובים
• שאלות נפוצות משאלות אמיתיות שנאספו במהלך ההדרכה
• הוראות וידאו לפעולות לא טריוויאליות (לפי בקשה)

תיעוד API

לפרויקטים עם REST API מותאם אישית — אנו מתארים את כל נקודות הקצה: מתודה, URL, מטרה, פרמטרים (חובה/רשות), פורמט תגובה. אימות: מנגנון קבלת טוקן, TTL, חידוש. הגבלת קצב: מגבלות, קודי HTTP בחריגה. דוגמאות — פקודות cURL עובדות, לא תיאורטיות. כלים: Swagger/OpenAPI (לפי תקן REST API) ו-Postman Collection לבדיקות.

תרשימי ארכיטקטורה

תרשים אחד מחליף 10 עמודים של טקסט. פורמטים: Draw.io, Mermaid (מנוהל בגיט), PlantUML.

• תשתית — שרתים, רשתות, מאזן עומסים, DB (master-slave), Redis, CDN. טופולוגיה פיזית ולוגית
• רכיבים — מודולי Bitrix, רכיבים מותאמים אישית ב-bitrix/updates/, שירותים חיצוניים, קשרים
• תרשים ER — טבלאות b_iblock_element, b_sale_order, בלוקים בעלי עומס גבוה, טבלאות מותאמות אישית. שדות, קשרים, אינדקסים. קריטי במיוחד לטבלאות מותאמות אישית שאינן בתיעוד Bitrix
• זרימות נתונים — איך מידע נע בין Bitrix, 1C, שווקים מקוונים, CRM, מערכות תשלום
• מפת אתר — מהו בלוק מידע, מהו עמוד סטטי, מהו סעיף מותאם אישית על רכיב

תקנות תפעוליות

פריסה:

• הוראות שלב-אחר-שלב לסטייג'ינג ופרודקשן
• רשימת בדיקה לאחר פריסה: בדיקת עמוד ראשי, קטלוג, תשלום, החלפת 1C
• הליך שחזור — איזה סימלינק להחליף, איזה גיבוי DB לשחזר

גיבויים:

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

עדכון ליבה:

• סטייג'ינג → בדיקות → פרודקשן. בדיוק בסדר הזה
• בדיקת תאימות של רכיבים מותאמים אישית וקבצי ליבה ששונו
• bitrix/updates/ — מה עודכן

תקלות:

• סיווג: אתר לא זמין / שגיאות 500 / החלפת 1C נשברה / האטה
• אנשי קשר ותחומי אחריות
• תבניות פעולה לכל סוג

מה כלול בעבודה

אנו מכינים חבילת תיעוד מלאה:

• תיעוד טכני המתאר ארכיטקטורה, מבנה נתונים, פיתוחים מותאמים אישית ואינטגרציות
• הוראות משתמש למנהלי תוכן ומנהלי מערכת
• תיעוד API בפורמט Swagger/OpenAPI עם אוסף Postman
• תרשימי ארכיטקטורה (תשתית, תרשימי ER, זרימות נתונים)
• תקנות תפעוליות (פריסה, גיבויים, עדכון ליבה, תקלות)
• מיקום ב-Confluence, GitBook, Notion או Wiki עם הגבלות גישה
• אחריות לדיוק — אנו מעדכנים את התיעוד עם כל שינוי משמעותי

לוחות זמנים

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