עבודה בgit

[טובה ראבי]

מעבר מ TFS ל Git בהחלט דורש שינוי תפיסה.

אני לא בטוחה שהבנתי במאה אחוז את שאלתך –

בכל רגע נתון, ישנה גרסה אחת בלבד בשרת הבדיקות.
כאשר את מסימת לפתח פיצ׳ר מסוים,
את מוציאה גרסה מהbranch שלך ומעלה אותה לשרת הבדיקות.
צות הבדיקות מבצע את התהליכים שלו ולאחר אישור מצידו, את יכולה למרג׳ג׳ את הbranch שלך אל master (או main, איך שקוראים לbranch המרכזי אצלכם)
מומלץ ביותר לבצע את המירג׳וג׳ בעזרת Pull Request (יש אפשרות לנעול את ה master/main מפני מירג׳וג׳ ישיר וכך להכריח הכנסת קוד אליו רק דרך Pull Requests)
אם יש לכם צורך לבדוק כמה פיצ׳רים ביחד בגרסה אחת,
אפשר ליצור branch מתוך main (כמדומני שמקובל לכנות אותו next) ולמרג׳ג׳ לתוכו את כל ה feature branches הדרושים,
ואז ליצור גרסה מתוך ה branch הזה ואותה להעלות לשרת הבדיקות.

אני מקוה שמצאת מענה לשאלתך.

[מלכי פלדמן]

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

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

בגדול – אם פיצ׳ר זו משימה בהיקף של ימים / שעות. אין סיבה לבדוק את הפיצ׳ר בנפרד וניתן לדחוף אותו לברנץ שמבוסס על מה שיש בגרסת production + הפיתוחים החדשים.

ניתן לקרוא לזה branch dev/develop וכו׳.

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

כשמחליטים שהגרסה מוכנה לבדיקות – אפשר להעביר לברנץ staging/qa ושם להעלות לסביבה לאנשי qa.

ממליצה לקרוא על השיטות השונות כמו git flow, trunk base ולהבין מה מתאים לכם.

[שרה ה]

ערב טוב,

בתור עובדת devops אני יכולה להגיד שישי חשיבות גבוה מאד לשיטות הניהול השונות של ה source-control.

השיטה הפופולרית ביותר היא כמו שטובה ציינה כך שיש master branch שבו יש את הגרסא שקיימת כרגע אצל הלקוח(הגרסא האחרונה ששוחררה), ב dev-nranch יהיה את הdelivery הבא , ובכל פעם שמתכנת רוצה לייצר פיצ׳ר נוסף הוא יפתח branch ישר מהdev.

אני ממליצה לך ליצור pipeline כך שיעשה את כל תהליך ה CI-CD בצורה אוטומטית לדוג׳ כאשר מפתח פותח PR ל dev אז מאחורי הקלעים מופעל הpipeline שיבנה את האפליקציה שלך (מומלץ עם דוקר או כלים רלוונטיים אחרים) לאחר מכן הוא יריץ את הunit-tests על הקוד שנוסף ואז הוא ירים סביבה וירטואלית עם האפליקציה שלך ויריץ עליה את הintegration-tests ובמידה ועברו הבדיקות בהצלחה אז ה pipeline אוטומטית ימרג׳ג׳ ל dev וימחוק את הbranch שעבדו עליו עם הפיצ׳ר החדש.

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