Team Foundation Server 2013 – קסטומיזציה מתקדמת באמצעות טיפול באירועים

30 באוגוסט 2014

אין תגובות

גרסת 2013 של ה- Team foundation Server כוללת סט של 3 תבניות עבודה עשירות מובנות וכן מאפשרת עריכה של ה- work items templates בעזרת קונפיגורציה ואף בעזרת פיתוח Custom controls. בפוסט זה נדון במקרים בהם כל היכולות שלעיל אינן מספיקות וברצוננו לפתח יכולות מורכבות במיוחד כמו למשל שינוי של מסך ה – iteration backlog או שיש צורך ב Performance גבוה (למשל, ביצוע אגרגציות או חיתוכי מידע בין work items) וכן שאנו מעוניינים לבצע את השינוי ברמת שרת ה- TFS ולהמנע מהצורך להפיץ dll –ים למשתמשי המערכת על כל שינוי.

הפתרון אותו נציג הוא למעשה הרחבת Team Foundation Server ע"י טיפול באירועים עם ISubscriber והוא מסתמך על מימוש של ממשק ISubscriber והתקנתו בשרת בתיקיית ה-Plugins.

מה נחוץ

Visual Studio שתומך באותה גרסת דוטנט שבה נבנתה גרסת ה-TFS שברשותכם.

במקום להקיף אותנו ב-API נוסף, הגדרת הבסיס היא ששינוים שאנחנו רוצים לבצע על ה-TFS כתגובה לאירועים מבוצעים דרך ה-Client API שאנחנו מכירים ומתועד היטב ב-MSDN. גישה זו נועדה לשמור על שלמות הפעולות, לדוגמא לא היינו רוצים ששינוי שדה על ל-WorkItem יתעלם מ-Rules שכרגע מופעלים עליו בגלל שהשתמשנו ב-API הלא נכון.

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

כיצד מתחילים

העתיקו אל מחשב הפיתוח שלכם את ה-API של צד השרת של ה-TFS ישר מהשרת המותקן. תוכלו למצוא את הקבצים הרלוונטיים בנתיב שבו התקנתם את המוצר בתיקיה

\Application Tier\Web Services\bin

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

פרטי המימוש

מימוש ISubscriber

  • Name – שם שמזהה את ההרחבה שלכם. שם המחלקה מספיק בהחלט.
  • Priority – תמיד `SubscriberPriority.Normal`, מעטים מאד המצבים שבהם יש הצדקה לשחק עם Execution Priority. תקפידו לכתוב את ההרחבות שלכם ללא תלויות אחת בשנייה ולא תהיה לכם אף בעיה.
  • SubscriberTypes – מגדיר ל-Team System אילו אירועים לשלוח לנו לפי ה-Type של האירוע. (רשימת האירועים שניתן לטפל בהם)
  • ProcessEvent – המתודה שנקראת כשאחד האירועים שאליו נרשמנו (לפי מה שאנחנו מחזירים ב-SubscriberTypes)

גוף המימוש (בתוך ProcessEvent)

  • requestContext – האובייקט מקביל לאובייקט ה-HttpContext שאנחנו מכירים. הוא מהווה נקודת גישה לשאר ה-API בעיקר ע"י קריאות ל-GetService.
  • notificationType – כל אירוע שניתן להירשם אליו הוא או Notification, או DecisionPoint. אירועי Notification לא מתייחסים לערכים שחוזרים מהמתודה והם משמשים רק כדי לידע אותנו שהאירוע קרה. אירועי DescisionPoint מתחברים לזרימה הלוגית של הטיפול באירוע כנקודת החלטה לגבי האם לבצע את הפעולה או לא.
  • notificationEventArgs – האובייקט יהיה מהטיפוס של האירוע שהגיע. הטיפוסים של האירועים הם אותם טיפוסים שאנחנו מחזירים ב-SubscriberTypes (לדוגמא WorkItemChangedEvent). בהחלט אפשר לטפל בכמה אירועים באותו מימוש פשוט ע"י בדיקת הטיפוס של הפרמטר.
  • שלושת הפרמטרים הנוספים הם ערכי החזר עבור אירועים מסוג DescisionPoint והם לא רלוונטים עבור אירועים מסוג Notification.
    • עבור אירועי Notification המתודה תמיד תחזיר EventNotificationStatus.ActionPermitted.
    • עבור אירועי DescisionPoint נחזיר EventNotificationStatus.ActionApproved או EventNotificationStatus.ActionDenied בהתאם ללוגיקה שלנו.

