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

שאלה
-
תשובות
-
אלדד
מצב שבו פרוייקטים לא נטענים בפתרון, הוא לא מצב תקין, גם אם בעמדת הקצה שלך אתה עובד ומקמפל ללא הפרויקטים האלה.
TFS יכשיל בילד במצב כזה, ובצדק.
האפשרויות העומדות בפניך הן לתקן את הבעיה ולגרום לפרויקטים להיטען, או להסיר אותם מהפתרון, או לבנות פתרון חלופי ללא הפרוייקטים האלה.
אשמח לסייע לך בפתרון הבעיה הבסיסית - פרויקטים שלא נטענים
דן
- סומן כתשובה על-ידי Eldadcohen יום חמישי 22 נובמבר 2012 22:15
-
הי אלדד
לגבי פרויקטים שמוקפאים לאחר שכל תכולת הפיתוח שלהם שולבה בניהול התצורה - הם פשוט שם, לא בורחים לשום מקום.
כך שאני מניח שאתה מתכוון לדרך הניהול בפיתוחים לפרויקט מסויים והוקפאו באמצע, לפני ששולבו ב- main branch של הפרויקט בניהול התצורה.
התשובה - תלוי באיזה ענף פותחו. אם בתחילת העבודה על שינוי מסויים הקצית branch ייעודי לצורך הפיתוח הנ"ל, אז ב- branch הזה אתה מבצע check out check in מבלי להשפיע על ה- main branch של הפרויקט.
אם ביצעת שינויים (check out או כל pending change אחר) על ה- branch הראשי ואתה מעוניין להקפיא את העבודה, אתה יכול לבצע shelve pending changes ובעצם לגבות את כל השינויים שלך ל- TFS. מדובר בסוג של שמירה בצד אבך בתוך TFS. ה- shelve לא ישנה את ה- latest version. אתה תוכל להחזיר את ה- workspace שלך ל- latest version וכשתרצה "להפשיר" את הפיתוח המוקפא תבצע unshelve
ולסוגיית הבילדים
בילדים ב- TFS מאפשרים לך לקבל תוצר שמבוסס כולו מקוד שנלקח מה- TFS לצורך בדיקות או אספקת גרסה, מאפשרים לך לעקוב ולוודא גירסה תקינה (בילד שנכשל מדווח באמצעות bug work item, תוכל לקבל ALERT) ואפילו , אם תשתמש ב gated check in trigger, לבנות בילד שירוץ לפני ה- check in ויבטיח check in רק אם הבילד תקין
זאת אומרת שדווקא בפרוייקטים שעוברים שינויים תכופים אתה חייב בילדים שיעזרו לך לשמור על יציבות הקוד. אני מניח שהרתיעה שלך היא מעומס יתר של בילדים שיכבידו על הפיתוח. הייתי ממליץ לך להגדיר nightly build שירוץ כל לילה ויבנה את הפרויקטים, ולהגדיר שמירת מספר גרסאות קטן של תוצרי בילד (retention policy).
אם יש לך branch שהיציבות בו היא קריטית, שקול הגדרת gated check in build שימנע שילוב קוד שישבור את הבניה.דן
- סומן כתשובה על-ידי Eldadcohen יום ראשון 25 נובמבר 2012 19:28
כל התגובות
-
אלדד
מצב שבו פרוייקטים לא נטענים בפתרון, הוא לא מצב תקין, גם אם בעמדת הקצה שלך אתה עובד ומקמפל ללא הפרויקטים האלה.
TFS יכשיל בילד במצב כזה, ובצדק.
האפשרויות העומדות בפניך הן לתקן את הבעיה ולגרום לפרויקטים להיטען, או להסיר אותם מהפתרון, או לבנות פתרון חלופי ללא הפרוייקטים האלה.
אשמח לסייע לך בפתרון הבעיה הבסיסית - פרויקטים שלא נטענים
דן
- סומן כתשובה על-ידי Eldadcohen יום חמישי 22 נובמבר 2012 22:15
-
-
-
הי אלדד
לגבי פרויקטים שמוקפאים לאחר שכל תכולת הפיתוח שלהם שולבה בניהול התצורה - הם פשוט שם, לא בורחים לשום מקום.
כך שאני מניח שאתה מתכוון לדרך הניהול בפיתוחים לפרויקט מסויים והוקפאו באמצע, לפני ששולבו ב- main branch של הפרויקט בניהול התצורה.
התשובה - תלוי באיזה ענף פותחו. אם בתחילת העבודה על שינוי מסויים הקצית branch ייעודי לצורך הפיתוח הנ"ל, אז ב- branch הזה אתה מבצע check out check in מבלי להשפיע על ה- main branch של הפרויקט.
אם ביצעת שינויים (check out או כל pending change אחר) על ה- branch הראשי ואתה מעוניין להקפיא את העבודה, אתה יכול לבצע shelve pending changes ובעצם לגבות את כל השינויים שלך ל- TFS. מדובר בסוג של שמירה בצד אבך בתוך TFS. ה- shelve לא ישנה את ה- latest version. אתה תוכל להחזיר את ה- workspace שלך ל- latest version וכשתרצה "להפשיר" את הפיתוח המוקפא תבצע unshelve
ולסוגיית הבילדים
בילדים ב- TFS מאפשרים לך לקבל תוצר שמבוסס כולו מקוד שנלקח מה- TFS לצורך בדיקות או אספקת גרסה, מאפשרים לך לעקוב ולוודא גירסה תקינה (בילד שנכשל מדווח באמצעות bug work item, תוכל לקבל ALERT) ואפילו , אם תשתמש ב gated check in trigger, לבנות בילד שירוץ לפני ה- check in ויבטיח check in רק אם הבילד תקין
זאת אומרת שדווקא בפרוייקטים שעוברים שינויים תכופים אתה חייב בילדים שיעזרו לך לשמור על יציבות הקוד. אני מניח שהרתיעה שלך היא מעומס יתר של בילדים שיכבידו על הפיתוח. הייתי ממליץ לך להגדיר nightly build שירוץ כל לילה ויבנה את הפרויקטים, ולהגדיר שמירת מספר גרסאות קטן של תוצרי בילד (retention policy).
אם יש לך branch שהיציבות בו היא קריטית, שקול הגדרת gated check in build שימנע שילוב קוד שישבור את הבניה.דן
- סומן כתשובה על-ידי Eldadcohen יום ראשון 25 נובמבר 2012 19:28
-
-