רוב המשתמשים בכלי   MTM או בשמו המלא Microsoft Test and Lab Management הם הבודקים, אשר מכירים בעיקר את יכולות ביצוע הבדיקות של הכלי. פחות מכירים את יכולות ה – Lab של הכלי ובדיוק על נושא זה אני רוצה להרחיב בפוסט זה.

היכולות עיקריות של ה- Lab Management :

מעבדות פיזיות או כפי שהן מכונות ב– TFS 2012:  מעבדות סטנדרטיות.

מעבדות אילו מבוססות על מחשבים פיזיים או מכונות וירטואליות ב- VMware.

למעשה מה שעושים זה מגדירים מספר מחשבים ככמעבדה. החיסרון הוא ביכולות ה – Snapshot ברמת מעבדה ויכולות בדיקות ידניות מרוחקות על מחשבים אילו.

מעבדות וירטואליות.

מעבדות אילו מבוססות Hyper-V ונשלטות על ידי ה – SCVMM שמחובר ל – TFS, החיסרון בשיטה זו הוא הצורך בחומרה חזקה, היתרון מגיע ביכולות ה – Snapshot ברמת המעבדה. לדוגמא אני רוצה להכין מעבדה, “להקפיא” אותה ולאחר מכן להריץ בדיקות שילכלכו אותה, בסיום הבדיקה כול מה שאני צריך לעשות זה Revert למצב “המוקפא” ואני מוכן להרצת בדיקות מחדש ו\או נוספות.

בפוסט הזה נראה כיצד לייצר מעבדה סטנדרטית\פיזית, נשתמש בסוג מעבדה זו בעיקר להרצות של בדיקות אוטומטיות.

יש להתקין את ה – Test Controller כדי לבנות מעבדה פיזית.

הערה: יש להתקין את ה – Test Controller בלבד.

על מנת לייצר מעבדה סטנדרטית/פיזית יש לבצע את הצעדים הבאים:

צעד 1: לאחר התקנת ה – Test Controller יש לבצע קינפוג, נריץ את ה- Test Controller Configuration

צעד 2: נזין שם משתמש וסיסמה, משתמש זה יריץ את ה – Service של ה – Test Controller (חץ כחול)

צעד 3: נחבר את ה – Test Controller ל – Collection ב – TFS בו נשתמש (חצים אדומים)

צעד 4: נגדיר משתמש שיריץ את ה – Lab service במקרה הזה השתמשתי באותו שם משתמש (חצים ירוקים)

צעד 5: נלחץ על Apply Settings לסיום הקינפוג

צעד 6: לאחר סיום הקינפוג יש ללחוץ Close

צעד 7:  נפעיל את ה - MTM

צעד 8: נעבור ל – Lab Management, יש לשים לב שאנחנו עובדים על ה – Collection הנכון

צעד 9: נוודא שיש לנו Test Controller תקין, נעבור לטאב Controllers ונבדוק שה – Test Controller לא מסומן ב – X אדום

צעד 10:  נעבור לטאב Lab ונלחץ על New ליצירת מעבדה חדשה

צעד 11: נבחר Standard environment, נזין שם למעבדה ונעבור לטאב Machines

צעד 12: נלחץ על Add machine להוספת מחשבים חדשים

צעד 13: נזין את שם המחשב ונבחר לו Role מהרשימה, כמו כן נזין לו שם משתמש שיש לו הרשאות על המחשב

שים לב: תהליך זה יתקין ויקנפג Test Agent על מחשב זה, במידה ויש כבר Test Agent המחובר ל – Test Controller ניתן לבחור מרשימה קיימת של מחשבים, לינק אל הרשימה תופיע בתחתית החלון.

צעד 14: נעבור ל – Advanced ונסמן את Configure environment to run UI tests

צעד 15: נבחר על איזה מחשב ירוצו בדיקות ה – GUI, נזין שם משתמש וסיסמה בעלי הרשאות ונעבור לטאב Verification

צעד 16: נלחץ על Verify ונוודא שהכול ירוק

צעד 17: כעת המערכת מתקינה ומקנפגת את ה – Test Agent על המחשב שהזנו קודם

שימו לב שבמהלך ההתקנה המערכת תבצע Restart לבד וגם תבצע Log-in לבד.

זה הכול, יש לכם מעבדה עובדת. תהנו!

יש לכם שאלות בנושא Visual Studio ו-ALM? כנסו לפורום שלנו בעברית.

הפוסט נכתב על ידי ערן רוסו , מנהל חטיבת ה - ALM & DevOps בחברת TOP Q, המובילה במגוון פתרונות אוטומציה לבדיקת מוצרי תוכנה, ALM ו – DevOps בטכנולוגיה מתקדמת, המיועדים לסביבות מחשוב מרובות מערכות, קונפיגורציות ותהליכים בארגונים בינוניים וגדולים. כנסו לבלוג של ערן וקראו על עוד נושאים מעולם ה- ALM וה- TFS ואתם מוזמנים גם לקבוצת הלינקדאין.

על פי המסורת, רוב חברות ההיי-טק בישראל משתמשות בטכנולוגיות של מיקרוסופט. ומסיבה זו, הבחירה הטבעית למערכות ניהול תצורה גם היא מגיעה מאותו הבית. בימים ההם, שרבים כבר הצליחו לשכוח זו הייתה תוכנת Source Safe. מכיוון שיכולותיה לא התאימו לקבוצות גדולות והשוק דרש פתרונות יותר מתוחכמים, לפני מספר שנים מיקרוסופט השיקה פתרון חדש ושמו – Team Foundation Server.

המערכת גדלה, השתפרה פלאים ונכון להיום היא אחת הפתרונות הנפוצים והנוחים לניהול תצורה עבור החברות המסתמכות יום-יום על מיקרוסופט לכל צרכי הפיתוח. פרט חשוב לזכור כאן, הוא ש- TFS, לעומת רוב הכלים האחרים שנמצאים היום בשוק, הוא לא רק כלי ניהול תצורה, אלא גם מערכת לניהול משימות, build server, כולל מודולים להרצת בדיקות אוטומטיות, ועוד לא מעט דברים אחרים, כלומר, נותן פתרון ALM  (ניהול מחזור החיים של פרוייקט תוכנה) מלא מקצה לקצה. ובזאת נמצא הכוח העיקרי של TFS.

מדוע לעתים נדרש ניהול תצורה מבוזר

לעומת כל היתרונות שיש ל-TFS, קיימים גם דברים שמערכת זו לא תוכננה להתמודד איתם. אחד הדברים הוא עצם העובדה ש-TFS מבוססת שרת מרכזי ולכן מפתח לא מסוגל לעבוד בצורה חלקה כאשר אין תקשורת קבועה עם השרת. לצוותים מסוימים, שמפתחיהם לא נמצאים באותו אזור גאוגראפי או שמורכבים בחלקם מקבלני משנה - כאשר מחלקת IT, או שלא מעוניינת או שלא מסוגלת לתת פתרון הולם לחשיפת השרת לעולם מחוץ לפיירוול – זו מגבלה אשר, עלולה לגרום לפגיעה בפרודוקטיביות. נוסף על כך, רבים מאיתנו נמצאים לא מעט זמן בנסיעות שבמהלכן ערוצי התקשורת פשוט לא זמינים. גרסת ה-2012 של TFS פותרת חלק מהבעיה ע"י יכולת בשם Local Workspace שהיא תוספת נחמדה מאוד – המפתח מסוגל לערוך את הקוד שלו בלי תקשורת לשרת וכשהתקשורת חוזרת, לעשות check-in כאילו הניתוק לא קרה אף פעם. החיסרון הוא שבזמן שלא הייתה תקשורת עם השרת, השינויים כבר יכלו לגדול למימדים לא קטנים, ובמקום להיות קשורים לפיצ'ר ספציפי אחד, הם נהיים שינויים חובקי-עולם, בלי היסטוריה ואפשרות להבין מה שייך לאן.

כתוצאה, התמונה התקינה הבאה:

הופכת להיות משהו אחר, בלי אפשרות לשייך את השינויים למשימה מסויימת, גם אם המפתח זוכר מה התקוון בכל שינוי ושינוי:

הפתרון לבעיות דומות הוא עבודה בשיטת ניהול תצורה מבוזר (DVCS) ומסוף חודש ינואר, שנת 2013, TFS תומך גם באפשרות זו.

Git כלי מצוין, אך לניהול תצורה בלבד

כלי לניהול תצורה מבוזר הנפוץ ביותר בעולם הוא, ככל הנראה, git. כמות הפרוייקטים שמשתמשים בו פשוט עצומה: Linux kernel (שעבורו git נכתב), VLC, Ruby on Rails, Android ועוד רבים. אתרי קוד פתוח כמו GitHub ו-CodePlex נותנים שירותי הוסטינג ב-git. משתמשים בו אפילו לצרכי deployment.

האם זה לא מספיק בשביל להתחיל להשתמש בכלי הזה?

המציאות אומרת שלא. ושתי הסיבות העיקריות הן:

1. git נבנה ככלי command line עם גישה שונה לגמרי מהסבב של check-out – check-in הרגיל, ולמפתח שמרגיש נוח לעבוד מתוך הסביבה החמימה של Visual Studio די קשה לעשות את המעבר ולהתחיל להשתמש במשהו כל כך שונה, גם בעזרת כלים כמו Git Extensions שנותנים רמת אינטגרציה מסוימת.