כיצד להתקין

ההתקנה מסתכמת בהעתקת ה-Dll עם המימוש שלכם לתיקייה

Application Tier\Web Services\bin\Plugins

בנתיב ההתקנה של שרת ה-TFS. אתם תראו הודעה ב-Event Log של ווינדוס שההרחבה שלכם נטענה.

כיצד לדבג

אתם יכולים לדבג בקלות את המימוש שלכם בעזרת יכולות ה-Remote Debugging של ה-Visual Studio.

תידרשו כמובן להתקין על המכונה את ה-Visual Studio Remote Tools. ה-Process שאתם רוצים לדבג הוא `w3wp.exe` שמארח את ה-TFS Application Tier. שזאת עוד סיבה טובה מאד לא לפתח על השרת המבצעי שלכם.

טיפים והמלצות לגבי המימוש

הקו המנחה הוא בנוגע למימוש של הלוגיקה עצמה הוא להשתמש ב-Client API שרלוונטי אליכם. אפשר לאתחל את ה-Client API בנוחות בעזרת הקטע הבא:

var locationService = requestContext.GetService<TeamFoundationLocationService>();

var uri = locationService.GetSelfReferenceUri(requestContext, locationService.GetDefaultAccessMapping(requestContext));

var collection = new TfsTeamProjectCollection(uri);

collection.EnsureAuthenticated();

בגלל שאנחנו מבצעים פעולות דרך ה-ClientAPI אתם תיתקלו לפעמים במצבים שהשינוי שאתם עושים מקפיץ בעצמו אירוע וגורם לרקורסיה. דרך אחת להתמודד עם הרקורסיה היא לבדוק האם המשתמש שגרם לאירוע הוא המשתמש של ה-Team System עצמו.

var workItemChangedArgs = notificationEventArgs as WorkItemChangedEvent;

var identityService = requestContext.GetService<IdentityService>();

var changerIdentity = identityService.ReadIdentities(

requestContext,

new List<IdentityDescriptor> {

IdentityHelper.CreateDescriptorFromSid(workItemChangedArgs.ChangerSid)

},

QueryMembership.Expanded,

null).Single();

if (!IdentityHelper.IsServiceIdentity(requestContext, changerIdentity)) {

// Do stuff….

}

  • הטיפוס `Microsoft.TeamFoundation.TFStringComparer` מכיל אובייקטי Comparer עבור טיפוסים של ה-TFS ותמיד כדאי להשתמש בו במידה וקיים שם Comparer לטיפוס שאתם מנסים לבדוק.
  • הטיפוס `Microsoft.TeamFoundation.Framework.Server.TeamFoundationApplicationCore` מספק לכם פונקציות logging שרושמות בין השאר גם ל-Event Log של ווינדוס. זה מאפשר לנו לנתר בעצמנו את ההרחבה וגם דואג ששגיאות מההרחבה יופיעו כשגיאות של ה-Team System במערכות ניתור.

 

Tamir Danielyהפוסט נכתב על ידי טמיר דניאלי, יועץ בכיר בתחום ה ALM, TFS ו DevOps בעל ניסיון של שנים רבות בהטמעת מערכי TFS מורכבים אצל לקוחות ממגון תחומי השוק.

חברת CodeValue מובילה בשירותי תוכנה וביצוע פרויקטים, באמצעות בניית הגשר בין טכנולוגיות חדשניות וצרכים עסקיים ספציפיים, תוך הענקת חוויית משתמש ברמה הגבוהה ביותר. חברת CodeValue מבצעת בהצלחה פרויקטיי פיתוח תוכנה במגוון פלטפורמות ומספקת ייעוץ תוכנה ופיתוח המותאם לצרכי הלקוח..חברת CodeValue מתמקדת במספר נושאים מרכזיים בעולם התוכנה, ביניהם ALM ו DevOps, מחשוב ענן, עולם ההתקנים הניידים, מענה אחוד וכולל לשווקי ה-UI/UX, פיתוח מערכות מידע ועוד. החברה מונה כיום כ-80 עובדים בהם מומחי טכנולוגיה בעלי ניסיון רב, הנחשבים מובילים בתחומם ומוכרים כסמכות מקצועית.

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *