הדף מתאר את הדרך מתיקון בקוד ועד שהוא ב-main של הריפו wizzo-products/wizzo50_core, ומשם ללקוחות בעדכון הגרסה. הוא נכתב למי שיש לו גישת כתיבה לריפו. מי שאין לו גישה פותח את השינוי כ-fork או כ-patch ומוסר אותו לצוות.
מידע
אין היום בדיקות אוטומטיות, CI או סקירה שנאכפת בכלי. מה שמתואר כאן הוא הנוהג בפועל, והאחריות על התוצאה היא של מי שמגיש. במפת הדרכים מפורט מה יתווסף.
המעגל בקצרה#
- מסתעפים מ-
mainהעדכני. - עובדים באתר מקומי שמצביע על הריפו (ראו זרימת עבודה).
- מעלים את
api/core/version.txtב-0.0.1. - פותחים Pull Request אל
main, ממזגים אותו כ-merge commit. - הגרסה החדשה זמינה לאתרי הלקוחות דרך עדכון גרסה (ראו עדכוני גרסה).
ענפים#
- ענף חדש לכל שינוי, מ-
main, לא ענף ארוך חיים. - שם קצר וברור, למשל
fix-<נושא>-<מספר משימה>אוfeature-<נושא>. בענפי הריפו הקיימים נפוצה גם התבניתchat-<מספר>-<נושא>. - לא עובדים ישירות על
main. וגם לא מכווניםwatch:apiאוpublish:apiלשרת ה-master מתוך ענף שלא נבדק (ראו האזהרה בזרימת עבודה). - לפני כל Pull Request ממזגים את
origin/mainלענף, כדי שלא תדרסו שינוי שנכנס בינתיים. מזגתם וקיבלתם התנגשות: פותרים בשמירה על שני הצדדים. אם לא ברור איך, שואלים את מי שכתב את הצד השני במקום לבחור צד שלם.
הודעות commit#
השורה הראשונה מתארת מה השתנה, והיא קצרה מספיק לקריאה ברשימת ההיסטוריה. הנוהג בריפו:
[TICKET-1234] core 5.0.116: תיאור קצר של מה שהשתנה ולמה- בתחילת השורה מזהה המשימה בסוגריים מרובעים.
- שינוי שיוצא ללקוחות נושא את מספר הגרסה החדש (
core 5.0.N). - בגוף ההודעה, כשצריך: ההקשר, הסיבה, ומה נבדק.
- לא מכניסים סודות להודעה (טוקנים, כתובות פנימיות, סיסמאות).
העלאת גרסה#
הגרסה נקראת מהקובץ api/core/version.txt (שורה אחת, למשל 5.0.115). אתרי לקוח מזהים שיש עדכון לפי השוואה בין הגרסה שלהם לגרסה שבקובץ הזה ב-master.
- כל PR שמשנה קוד ב-
api/core/או ב-api/js/מעלה אתversion.txtב-0.0.1. - שני ענפים שמעלים לאותו מספר יוצרים התנגשות: אחד מהם צריך לעבור למספר הבא אחרי המיזוג. זה קרה כבר (גרסאות 5.0.79 ו-5.0.110 נתפסו פעמיים). לכן ממזגים את
mainמיד לפני שבוחרים מספר, ובודקים מה המספר האחרון. - שינוי שאינו קוד ליבה (דפי תיעוד תחת
website/, מסמכים תחתdocs/) לא מעלה גרסה. - חוקי הגרסאות והערוצים (
latest,stable) מפורטים בניהול גרסאות.
שימו לב
version.txt הוא מה שמפעיל את חוויית העדכון בכל הצי. העלאת גרסה ל-main שלא נבדקה היא העלאה שכל אתר לקוח יציע להתקין.Pull Request#
- ה-PR נפתח אל
mainב-wizzo-products/wizzo50_core. - הכותרת כמו שורת ה-commit הראשונה.
- התיאור עונה על שלושה דברים: מה השתנה, למה, ואיך נבדק (ראו בדיקות).
- ממזגים עם merge commit (
gh pr merge <PR> --merge), לא squash ולא rebase, כדי שההיסטוריה של הענף תישמר. - PR נשאר פתוח רק כל עוד הוא נסקר. קוד שנשאר בענף פתוח לא קיים ל-
main, ומי שיסתעף מ-mainיעקוף אותו או ידרוס אותו.
מה נבדק לפני מיזוג#
כיום זו רשימה ידנית של מי שמגיש ושל מי שסוקר:
| בדיקה | איך |
|---|---|
| תחביר PHP תקין | php -l על כל קובץ ששונה (ראו בדיקות) |
| האתר המקומי עולה | טעינת עמוד ציבורי ועמוד ניהול בלי שגיאה |
core_ping עונה | הגרסה והמצב נכונים (ראו זרימת עבודה) |
| תקן הקוד | תקן קוד: DB, אבטחה, CSS לוגי |
| שינוי ב-JS או SCSS | נבדק בדפדפן, גם בכיוון RTL |
| תיעוד | אם השתנתה חתימה, מפתח הגדרה או שם טבלה, דף הרפרנס מעודכן באותו PR |
מה אסור להכניס#
- סודות: סיסמאות, מפתחות API, טוקנים, קובצי
.env. הם לא נכנסים לריפו גם "זמנית". נכנס סוד בטעות: ההיסטוריה של git שומרת אותו גם אחרי שמסירים אותו, ולכן מחליפים את הסוד עצמו (rotate) ומדווחים לצוות. - קבצים בינאריים כבדים: ZIP, גיבויים, סרטונים, ספריות מוכנות.
*.zipב-.gitignoreמסיבה זו. ספריות PHP נכנסות דרך Composer (ראו Composer). DB::insert: הפונקציה לא קיימת. ראו תקן קוד.- עריכה של ספריות צד שלישי בתוך
addons/אוlibraries/כדי לתקן להן באג. מתקנים על ידי עטיפה או החלפת הגרסה, ומתעדים. .cssשנוצר מ-SCSS. עורכים את.scss.- שינוי במבנה טבלאות ב-SQL שנכתב ביד בלי מנגנון ההגירה. שינויי סכימה נכנסים דרך מנגנון ה-
update_dbשל עדכון הגרסה (ראו עדכוני גרסה), לא כ-SQL שמריצים ידנית בכל אתר. - קוד שמפעיל שליחה אמיתית (מייל, SMS, push) או קריאה חיצונית עם תופעות לוואי בזמן טעינה או בבדיקה.