2. גם לאחר ההתגברות על הבעיה הראשונה לעיל, די קשה לאמץ git בתוך חברה, במיוחד ארגון המתבסס על מוצרים של מיקרוסופט, מפני ש-git עושה טוב ואפילו טוב מאוד רק את החלק של ניהול תצורה, וזה ממש לא מספיק לכל חברה שמבקשת יותר (רמז – TFS). לכן קיימים פתרונות כמו git-tfs ו- git-tf, אבל הן לוקחות אותנו שוב לעולם ה-command line המאוד זר למפתח העכשווי הממוצע.

מיקרוסופט מחבקת את Git

לאור הביקוש הגדול, במיקרוסופט החליטו לאמץ את הבן-דוד החורג של TFS ולתמוך בו בצורה מלאה בגרסאות הבאות של TFS 2012. נכון להיום, התמיכה ניתנת בגרסת 2012.2 CTP של Visual Studio, שנמצאת כאן. לאחר התקנת העדכון, התוסף לעבודה עם git הופך לנגיש בגלריית ההרחבות של Visual Studio תחת השם Visual Studio Tools for Git:

מרגע שהתוסף מותקן, נוכל לפתוח כל פרוייקט של Visual Studio שממופה לרפוזיטורי של git ולראות שאפשרויות ה-git התווספו ללשונית ה-Team Explorer:

מה שמעניין אותנו כעת הוא לפתוח פרוייקט חדש. אז נכון, GitHub הוא אופצייה לגיטימית לגמרי, אבל הוא לא נותן את היכולות של TFS (לפחות לא את הרוב). לכן נשתמש ב-TFS, ולא סתם ב-TFS, אלא בגרסת הענן שלו. נכון להיום, זו גם האופצייה היחידה להשתמש באינטגרציה המלאה בין הכלים. מיקרוסופט מבטיחה כי בעתיד הלא רחוק קונפיגורציה כזו תיתמך גם בגרסת ההתקנה של Visual Studio Team Foundation Server.

ללכלך את הידיים

הפתיחה של פרויקט חדש ב-Team Foundation Service היא מחוץ לסקופ של מאמר זה, אך כל המידע הדרוש נמצא באתר שלו. השוני היחיד הוא שבזמן הוספת הפרוייקט צריכים לציין את git כ-version control.

לאחר יצירת פרוייקט חדש נרצה, כמובן, להגדיר משימות. ומיד נתחיל בראשונה מהן:

שהיא יצירת פרויקט.

מכאן נעבור ל-Visual Studio ונחברו לפרוייקט ב-TFS:

בלחיצה על OK יתבצע חיבור לענן וחלון האוטוריזציה יבקש להכניס את שם המשתמש והסיסמא. לאחר הכנסתם וזיהוי מוצלח, השרת יופיע ברשימת שרתי ה-TFS ותתאפשר האופציה להתחבר לפרוייקט:

זה הזמן ללחוץ על Clone:

ולספק את מיקום הפרוייקט החדש:

במצב של פרוייקט קיים הפקודה מייצרת העתק מקומי מלא של הרפוזיטורי בענן. כתוצאה מהפעלת הפקודה על רפוזיטורי ריק, העתקו יופיע על הדיסק המקומי. כלומר, ההתנהגות המוכרת לנו מ-git הרגיל, זה כמובן לא מפתיע כי המימוש של TFS git הוא... ה-git המוכר לנו.

כעת נוכל ליצור פרוייקט חדש בספריה זו. בחרתי את האופציה המתוחכמת ביותר – console application, שבעתיד, לאחר מאמצים רבים, תוכל להדפיס ללא שגיאות את השורה "It works!". הפרוייקט יווצר בספריה הקיימת של git:

מיד עם היווצרות הפרוייקט, השינויים הניתנים להכנסה לרפוזיטורי יופיעו בתוך ה-solution explorer:

ואם נלחץ על ה-Commit… מתוך context menu של solution, נעבור למסך ה-Team Foundation עם הרשימה של השינויים:

בנקודה זו חייבים להבין משהו מאוד חשוב: ההתנהגות של git תחת שליטה של Visual Studio היא לא ההתנהגות הרגילה שלו. למה? מכיוון ש-git מוסיף לרשימה לעיל לא רק את הקבצים המופיעים ב-Included Changes, אלא גם את כל אלה:

הדבר היחיד ש-git מכיר על הפרוייקט, הוא המיקום שלו. כל הקבצים, שלא נמצאים כבר בתוך הבסיס נתונים שלו, הם שינויים להכנסה מבחינתו. ה-Visual Studio מכיר את מבנה הפרוייקט ודואג להכניס רק את הקבצים הרלוונטיים. בכדי לא לשבור את ההתנהגות הטבעית, וזה חשוב בכדי לתמוך באנשים שיעבדו עם git לא דרך Visual Studio, נצטרך להכניס קובץ קונפיגורציה בשם .gitignore. לשם כך נלך ל- Team Explorer – Home à Settings à Git Settings ונלחץ על Add בתוך Repository Settings à Ignore File:

כתוצאה, יופיע הקובץ שמתאים לרוב הפרוייקטים הנוצרים ע"י Visual Studio, הנמצא בספריית השורש של הרפוזיטורי. בנוסף, נראה שרשימת ה-Untracked Files הצטמצמה פלאים:

את שני הקבצים נרצה להוסיף לרשימה שלנו על מנת להכניס אותם לרפוזיטורי.

בדומה ל-.gitignore נרצה להוסיף ובמידת הצורך לערוך את קובץ ה-.gitattributes עבור הפרויקט.

דבר נוסף שנרצה לשנות הוא פרטי המשתמש. הקונפיגורציה נמצאת ב-Global settings:

השינוי כמובן רלוונטי רק לאנשים שתמיד יעבדו תחת אותם פרטי הזיהוי. במקרה ומישהו משתתתף במספר פרויקטים ופרטי הזיהוי, כמו שם משתמש או כתובת הדואר האלקטרוני, שונים מאחד לשני, הגדרת פרטים אלה חייבת להיעשות בצורה ידנית (בשלב זה) בתוך קובץ config בספריה המוסתרת .git בתוך הרפוזיטורי:

מה שנשאר הוא לכתוב הערה מתאימה ולהכניס את השינויים לרפוזיטורי. נרצה גם לשייך את השינוי ל-work item ספציפי. לשם כך נציין את מספר ה-item בתוך ההערה:

נותר רק ללחוץ על כפתור ה-commit והשינוי ייכנס לרפוזיטורי המקומי.

וכאשר נלחץ על View Commits, נראה את השינוי בהיסטוריה:

כמובן, השינוי עוד לא הופץ לרפוזיטורי המרכזי. בכדי לעשות זאת, נרצה לעשות Push, אבל קודם נלחץ על Fetch מתחת לכותרת Incoming Commits בכדי לוודא שאין שינויים ברפוזיטורי המרכזי ביחס לרפוזיטורי מקומי. במקרה זה לא מצפות לנו הפתעות ובביטחה נוכל להפיץ את השינויים.

לאחר הפעולה נוכל ללכת ל-web interface ולראות שהשינוי מופיע כעת גם בשרת:

וה-task מוכן לסגירה.

קדימה, להסתעף!

הגיע הזמן להתקדם ולממש את הפונקציונליות העיקרית של הפרויקט. לשם כך נשתמש ביכולת הבולטת של git – branching. מכיוון שיצירת branch היא זולה מאוד ולא משפיעה כלל על גרסת הקוד בשרת, נרצה להשתמש ביכולת זו עבור כל אחד ואחד מה-features אותם נפתח במהלך הפרויקט. Visual Studio מאפשר לגשת לפעולה מתוך הלשונית ההראשית של Team Explorer:

בלחיצה על Branches נגיע לחלון בו נגיש הקישור New Branch המאפשרת לבצע את הפעולה:

וכתוצאה מאישור ברירות המחדל ולחיצה על Create Branch ניצור branch חדש ומיד נעבור אליו. ה-feature לא היה פשוט, אך בסופו של דבר מומש בהצלחה:

פעולת הכנסת השינויים לרפוזיטורי כבר מוכרת, רק שהפעם היא תתבצע ב-branch נפרד:

פעולת ההפצה (Push) תמיד תתבצע מה-branch הראשי, master, לכן נמזג את השינויים בחזרה. הפעולה נגישה מתוך הלשונית Branches:

ולאחר המיזוג נוכל לבצע את ההפצה בצורה הרגילה.

לסיכום

ניסיתי כאן בקצרה להציג את היכולות שמספקת אינטגרציית ה-git לתוך האקו-סיסטם של מיקרוסופט. לא נגעתי בתסריטים יותר מתקדמים של מיזוג, בפתרון ההתנגשויות, פעולות נוספות של git, אבל גם לא שמתי כמטרה לכתוב טיוטוריאל ל-git. למרות זאת אני מקווה שכל מי שקורא את המאמר יקבל טעימה מהפונקציונליות החדשה והטעם יהיה טוב. למרות שהכלי נמצא בשלב ה-CTP ולא כל האופציות חשופות דרך הממשק הוויזואלי, הוא מרגיש יציב ומוכן לשימוש. כל מי שחיכה לקבל שילוב טבעי של git בתוך Visual Studio – ההמתנה נגמרה. והפרט החשוב הוא שהשילוב לא נגמר בעוד source provider ל-Visual Studio, יש כאן איחוד של כלי תצורה DVCS נפלא ומערכת ALM המובילה בשוק. האם מישהו יוכל לבקש יותר מזה?

שאלות נוספות בנושא VIsual Studio ו- Git? כנסו לפורום ALM שלנו בעברית!

הפוסט נכתב ע”י מיכאל דונכין, יועץ בכיר בחברת CodeValue ומומחה בטכנולוגיות מיקרוסופט: #C, ++C, WPF, MEF ועוד. מיכאל הוא בעל וותק ונסיון רב בפיתוח כלים ושירותים לחברות שונות בטכנולוגיות מיקרוסופט ואחרות.
חברת CodeValue מתמחה ביישום והטמעת פתרונות תוכנה מבוססי מיקרוסופט ובכללן פתרונות מבוססי Azure, הענן של מיקרוסופט. החברה מונה כיום כ-60 עובדים בהם מומחי טכנולוגיה בעלי ניסיון רב , הנחשבים מובילים בתחומם ומוכרים כסמכות מקצועית, בקהיליית פיתוח התוכנה.

בעדכון האחרון לכלי הפיתוח Visual Studio 2012 Update 2 שוחררו מספר פיצ’רים חדשים לבודקי תוכנה. בנוסף לשיפור ב- Microsoft Test Manager, העדכון מכיל יכולות ניהול חדשות מבוססות דפדפן שכתבנו עליהם פוסט לא מזמן.

כעת לבודקים יש אפשרות לבצע תסריטי בדיקה שונים כמו למשל לבדוק non-windows apps ולבצע בדיקות ללא התקנת כלים ייעודים במחשב היעד.

ה- test hub החדש שהוצג מאפשר גם לכל חברי צוות הפיתוח לראות ולערוך test cases וכמובן מאפשר למנהלים לעקוב אחר כל צעדי הבדיקה.

וידאו חדש באתר Channel 9 נותן הצצה ליכולות החדשות:

בודקים תוכנה באמצעות הכלים של מיקרוסופט? כנסו לפורום בעברית שלנו אם יש לכם שאלות בנושא!

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

בפוסט הקודם התחלנו לדבר על השינויים הקטנים שעושים הבדל גדול בין גרסת MTM 2010 ל– MTM 2012. בפוסט הזה אני רוצה להרחיב על שכלול מנגנון ה- Exploratory Testing שהוצג ב- MTM 2010 ופירטתי עליו בפוסט הזה.

החידושים בפיצ’ר ה- Exploratory Testing ב- MTM 2012

מספר חידושים ושכלולים בהקשר למנגנון זה בגרסת MTM החדשה:

1. היכולת להריץ Exploratory Testing הפכה להיות זמינה הרבה יותר
   
2. היכולת לתחקר ריצות מסוג זה לא הייתה קיימת כלל קודם.
   
3. נעשו שינויים ב – Test Runner.
   למעשה יצרו ל – Test Runner תצורת הרצה שונה עבור ה – Exploratory Testing, הוסיפו את היכולת לקשר ריצה מסוג זה ל – Requirement/User Story/Product Backlog, ויצרו דיווח באג המכיל Screenshots של כול התהליך.
   
4. היכולת ליצור Test case מיתוך Exploratory Test היא תוספת שחוסכת זמן רב לבודקים בכתיבת Test Cases.

בואו נראה כיצד משתמשים ב- Exploratory Testing

אלו הם הצעדים הנדרשים:

1. נריץ Exploratory Test עבור User Story
   
2. נפתח באג
   
3. נייצר Test Case מהריצה ונראה איך הכול מתחבר

צעד 1: הרץ Microsoft Test Manager

צעד 2: הקלק על טאב Test

צעד 3: בחר Do Exploratory Testing מהתפריט המשני של Test

צעד 4: בחר User Story/Requirement/Product Backlog Item מהרשימה או לחץ Explore עבור בדיקה כללית (אני מראה את האפשרות הראשונה)

צעד 5: לחץ Explore work item

צעד 6: לחץ Start ב – Test Runner שנפתח

ניתן בכול שלב בהרצה ליצור באג, ליצור Test Case וליצור screenshot (למרות שאני חושב שעם הווידאו הפונקציה הזאת מיותרת)

צעד 7: אנחנו ניצור כעת באג, לחץ Create bug

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

כמו כן נוצר וידאו עבור כול הבדיקה, בנוסף אני מקבל גם את ה – System Information, Action Log, Event Log ועוד. תלוי מה הגדרתי לאיסוף.

צעד 8: אנחנו נמלא Title וחשוב מאוד גם Severity (אם אני איש הבדיקות) ונקליק על Save and create test, כדי לייצר Test Case שישחזר את הבאג בהמשך.

באופן אוטומטי נוצרים לי הצעדים של ה – Test Case אני צריך כמובן להשלים את ה – Expected Results

צעד 9: הזן Title ושמור.

ניתן לראות שנוספו לי ל – Exploratory Test באג אחד ו – Test Case אחד, גם בשורת ההערות, אני גם הוספתי שורה לשדה ההערות.

זה מחלון תוצאות הרצת הבדיקה.

אם נעבור ל – Test Case נוכל לראות שהוא מקושר ל – Bug ול – User Story כמו כן מצורפים לו תוצאות ההרצה.

סיכום

ניתן לראות שהחיים של הבודק הופכים להיות קלים יותר. אם נבדוק, כנראה שנמצא שאף בודק לא ממש אוהב לכתוב צעדי בדיקה. על ידי שימוש במנגון ה-  Exploratory Test ניתן לחסוך חלק מהתהליך הידני.

תיהנו!

יש לכם שאלות בנושא Visual Studio ו-ALM? כנסו לפורום שלנו בעברית.

הפוסט נכתב על ידי ערן רוסו , מנהל חטיבת ה - ALM & DevOps בחברת TOP Q, המובילה במגוון פתרונות אוטומציה לבדיקת מוצרי תוכנה, ALM ו – DevOps בטכנולוגיה מתקדמת, המיועדים לסביבות מחשוב מרובות מערכות, קונפיגורציות ותהליכים בארגונים בינוניים וגדולים. כנסו לבלוג של ערן וקראו על עוד נושאים מעולם ה- ALM וה- TFS ואתם מוזמנים גם לקבוצת הלינקדאין.

לטובת למי שלא מכיר את ה- MTM,  מדובר בכלי לבודקים המכונה גם Test Professional. כלי זה הוצג לראשונה בגרסת TFS 2012. ניתן לקרוא עוד בנושא כאן.

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

מה שכן שמיקרוסופט שינתה הם כל הדברים שמאוד אבל מאוד היו חסרים ב – MTM 2010.

בסדרת פוסטים זאת אציין חלק מן השינויים הללו. בפוסט זה אני אתמקד ב- 3 שינויים בנוגע לצעדי הבדיקה:  Rich Text, תמיכה בעברית והיכולת לבצע Resize לחלון הצעדים.

Resize לחלון הצעדים

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

ב- MTM 2012 ניתן לראות שלמרות שיש  10 צעדי בדיקה – אנו רואים רק 4:

בגרסת MTM 2012 לעומת זאת,  ניתן להגדיל את חלון הצעדים ולראות את כולם:

יכולות Rich Text בצעדי הבדיקה

גם נקודה זאת היתה כואבת בחסרונה לבודקים רבים וגם כאן החוסר הושלם בכלים חיצוניים.

בדוגמא למטה  ניתן לראות שב – MTM 2012 החוסר הושלם וכעת ניתן לשנות את הגודל, הצבע, הפונט, וכו’:

כמו כן ניתן לראות שהתמיכה היא מלאה וגם בחלון הריצה אנחנו מקבלים את התמיכה ב – Rich text:

תמיכה בעברית בתוך צעדי הבדיקה

החוסר בתמיכה בעברית פגע בחברות רבות שנאלצו לעקוף את החוסר בכל מיני דרכים כמו לשנות את הכיוון של הכלי כולו על חשבון קבלת כלי מעוות ועוד דרכים יצירתית. עכשיו ב – MTM 2012 התמיכה בעברית היא Out of the box.

ניתן לראות גם כאן שהתמיכה בעברית ממשיכה גם ל – Test Runner:

עוד על השינויים ב – MTM 2012 – בחלק השני של הפוסט!

יש לכם שאלות בנושא Visual Studio ו-ALM? כנסו לפורום שלנו בעברית.

הפוסט נכתב על ידי ערן רוסו , מנהל חטיבת ה - ALM & DevOps בחברת TOP Q, המובילה במגוון פתרונות אוטומציה לבדיקת מוצרי תוכנה, ALM ו – DevOps בטכנולוגיה מתקדמת, המיועדים לסביבות מחשוב מרובות מערכות, קונפיגורציות ותהליכים בארגונים בינוניים וגדולים. כנסו לבלוג של ערן וקראו על עוד נושאים מעולם ה- ALM וה- TFS ואתם מוזמנים גם לקבוצת הלינקדאין.

חוץ מכלי הניהול הרגיל (TFS administration console), יצא בגרסה האחרונה של TFS 2012 כלי אדמיניסטרטיבי חדש.

הכלי החדש מאפשר ניתוח תמונת מצב של המערכת מבחינת עומסים וביצועים. הכלי מציג זאת משני אספקטים שונים Activity Log ו- Job Monitoring.

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

כחלק מהמאמצים של מיקרוסופט להעביר את כל כלי המנהלה לאזור ה-Web (כדוגמת ניהול המשתמשים, ניהול ה-alerts ועוד) , גם כלי זה נגיש באמצעות הדפדפן.

כתובת הכלי: http://<your TFS server>:8080/tfs/_oi

בטבלה ניתן לראות את התהליך שהריץ את הפעולה במערכת, כיצד הוא הסתיים (אם בעמודת הסטטוס הספרה שונה מאפס, סימן שהפעולה הסתיימה בכישלון), איזה מכונה יזמה אותו ועוד. ישנם מאפיינים נוספים בטבלה כמו: סינון עפ"י משתמש וקבלת פרטים נוספים לכל שורה (התמונה הבאה).

הכלי מספק גם סטטיסטיקות לגבי התהליכים של המערכת לאורך זמן:

לסיכום

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

לפני מספר ימים כתבנו פוסט על העדכון החדש ל- Visual Studio 2012, עדכון שנקרא Update 2.. העדכון כרגע בגרסת ה- CTP אך כבר עכשיו שוחררו יכולות חדשות, בעיקר בנושא ה- ALM.

הכירו את ה- Test Hub

בפוסט זה אני רוצה לכתוב על פיצ’ר חדש שרבים המתינו לו בכיליון עיניים: ה- Test Hub in Team Web Access או בקיצור ה- Test Hub שהוא למעשה כלי שנותן יכולת להריץ בדיקות דרך ה- Web, יכולת קריטית עבור ארגונים רבים.

הבעיה – איך להריץ בדיקות ללא התקנת תוכנה ייעודית?

עד היום בודקים היו צריכים לתמרן בין ה – MTM לאפליקציה הנבדקת כאשר לא ניתן להתקין את ה – MTM על המחשב הנבדק, לעבור בין שני מחשבים, להחזיק לפטופ נוסף על המחשב הנבדק או לעבור בין מחשבים וירטואליים, בקיצור לא נוח והרבה פעמים ממש לא פרקטי.

הפתרון – הרצת בדיקות ישירות מהדפדפן באמצעות Test Hub

ה- Test Hub  הוא כלי בדיקות מבוסס Web שלא דורש התקנה כלל ומאפשר לבודקים להריץ את הבדיקה על המחשב כאשר ה – Test Runner רץ בתוך Browser. (עובד לא רק ב- IE אלא גם בדפדפנים אחרים).

איך משתמשים ב- Test Hub?

ה - Test Hub in Team Web Access לא שוחרר כחלק מהתקנת ה – CTP אלה כחלק משירות הענן Team Foundation Service.  לכן, יש ליצור חשבון ב – Team Foundation Service מכאן. אל תדאגו, זה חינם.

לאחר יצירת החשבון ו – Team Project מתאים נבצע את השלבים הבאים שאותם נסביר בפירוט בהמשך הפוסט:

1. נחבר את ה – MTM לשרת ולפרויקט
2. ניצור תוכנית בדיקות
3. ניצור מקרה בדיקה
4. נריץ את מקרה הבדיקה דרך ה – Test Hub  ונבדוק שהתוצאות מתועדות.

הוראות צעד אחר צעד

צעד 1: נריץ את ה – MTM

צעד 2: לחץ על Home

צעד 3: עכשיו לחץ Change project

צעד 4: לחץ Add server

צעד 5: הזן את ה – URL שלך ב – Team Foundation Service ולחץ Add

צעד 6: תתבקש לבצע Log-in יש לבצע זאת עם ה – Microsoft Account שלך

צעד 7: יש לבחור את ה– Team Project שיצרת ב– Team Foundation Service ולחץ Connect now

צעד 8: לחץ Add להוספת תוכנית בדיקות

צעד 9: הזן שם לתוכנית הבדיקות ולחץ Add

צעד 11: בחר את תוכנית הבדיקות שנוצרה ולחץ Select plan

צעד 12: לאחר שבנינו תוכנית בדיקות ניצור Test Suite על ידי לחיצה על New

צעד 13: הזן שם משמעותי ל – Test Suite ולחץ New ליצירת Test Case חדש

צעד 14: הזן את מקרה הבדיקה ולחץ Save and Close

צעד 15: ניכנס ל – Web Access של ה – Team Foundation Service ונלחץ על Test בשורת הטאבים

נראה שהבדיקה מופיעה.

צעד 16: נסמן את הבדיקה ונלחץ Run

כעת יפתח לנו ה – Test Runner

צעד 17: נריץ את הבדיקה עד הסוף  ולחץ Save and Close בסוף הבדיקה

נראה את התוצאה ב – Test Hub in Team Web Access

נראה גם את התוצאה ב - MTM

ניתן גם לכתוב בדיקות דרך ה – Test Hub in Team Web Access או לערוך בדיקות קיימות, כמו כן פונקציונאליות חדשה נוספת שניתן לראות כאן זה תיוגים.

תייגתי את הבדיקה הזאת כ – Valid Test.

סיכום

על פי התרשמותי מהתנסות קצרה עם הכלי מדובר בכלי נוח יחסית שנותן פתרון הולם היכן שלא ניתן להתקין את ה – MTM. בוודאי שבכול מקום בו ניתן להתקין את ה – MTM אני יעדיף אותו מפני שיש לו יכולות רבות יותר.

יש לכם שאלות בנושא Visual Studio ו-ALM? כנסו לפורום שלנו בעברית.

הפוסט נכתב על ידי ערן רוסו , מנהל חטיבת ה - ALM & DevOps בחברת TOP Q, המובילה במגוון פתרונות אוטומציה לבדיקת מוצרי תוכנה, ALM ו – DevOps בטכנולוגיה מתקדמת, המיועדים לסביבות מחשוב מרובות מערכות, קונפיגורציות ותהליכים בארגונים בינוניים וגדולים. כנסו לבלוג של ערן וקראו על עוד נושאים מעולם ה- ALM וה- TFS ואתם מוזמנים גם לקבוצת הלינקדאין.

לפני מספר ימים שחררנו להורדה עדכון ל- Visual Studio 2012 בגרסת CTP, עדכון אשר מכיל מספר יכולות חדשות וביניהן תמיכה ב- Git, מערכת ניהול קוד מבוזרת הצוברת פופולריות רבה בשנים האחרונות.

זוהי בשורה משמחת לכל המשתמשים בכלי ניהול התצורה Git, אשר מהיום יוכלו לעבוד בצורה נוחה מול Git Repositories של צד שלישי כמו GitHub וכו’ וכן מול Git Repositories אשר מתארחים בשירות הענן של TFS, הלא הוא Team Foundation Service אשר כתבנו עליו בעבר.

מהיום אתם יכולים להגדיר לשירות ה- Team Foundation Service מול איזה Version Control לעבוד: TFS או Git.

איך מתקדמים?

1. פותחים חשבון לשירותי TFS בענן כאן.

2. אתם צריכים Visual Studio 2012 ובנוסף להתקין את ה-Update 2 שנמצא בשלב הCTP.

3. מתקינים את כלי ה-Git עבור Visual Studio 2012.

לאחר שסיימנו עם השלבים המוקדמים, מתחברים לדף הבית של שירותי ה-TFS, וכבר ניתן לראות שאפשר לבנות שני סוגי פרויקטים, אנו נבחר באופציה שכוללת את האינטגרציה ל - Git:

השינוי היחידי שצריך לשים אליו לב הוא היכולת לשנות את סוג ה - VC:

ואחרי כמה שניות:

לכשנפתח את Visual Studio נראה שב - Team explorer כבר יש את פקודת הGit "clone" ומצד שמאל של המסך ב – Source Control Explorer נראה שאין מידע זמין עבור הפרויקט מאחר והפרויקט משתמש ב – Git.

נלחץ עלclone כדי להתחיל את הקישוריות ל – Git.

כל פעולות ה -Git )כדוגמת: Pull, Fetch, Branch ועוד( ימצאו בלשונית Team Explorer:

ומכאן כל שנותר לעשות הוא להתחיל לפתח!

הכנסו עכשיו לפורום העברי שלנו בנושא Visual Studio & ALM והתייעצו עם מיטב מומחי הקהילה.

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

שוחרר העדכון בגרסת CTP שהיא למעשה גרסת Preview לקהילה הטכנולוגית.

בעדכון 2 הולכים להיות הרבה פיצ’רים חדשים ויכולות חשובות בעיקר בתחום ה- ALM. לא כל הפיצ’רים כלולים בגרסה זאת אבל זה בהחלט נותן לכם הצצה ליכולות החדשות.

להורדת העדכון לחצו כאן

העדכון הנוכחי כולל יכולות ב-4 קבוצות עיקריות:

1. Agile Planning
2. Quality Enablement
3. Line of Business Development
4. Developer Experience

יש לכם שאלות בנושא Visual Studio ו-ALM? כנסו לפורום שלנו בעברית.

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

אחד מהאתגרים הגדולים ביותר בכתיבת unit testing לאפליקציה שלנו היא העובדה שלעתים אנו תלויים בגורמים חיצוניים שמקשים עלינו לבדוק כל יחידה בצורה עצמאית. למשל, קטע קוד הכותב למדפסת או למערכת קבצים. מאמר זה יספר לכם כיצד ניתן להתגבר על מכשול זה באמצעות יכולת חדשה ש- Visual Studio 2012 מציגה.

אז בבמאמר הקודם דיברנו על stubs – כלומר על הדרך הנכונה לבדוק בצורה מבודדת ככל האפשר קוד שנכתב בצורה נכונה, כלומר תוך שימוש ב-Interfaces וב-Dependency Injection.

לצערנו הרב, כנראה שלא כל הקוד בעולם (ואולי אפילו לא כל הקוד שנכתב בחברה שלכם..) אכן נכתב בצורה כזו. לא נדיר למצוא ערמה ענקית של קוד, שקשה ויקר מדי לכתוב אותו מחדש בצורה מושלמת – ובכל זאת אנו רוצים לכתוב לו Unit Tests, שלא יחייבו הקמת סביבה מיוחדת וירוצו גם על build servers.

הכירו את ה- Shims

כאן באים לעזרתנו כוחות האופל – ה-Shims. Shims מאפשרים להחליף כל פונקציה שהקוד קורא לה – כולל פונקציות מערכת –בפונקציה משלנו, וזאת בלי לשנות את הקוד הנבדק.

למה ה-Shims נחשבים לכוחות אופל? כי הם מחליפים, למעשה, כל קריאה לפונקציה המקורית בפונקציה שלנו. כיוון שמדובר בפונקציית מערכת, ולא ב-Interface, כמו במקרה של Stubs – הרי שכל הקריאות, כולל אולי כאלה שלא חשבנו עליהן ואולי אף כאלה המופעלות על ידי הקוד הבודק, יוחלפו, מה שעלול לגרום לתוצאות מפתיעות... לכן יש להשתמש ב-Shims בזהירות, ובוודאי להעדיף שימוש ב-Stubs כאשר הדבר אפשרי.

אחרי האזהרות, הגיע הזמן להסביר איך משתמשים ב-Shims...

ניקח את דוגמת הקוד הבאה:

public class Multiplier
    {
        private StreamWriter m_outFile;
        public Multiplier()
        {
m_outFile = new
StreamWriter("c:\\users\\yoarno\\Documents\\xxx.txt", true);
        }
        public int MultipyAndSave(int m, int n)
        {
            var result = m * n;
            var strResult = result.ToString();

            m_outFile.Write(strResult);
            return result;
        }
    }

שימו לב שמדובר בקוד דומה לזה שהבאנו בחלק הראשון, רק שפה הוא כתוב פחות יפה – כלומר ללא Dependency Injection ועם פניה ישירה ל-File System. כדי לבדוק את הקוד, עלינו לבודד את הפניה ל-File System, כיוון שאיננו בטוחים שבמכונת הטסט יהיה קובץ בנתיב המופיע ב-Constructor, ובוודאי שאיננו בטוחים שתהיה לנו הרשאת כתיבה לנתיב הזה. בנוסף איננו מעוניינים להשאיר במכונת הטסט "שאריות" בצורת קובץ חדש שיישאר לאחר ביצוע הטסט.

נניח בנוסף לכל אלה שאין ביכולתנו לשנות את הקוד – אולי המדובר בספריה סגורה ש"ירשנו" או סתם בקוד שאנחנו מפחדים לשנות כל עוד שאין לנו Unit Tests שבודקים אותו כמו שצריך (בעיה של "ביצה ותרנגולת").

לכן הפתרון היחידי שאנחנו יכולים לפנות אליו הוא שינוי של המימוש של StreamWriter, וזאת נוכל לעשות בעזרת ה-Shims.

איך משתמשים ב- Shims

נוסיף ל-Solution שלנו Test Project וניצור ממנו Reference לפרוייקט שבו כתבנו את ה-Multiplier (בדוגמא שיצרתי הוא נקרא ShimsSample).

כעת נצביע על ה-Reference (כמו שעשינו בחלק 1) אך הפעם נבחר את המודול System (בו ממומש StreamWriter) ונלחץ על מקש העכבר הימני. יופיע התפריט הבא:

נבחר Add Fakes Assembly וכעת יתווספו לפרוייקט שני אלמנטים חדשים – ספריה בשם System.4.0.0.0.Fakes וקובץ הגדרות בשם System.Fakes:

כעת, נוכל להחליף את היישום של StreamWriter.Write. את זאת נעשה בצורה הבאה:

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using ShimsSample;
using Microsoft.QualityTools.Testing.Fakes;

namespace MultiplyShimsTest
{
    [TestClass]
    public class UnitTest1
    {
        [TestMethod]
        public void TestMultiplyWrite()
        {
            using (ShimsContext.Create())
            {
                string actualString = "";
                System.IO.Fakes.ShimStreamWriter.AllInstances.WriteString =
 (@this, s) => actualString = s;
                var mult = new Multiplier();
                mult.MultipyAndSave(5, 7);
                Assert.AreEqual("35", actualString);
            }

        }
    }
}

שימו לב:

1. קטע הקוד הקורא ל-Shim תמיד יהיה כלול בתוך ShimsContext. בצורה כזו נגביל את ההשפעה של החלפת המימוש לאותן שורות קוד המעניינות אותנו – כדי למזער את הסכנה שבהחלפת פונקציות מערכת (יש לזכור שאפילו Visual Studio עצמו משתמש ב-StreamWriter וייתכן שנפגע גם בפונקציות שלו)
   
2. כמו במקרה של Fakes, גם כאן הפונקציה שהחלפנו נקראת WriteString – כלומר, אותו מופע של פונקציית Write המקבל String כפרמטר.

נריץ את הטסט (דרך תפריט Test/Run/All Tests) ונוודא שהוא עבר. אפשר בכוונה לשנות את ה-Expected Value כדי לוודא שהטסט נכשל במקרה כזה.

למרות שהצלחנו לשנות את ה-StreamWriter.Write, עדיין הטסט לא ירוץ תמיד על מכונת Build כיוון שחוקיות קובץ המטרה (c:\users\yoarno\Documents\xxx.txt) נבדקת בזמן הקריאה ל-Constructor של StreamWriter. כלומר, כדי לבודד לחלוטין את הפונקציה הנבדקת עלינו להחליף את ה-Constructor. את זה נבצע בצורה הבאה:

[TestMethod]
public void TestMultiplyWrite()
{
    using (ShimsContext.Create())
    {
        string actualString = "";
        System.IO.Fakes.ShimStreamWriter.ConstructorStringBoolean =
            (@this, f, fAppend) =>
            {
                var shim = new System.IO.Fakes.ShimStreamWriter(@this)
                {
                    WriteString = (s) => actualString = s
                };
            };

        var mult = new Multiplier();
        mult.MultipyAndSave(5, 7);
        Assert.AreEqual("35", actualString);
    }

}

שימו לב:

1. החלפנו את ה-Constructor הספציפי (זה שמקבל String ו-Boolean) באחד שלא ניגש כלל לקבצים.
   
2. את ההחלפה של WriteString הכנסנו לתוך ה-Constructor. כך קיבלנו צמצום נוסף של ה-Shim – במקום לכל המופעים של StreamWriter הוא מתייחס רק לאלה הקוראים לConstructorStringBoolean .
   
3. החלפת המתודה Writestring יכולה להתבצע בכל Instance של StreamWriter , כיוון שכולם מצביעים לאותן מתודות. לכן ניתן להגדיר משתנה ספציפי (כאן קראנו לו shim) ולבצע עליו את ההחלפה.

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

לסיכום:

• Shims הם כלי רב עוצמה (כמעט אפל...) לבידוד של בדיקות לקוד קיים כך שיוכלו לרוץ בכל סביבה.
  
• יש להשתמש ב-Shims כמוצא אחרון, ורק אם אין ביכולתנו לשנות את הקוד. אם אפשר, תמיד עדיף להשתמש ב-Stubs ו-Dependency Injection כמו שהסברתי בחלק הראשון של המאמר.
  
• Unit Tests הם ידידך – כתוב כמה שיותר, כך שתוכל להיות בטוח שהקוד שלך בדוק, מתפקד וימשיך לתפקד גם לאחר שינויים.
  
• רוץ ונסה את Visual Studio 2012 עוד היום! יש גם גרסה חינמית קלה או גרסה מלאה להתנסות.

* רשימה זו מסתמכת בחלקה על הפוסט המצוין של Peter Provost.

הכנסו עכשיו לפורום העברי שלנו בנושא Visual Studio & ALM והתייעצו עם מיטב מומחי הקהילה.

הפוסט נכתב על ידי יואל ארנון, מהנדס תוכנה במיקרוסופט המסייע ללקוחות פרמייר - Premier Field Engineer. בעבר יואל היה יועץ עצמאי וחבר בצוות הפיתוח של MSMQ במיקרוסופט חיפה.

שרת ה- Team Foundation Server או בקיצור TFS, הוא עדיין הפלטפורמה המיקרוסופטית החזקה ביותר בכל הנוגע לשיתוף פעולה בין צוותי פיתוח תוכנה. הוא מספק פתרון מקצה לקצה בכל שלבי הפיתוח של אפליקציות, כולל ניהול ותכנון פרוייקטי אג’ייל, ניהול גרסאות, אוטומציה ועוד יכולות הדרושות לניהול יעיל של פרוייקט תוכנה.

בנוסף ליכולות ששרת ה- TFS מספק, אנו רואים צורך הולך וגובר של אותן יכולות גם לסביבות פיתוח הטרוגניות, בהן המפתחים משתמשים ב- Visual Studo, Eclipse או Xcodoe, בהן המפתחים משתמשים ב- .NET, Jave, ++C או JavaScript, בהן המפתחים בונים אפליקציות לפלטפורמות Windows, Windows Phone, Azure, Android, iOS, MacOS, Linux.
אנו גם מבחינים בעובדה חשובה נוספת - שהענן הפך להיות גורם המפתח שמאפשר שיתוף פעולה בין המפתחים בסביבה הטרוגנית שכזו.

שנה שעברה בוועידת Build  2011, הודענו על שירות חדש – Team Foundation Service – גרסה של TFS על הענן של Windows Azure, שירות הנגיש מכל מקום ומכל הכלים המוכרים,שירות הנגיש מכל השפות והפלטפורמות. בשנה האחרונה הרצנו את השירות בגרסת ה- Preview שבהמהלכה שיפרנו אותו והוספנו יכולות.

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

להרשמה ללא תשלום לשירות הכנסו לכאן: https://tfs.visualstudio.com.

Team Foundation Service כולל תוכנית חינמית עם יכולות חזקות המאפשרות למפתחים בודדים או צוותי פיתוח קטנים (lean teams) להתחיל להשתמש בצורה מיידית בפלטפורמת ה- ALM מבלי לרכוש חומרה יקרה, לנהל גיבויים ולדאוג לקונפיגורציה והקשחה של השרת. השירות כולל תמיכה לא רק בטכנולוגיות וכלי פיתוח מיקרוסופטים כגון Visual Studio, Excel ו- Project – באמצעות קליינט Team Explorer Everywhere שכתבנו עליו בעבר ו- Git-TF, גם מפתחים של Mac OS, Linux, Solaris ו- HP-UX יכולים להתחבר ולהשתמש בשירות בקלות, באמצעות סביבת הפיתוח המועדפת עליהם.

תוכנית החינם כוללת תמיכה בעד 5 משתמשים, מספר בלתי מוגבל של פרוייקטים, ניהול גרסאות (Version Control), יכולות work item tracking, כלי תכנון אג’יליים, feedback management ו- build (שנמצא עדיין בגרסת preview).

בנוסף, מנוי MSDN מסוג Visual Studio Test Pro, Visual Studio Premium ו- Visual Studio Ultimate יזכו להטבות נוספות אשר יתפרסמו בקרוב, במידה ויעשו שימוש בשירות.

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

כולכם כבר יודעים שמגרסת 2012 ששוחררה לאחרונה Visual Studio הפך למעשה כלי פיתוח המסוגל לנהל את כל מחזור החיים של התוכנה: משלב התכנון, דרך שלב הפיתוח ועד לשלב הבדיקות. לנו המפתחים, זה כמובן עושה את החיים הרבה יותר “קלים” במובן הזה שאנחנו כבר לא צריכים ללהטט וללמוד את רזי השימוש בכלים שונים – אנחנו מקבלים כלי אחד שעושה את כל מה שאנו זקוקים לו’ או בניסוח יותר גיקי -  One tool to rule them all.

עם זאת, כן ישנן מספר גרסאות ל- VS 2012 וזאת על מנת לאפשר לכם המפתחים, לבחור את הגרסה המתאימה ביותר לכם לפי הצרכים שלכם, של הפרוייקט וכמובן התקציב. העיקרון הוא פשוט: ככל שהגרסה מתקדמת יותר, היא מכילה יותר יכולות ופיצ’רים כך שלמעשה הגרסה החינמית (Express) היא בהחלט עוצמתית אך כמובן שמכילה הכי פחות פיצ’רים, ואילו גרסת ה- Ultimate, היא הגרסה החזקה ביותר המכילה את כל היכולות של הגרסאות מתחתיה ועוד.

פוסט זה נועד לכל המפתחים המקצוענים אשר משתמשים בגרסת ה- Professional החזקה, אך מבקשים להרחיב את היכולות ו/או נדרשים מפרוייקטי התוכנה שלהם לגרסה מקיפה ומקצועית יותר הכוללת פיצ’רים נוספים אשר אינם כלולים בגרסת ה- Professional.

אתם מוזמנים לנסות את גרסת הניסיון של Visual Studio 2012 Premium

כלים לאבטחת איכות הקוד- Code Quality Tools

אז גרסת Visual Studio Professional 2012 או בקיצור VS Pro, מספקת יכולות unit testing עם תמיכה ב- test explorer החדש ותמיכה בפריימוורק בדיקות צד שלישי כגון NUnit. xUnit, QUnit. בהחלט מרשים.

גרסת הפרימיום, בנוסף ל- MS Test,  מוסיפה עוד מגוון יכולות הנוגעות לאבטחת איכות הקוד:

• Code Coverge – עוזר לכם לראות כמה מן הקוד שלכם מכוסה מבחינת בדיקות יחידה, ממש עד רמת שורת הקוד, על מנת שתגלו את הפערים בזמן.
• Code Metrics – עוזר לכם למדוד איפה יש סיבוכיות מיותרת שיכולה להביא לבאגים ותחזוקה מיותרת.
• Static Code Analysis – עוזר לכם להחיל חוקים ו- best practices על הקוד על מנת למנוע בעיות אבטחה ויציבות. עוזר לכם גם לאכוף את מתודולוגיית הפיתוח בארגון/חברה שלכם.
• Code Profiling – עוזר לכם לזהות בעיות ביצועים של הקוד שלכם, לזהות דליפות זיכרון, race conditions ו- deadlocks.
• Code Clone Analysis – פיצ’ר חדש ב- 2012, שסורק את הקוד שלכם במטרה למצוא כפילויות. עוזר לכם למצוא קוד ששוכפל באמצעות copy and paste ועוזר לכם למצוא היכן צריך לבצע refactoring.
  אתם יכולים לראות וידאו בנושא.
• Code Review – עוד פיצ’ר חדש ב- 2012 המאפשר בצורה נוחה וקלה לתת סקירות קוד או לקבל סקירות קוד מאחרים. עוד בוידאו כאן.

Suspend and Resume

אם אתם עובדים כמפתחים, בטח נתקלתם יותר מפעם אחת בסיטואציה הבאה: אתם עובדים על משימת פיתוח כלשהי, לגמרי in the zone, לא מעט קבצים פתוחים, breakpoints, pending changes וכו’ ואז לפתע מגיע ראש הצוות, מבקש לעזוב הכל כי התגלה איזה באג קריטי בסביבת הייצור שדורש תיקון מיידי. אם זה מוכר לכם, בטח תשמחו לגלות שבגרסת הפרימיום נוספה יכולת חדשה שמטפלת בדיוק בנקודה כואבת זאת: supend and resume. רק תלחצו על suspend והמצב של סביבת הפיתוח יישמר, מה שייאפשר לכם לעבוד בנוחות על משימה אחרת לגמרי. בסיום תלחצו על resume – וסביבת הפיתוח תשחזר בדיוק את ה- state שהיה קודם: קבצים פתוחים, breakpoints, pending changes וכו’. מאד נוח. עוד על כך בוידאו הזה.

Agile Tools

VS 2012 הציגה כלי Agile חדשים על מנת שתוכלו לעבוד על המשימות השוטפות בצורה יעילה ופשוטה יותר וכמובן לפי העקרונות והקונספט של מתודולוגיית ה- Agile. בגרסת הפרימיום תמצאו כלים שונים כגון ה- task board החדש המאפשר לכם לראות את ה- product backlog items ברזולוציה של מטלות וכמובן את סטטוס המטלות. גרסת הפרימיום גם כוללת את כלי התכנון של ה- product backlog ו- spring planning המאפשר לכם להקליט ולנהל את ה- backlog והספרינטים שלכם, כולל capacity managmnet. עוד כל כך בוידאו כאן.

StoryBoards

storyboarding זהו תוסף לתוכנת ה- power point המאפשר לכם ליצור ולהפיץ בקלות StoryBoarding לשאר אנשי הצוות ובעלי העניין. יש המון אלמנטים שכבר כלולים (כגון דפי ווב, טבלאות, ווידג’טים ועוד הרבה קומפוננטות אחרות) ואתם גם יכולים ליצור ולשתף בקלות אלמנטים אחרים שהפרוייקט זקוק להם.

Testing

גרסת הפרימיום של 2012 נותנת לכם גישה לכל כלי הבדיקות שבעבר היו קיימים רק לגרסת Ultimate, בחריגה אחת בלבד: כלי בדיקות הביצועים עדיין נגישים רק לבעלי גרסת Ultimate.

כלי הבדיקות החדשים שכלולים כעת בגרסת הפרימיום הם נושא לפוסט שלם, אך בסקירה מהירה אנו יכולים למנות:

• test case management – ביחד עם Microsoft Test Manager, סט של כלים לביצוע וניהול בדיקות.
• כלי בדיקות ידניות – תמיכה ב- fast forward playback  לביצוע אוטומציה של בדיקות. עוד על כך בוידאו הזה.
• Exploratory testing – פיצ’ר חדש ב- 2012, מאפשר לכם לבדוק בפשטות ובמהירות את האפליקציה שלכם מבלי לבנות test case. אתם יכולים לשחזר ולהקליט באגים ואפילו לבצע הנדסה לאחור של test case.
• Automated functional testing – אתם מעוניינים לבצע בדיקות אוטומטיות לאפליקציית הווב שלכם? בדיקות Coded UI בגרסת הפרימיום מאפשרות בדיוק את זה ויכולות להווצר מבדיקות ידניות או from scratch. עוד על כך בוידאו הזה.
• כלי פידבק חדש – מאפשר לכם לקבל ולהגיב על פידבקים שהתקבלו מבעלי עניין חיצוניים אשר משתמשים בכלי חינמי אשר ניתן להורדה.
• Lab Management – מאפשר תמיכה במעבדת בדיקות וירטואלית, המאפשרת לכם לנהל אוטומציה מקצה לקצה של תהליך ה- build, ההפצה והבדיקה. עוד בוידאו הבא.

סיכום

למרות שגרסת ה- Professional בהחלט חזקה ומתאימה לפיתוח אפליקציות מורכבות, כדאי מאד להכיר את היתרונות המשמעותיים של גרסת ה- Premium, ההופכים את הכלי להרבה יותר עוצמתי ולכלי המסוגל לספק פתרון ALM מקצה לקצה. הכלים החדשים הכלולים בגרסת הפרימיום מפשטים את תהליך הפיתוח ומאפשרים לכם סביבת עבודה אחידה מבלי להזדקק למספר כלי צד שלישי, שלא תמיד עובדים בצורה אינטגרטיבית טובה ופשוטה.

אתם מוזמנים לנסות את גרסת הניסיון של Visual Studio 2012 Premium.

יש לכם שאלות נוספות בנושא Visual Studio? הכנסו לפורום שלנו בעברית!

לאחרונה חברת גרטנר ביצעה סקירה מקיפה של שוק ה- ALM ומתוך 16 ספקים בתחום, מיקרוסופט מוצבה כמובילת השוק - גם בציר יכולת הביצוע וגם בציר שלמות החזון, כשהיא משאירה מאחור שחקנים מרכזיים כמו IBM ו- HP.

יש לשים לב שהדוח נכתב על בסיס VS 2010. בגרסת 2012 החדשה רק שיפרנו והוספנו יכולות ופיצ’רים רבים נוספים כמו גם שיפורים בעזרת פידבקים שקיבלנו ממכם המשתמשים, מה שמבטיח הגדלה נוספת של הפער מול המתחרים.

אודות מחקר גרטנר

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

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

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

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

מעמדה של מיקרוסופט בשוק ה- ALM

אמנם מיקרוסופט לא הייתה הראשונה שנכנסה לשוק ה- ALM, אך כיום ניתן לומר שהיא מובילה את השוק הזה.
"מכוח מעמדה בשוק כספקית של פלטפורמות וכלי פיתוח מובילים, פועלת מיקרוסופט כמובילה טכנולוגית בשוק ה-ALM", נכתב באותה סקירה של השוק ע"י גרטנר. "פרט ל-IBM, מיקרוסופט מציעה את כלי ה-ALM הרחבים ביותר בשוק מבחינה פונקציונלית. החברה נוטה להוציא גרסאות חדשות כל 18 חודשים, אולם היא גם נדרשת לתיאום מול עדכונים וגרסאות חדשות של פלטפורמות מרכזיות. על מנת לפצות על מחזורי פיתוח ארוכים, עושה צוות המוצר שימוש ב- MSDN כדי לספק הרחבות (מה שנקרא "Power Tools") וגישה מוקדמת לקטעי תוכנה אחרים."

בסיס לקוחות רחב ומגוון

עוד נכתב בדוח ש"מיקרוסופט מחזיקה בסיס לקוחות רחב, החל מעסקים קטנים ובינוניים (SMB) וכלה בארגונים גדולים וענפים, כך שהאתרים הגדולים ביותר שלה כוללים למעלה מ-10,000 משתמשים. בניגוד לכלים אחרים ב- Magic Quadrant, מיקרוסופט היא היצרנית היחידה הקושרת באופן הדוק את מערכת הגרסאות שלה לשאר כלי תכנון ה-ALM."

תמיכה בסביבות הטרוגניות

בדוח נקבע שעבור לקוחות המעוניינים לפתח ב- .NET ובסביבות מיקרוסופטיות, הרי שפתרון ה- ALM של מיקרוסופט הוא הטוב והמלא ביותר כיום בשוק, אך יש גם התייחסות לתמיכה שלה בסביבות הטרוגניות, אשר בגירסאות החדשות של Visual Studio בהחלט נתמכות. "אף על פי שמיקרוסופט היא אחת היצרניות היחידות המכסה את כל ההיבטים של ה-SDLC, האתגר הגדול ביותר הניצב בפניה הוא תמיכה בפיתוח לא-מיקרוסופטי. למרות זאת, עשתה החברה התקדמות ניכרת בתמיכה ב- Eclipseוביכולת להרחיב את ה-TFS עם קוד Java. האתגר הגדול ביותר העומד בפניה היום הוא לתפור יחד סביבה מעורבת הכוללת מפתחים על פלטפורמות לא מיקרוסופטיות שהסביבה שלהם כוללת כלי SCCM אחרים, והצעדים הדרושים כדי לתפור את כל זה יחד. TFS היא מערכת חזקה, אבל אם הארגון שלכם אינו משתמש ב-.NET או בטכנולוגיות מיקרוסופטיות אחרות, זו לא תהיה הבחירה הטבעית שלכם בשוק מוצרי ה-ALM. עם המעבר של פלטפורמות הפריסה לענן, זה כבר לא רק עניין של Java ו-.NET, ומיקרוסופט תצטרך להמשיך ולהפגין מחויבות ארוכת טווח לתמיכה בפלטפורמות אחרות הנדרשות על ידי המשתמשים."

פונקציוליות רחבה

הדוח נותן סקירה של הפונקציונליות הנרחבת אשר נתמכת וכוללת בין השאר:

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

נקודות חוזק

עוד הדוח קובע מספר נקודות חוזק, ביניהן:

ספקים שותפים, רשת פיתוח, מחיר, תמיכה ב-Office, SharePoint ו-Project.

לקריאת הדוח במלואו – לחצו כאן.

במציאות בה קבוצות פיתוח מפתחות אפליקציות אשר צריכות להיות מותאמות לפלטפורמות שונות ומגוונות כגון ווב, iOS, Android וכו', אין זה נדיר שצוותי הפיתוח והבדיקות עובדים בסביבות הטרגניות. חלקם מפתחים ב- Visual Studio, חלקם ב- Eclipse, חלקם על גבי Windows, חלקם על גבי Linux או Mac ולכל אלה מתווספים בעלי עניין נוספים כמו מנהל המוצר ומנהל הפרויקט שבכלל לא משתמשים בכלי הפיתוח עצמם.

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

Team Explorer Everywhere - חוצה פלטפורמות

הגירסה החדשה של Visual Studio מביאה את בשורת ה- ALM גם לסביבות פיתוח הטרוגניות באמצעות Team Explorer Everywhere. עד כה משתמשי TEE היו צריכים לרכוש את ה- Client Access License ואת ה- TEE, ומשתמשי ה- Visual Studio רק היו צריכים לרכוש את ה- Client Access License. אלא שלאחרונה הוכרז ש- TEE מוצע חינם (כן, חינם אין כסף) כתוסף ל- Eclipse. למעשה ה- TEE הינו plugin מבוסס Java המשולב ב- IDE של Eclipse, ומעניק לחברי צוות הפיתוח נגישות ל- TFS ממערכות הפעלה שאינן מבוססות Windows, לרבות Linux או Mac OS. קבוצות הפיתוח יכולות להשתמש ב- TFS, על אף העובדה שהם חוצים טכנולוגיות שונות.

דוגמה לתהליך חוצה פלופורמה כולל תרחיש לפיו אנשי הבדיקות יכולים להשתמש ב- Microsoft Test Manager כדי לדווח על באגים שמצאו באפליקצית iPad. מפתחי ה-Eclipse יעברו על הבאגים ויבחנו את הקוד על גבי מק. לאחר מכן הם ישתמשו ב- TEE כדי להבצע check-in של השינויים שבוצאו עם קישור לבאג עצמו. כל המידע זורם חזרה אל ה- TFS ומאפשר דווח מרוכז של התהליך כולו החוצה טכנולוגיות שונות.

אין צורך ברכישת CAL כדי לצפות בדוחות

כעת אין יותר צורך ברכישת רשיון CAL בכדי לצפות בדוחות אשר מופקות מה- TFS. זו בשורה חשובה לאותם בעלי עניין שמדי פעם רוצים לצפות בדוחות על מנת לבחון את התקדמות הפיתוח או נושאים אחרים. עבור משתמשים אלו רכישת הרשיון הוותה חסם שהיה מונע את השתתפותם הפעילה בתהליך הפיתוח.

מה חדש ב- Team Explorer Everywhere 2012

הגרסה החדשה של TEE מצטרפת למשפחת המוצרים של Visual Studio 2012 וכוללת מספר שיפורים חשובים:

• התקנה פשוטה ישירות מהרשת.
  ב-TEE 2010 היה צריך להוריד חבילת plugin ולהוסיף אותה ידנית אל ה-Eclipse. את TEE 2012 ניתן כעת להתקין ללא הורדה נפרדת אלא כחבילת התקנה ישירות ממיקרוסופט, כך שתהליך ההתקנה מבוצע אוטומטי.

• ממשק Team Explorer חדש
  בדומה לממשק למשתמשי 2012 Visual Studio, גם משתמשי TEE יקבלו חוויה דומה בממשק ה-Team Explorer החדש. חלונות ה-Pending Changes וה-Build Explorer הורחבו לכלול מידע נוסף. הבשורה הגדולה יותר היא שנוספו אפשרויות הגדרות וניהול שהיו בלעדיות עד כה למשתשי ה-Visual Studio. 
• תמיכה ב-Local Workspace
  פיצ'ר חדש וחשוב זה של TFS 2012 נתמך גם עבור משתמשי ה-Eclipse.
• תמיכה ב- TFS בענן
  מוצר חדש נוסף שנוסף למשפחת ה-Visual Studio ALM 2012 הנתמך גם הוא עבור משתמשי ה-Eclipse.
• עורך work item מובנה
  אם בגרסת TEE 2010 עריכת הבאגים או המשימות היתה מתבצעת דרך דפדפן חיצוני, בגרסת 2012 ניתן לערוך אותם ישירות מתוך ה-Eclipse.

לסיכום

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

יש לכם שאלות נוספות בנושא ALM או VIsual Studio?
הכנסו להתייעץ עם מיטב המומחים בפורום העברי שלנו!

 הפוסט נכתב על ידי קובי מורז, מוביל תחום ALM בחברת CodeValue, ארכיטקט ALM ומנהל פרוייקטים בהטעמות TFS. ליצרת קשר ומידע נוסף בבלוג שלו.

CodeValue מובילה במתן מענה ובפיתוח פתרונות תוכנה למגוון חברות ומציעה מגוון רחב של שירותים מקצועיים ושירותי ייעוץ. החברה מתמחה ומתמקדת במספר נושאים מרכזיים העומדים היום בקדמת הטכנולוגיות של עולם התוכנה:
Cloud Computing, Mobile, UX, Microsoft Technologies, ALM and TFS

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

בזמן האחרון אנו שומעים הרבה את המושגים DevOps ו-NoOps.
מדובר בשתי נקודות מבט שונות על הדרך לשפר את האינטראקציה בין הפיתוח לייצור מתוך כוונה לשפר את זמן מחזור הפיתוח ואת איכות היישום. אחד התהליכים שנוצרו במרחב זה הוא "הפריסה המתמשכת" – העברת גרסאות חדשות של האפליקציה לייצור (או לסביבה דמוית ייצור) באופן מתמשך מתוך מטרה לתרגל את "שריר" הייצור ולראות תוצאות. 

לאחרונה חשפנו את האינטגרציה בין Azure ל-Team Foundation Service, שותפות המאפשרת פריסה אוטומטית ל- Windows Azure Websites או ל- Windows Azure Cloud Services.

כברירת מחדל, אנחנו קובעים את תצורת הפריסות האוטומטיות לאחר כל check-in, אולם הדבר ניתן לשינוי לפריסות מתוזמנות או ידניות. בעיקרון, ניתן לעשות כל מה שאפשר לעשות עם TFS Build.

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

הערה חשובה: 
על מנת לאפשר יכולות פריסה מתמשכת חדשה (Continuous Deployment), יצרנו תבנית חדשה לתהליך ה-build, תבנית הנקראת AzureContinuousDeployment.11.xaml.  בסוף הפוסט תמצאו לינק להורדת הקובץ.
תבנית זו נמצאת ב-source control בתיקייה $/<teamprojectname>/BuildProcessTemplates.

אם תיצרו Team Project חדש, היא תתווסף אליו אוטומטית. אולם היא לא תתווסף לפרויקטים קיימים.
לאור זאת, יהיה עליכם להוסיף אותה בעצמכם אם אתם רוצים להגדיר פריסה מתמשכת.
אם תנסו לחבר את חשב ה- azure לפרויקטים הקיימים שלכם, תקבלו את הודעת השגיאה הבאה:

Failed to link TFS project 'MS' with your web site ‘<websitename>’ 

TF42073: The value cannot be null (Parameter name: Process) 

אתם יכולים למפות את תיקיית BuildProcessTemplates ל-workspace במחשב שלכם, להוריד את קובץ ה- xaml שצירפנו ולגרור אותו ל- Source Control Explorer או לחילופין להעתיק אותו לתיקייה ולהוסיף אותו, או משורת הפקודה או דרך ממשק המשתמש. מרגע שעשיתם זאת, אתם יכולים להשתמש באשף כדי להגדיר פריסה מתמשכת.

ישנו שלב נוסף. בנוסף ל-checking-in של תבנית תהליך ה-build החדשה, עליכם ליצור Build Definition שיקונפג לשימוש בתבנית זו. להלן הסבר הכולל שלבים מפורטים לעשות זאת.

פתיחת Azure Web Site וקישורו ל- TFS

נתחיל ביצירת חשבון Azure . אם כבר יש ברשותכם חשבון - אתם מסודרים.
אם לא, היכנסו לכאן והירשמו לגרסת ניסיון חינם או צרו חשבון מלא.

ברגע שיש לכם חשבון Azure, צרו אתר אינטרנט וגשו למרכז השליטה או ה- dashboard של האתר.
בצד ימין למטה תמצאו קישור ל-" Setup TFS publishing".
לחצו עליו כדי לקשר את פרוייקט ה- TFS שלכם לאפליקציית Azure באמצעות האשף.

האשף יאפשר לכם לקשר את האתר לחשבון Team Foundation Service קיים או ליצור חשבון חדש.
ברגע שיש לכם חשבון, הכניסו אותו בשדה "user name" ולחצו על "Authorize Now".
זה יביא אתכם לאשף אישור קטן, ואז ייקח אתכם לדף שבו תבחרו את ה- Team Project שבו נמצא קוד המקור של האפליקציה שלכם.

כעת, האתר שלכם ב- Azure והפרוייקט שלכם ב- TFS מקושרים בהצלחה!

במסגרת קישור החשבונות, יצרנו גם הגדרת build עם Continuous Integration שתבנה ותפרוס את האפליקציה שלכם ב-Azure בכל פעם שאתם עושים check-in.

אז הדבר הבא שאתם יכולים לעשות הוא ללכת ל- Visual Studio ולצור אתר חדש, או לערוך שינוי באתר קיים ולראות אותו נפרס.
אם אתם משתמשים ב- VS 2012 ששוחרר לאחרונה, אתם יכולים פשוט ללחוץ על האייקון של Visual Studio בתחתית הדף של Azure, מה שייפתח לכם את התקנת ה- VS עם הפרוייקט שקינפגתם.
אם אתם משתמשים בגרסאות קודמות, פשוט תריצו את  VS 2010 ותתחברו משם לחשבון ה- TFS המתאים.

תוכלו לצפות גם בתוצאות הפריסה בדוח של ה-TFS Build או בפורטל של Azure

בנוסף, ניתן לצפות בתוצאות הפריסה גם מתוך ממשק המשתמש של TFS באינטרנט

סיכום

למעשה, ש כאן מעט מאוד "קסם". אין ספק שעשינו קצת עבודת OAuth כדי לאפשר את שיתוף הפעולה בין ה-TFS ל-Azure. נכון לעכשיו עבודת ה-OAuth הזאת עדיין פרטית, אבל אנחנו צפויים לפתוח אותה בעתיד לאינטגרציות נוספות.

הוספנו גם קונספט חדש של "סביבת פריסה" המכילה את המידע הנחוץ להתחברות לנקודות הקצה בפריסה, לשמור באופן מאובטח על נתוני זיהוי וכו’. מעבר לזה, כל האינטגרציה הזאת מסתכמת בעצם במערך חדש של תהליכי TFS Build המסוגלים לבצע פריסות ל- Windows Azure. הוספנו גם פיסת ממשק משתמש חדשה ל-Build Explorer ב- Web Access להצגה וניהול של מצב הפריסה.

האם ניתן לעשות זאת על שרת ה- TFS המקומי?

טבעי שתשאלו אם ניתן לעשות זאת עם שרת ה- TFS המקומי שלכם..
כמובן שאתם יכולים לבצע פריסה אוטומטית לסביבות מקומיות באמצעות Lab Management.
ישנן גם דרכים ידניות לקנפג TFS Build מקומי לפריסה ב-Azure.
כמו שאתם יכולים להבין מהמאמר, התהליך הזה כולל הרבה שלבים.
ככל שיכולות הפריסה המתמשכת ילכו ויבשילו, אנחנו צפויים להביא יותר יכולות ופשטות גם למוצרי ה- TFS המקומיים. ביכולות הקיימות כיום אנחנו מראים רק את ה- "בקרוב" למה שעוד צפוי לבוא..

אם אתם מבצעים פריסות ל- Azure, אני מקווה מאוד שגיליתם כאן דרך נוחה ומהירה לייעל את תהליך הפיתוח שלכם. אל תהססו לנסות את זה בבית ולחלוק אתנו כל פידבק שיהיה לכם.

כאן תוכלו להוריד את קובץ ה- XAML שדיברנו עליו בתחילת הפוסט.