לחלק הראשון
הערה כללית: המאמר עוסק במיגרציה עצמה ומניח שהקורא מכיר את המונחים הבסיסיים בג'ירה וב-Quality Center (להלן QC).
הערה כללית: המאמר עוסק במיגרציה עצמה ומניח שהקורא מכיר את המונחים הבסיסיים בג'ירה וב-Quality Center (להלן QC).
המאמר מתאר איך אני ניגשתי לעניין, לא בהכרח זה מתאים לכל אחד ואופן השימוש שלו ושל החברה שלו בכלים אלה.
וכמובן אינני אחראי לדרך שבא מי שיקרא יממש את האמור או בעיות שיווצרו מכך.
הכנות כלליות
יצרתי עץ מסמכים ב-Confluence, עוד מוצר של Atlassian שנועד ליצור עבודה משותפת בין גורמים שונים וכלי לניהול מסמכים וידע.
הכנסנו לשם את הוורקפלואו של הבאגים (כלומר מפת הסטטוסים האפשריים של הבאג והמעברים המותרים), סוגי דפקטים שונים (באגים, רעיונות לשיפור המוצר וכד'), תהליכים אחרי שנעשים ב-QC.
כאמור הקמנו פורום של מעבר, והחלטנו בו על השדות שנרצה להעביר ועוד. אני שוב מזכיר שלא כדאי להעביר את הכל as is רק בגלל שאנו רגילים לכך. אם למדנו משהו מהאג'ייל זה שכדאי לעשות רק דברים שנותנים ערך, ולא לבזבז את הזמן במה שלא.
הכנות בג'ירה
הכנות בג'ירה
פרויקט
העדפתי ליצור פרוייקט חדש לבאגים ולא להשתמש בפרויקט שיש אצלנו לפיתוח או לזה של מנהלי המוצר למשל. הסיבה היא שזה נוח בתקופת ההכנות לא לעשות רעש מיותר בפרויקטים שהם פרודקשן, שיותר קל לעשות שינויים בפרויקט משלך, וכשנעביר את הטסטים לג'ירה יתווספו כנראה עוד Issue Types שעלולים לבלבל את הפיתוח.
כמובן שהג'ירה מאפשרת קישוריות בין פרויקטים והדוחות גם הם יכולים לכלול מספר פרויקטים.
Issue Type
יש בג'ירה Issue Type שבא עם כברירת מחדל בשם באג, אבל מכיוון שיש לנו הרבה משתמשים מקבוצות שונות ולא רציתי לשנות (בטעות או שלא) Issue Type שאולי כבר משתמשים בו ייצרתי אחד חדש.
שדות
אחרי יצירת ה-Issue Type, הדבר הבא היה ליצור את השדות שהחלטנו שאנחנו כן נעביר מה-QC ושנשתמש בהם גם לדיווחים חדשים.
אחרי שכבר סגרנו מראש את השדות שבחרנו להעביר ולהשתמש בהם, היה אפשר לחשוב שכל מה שנשאר הוא לייצר שדות חדשים. אבל זה רק חלק מהעניין.
דבר אחד הוא שאם החלטנו להעביר חלק מהבאגים ואחר-כך נרצה להעביר עוד - אין בעייה. אבל אם נרצה להעביר עוד שדות לבאגים שהעברנו זו תהייה בעיה. לכן העברתי בטאב שונה (ראו screens בהמשך) עוד כמה שדות ליתר ביטחון.
דבר שני הוא שה-QC שלנו מאוד מקוסטם והרבה מהקסטום הזה הוא של שדות מקושרים. למשל, יש לנו רשימה של פיצ'רים בטופס הדיווח של הבאג. אם בחרת פרויקט W השימת הפיצ'רים תהיה X. אבל אם בחרת בפרויקט Y הרשימה תהייה שונה. יתר על כן, היו לא רק שני שדות מקושרים אלא לפעמים יותר.
הפתרון שלנו נחלק לשניים:
1. הפתרון הטכני: Cascading Fields - שדה שבא עם ג'ירה. הוא מחבר שתי רשימות בלבד, אבל בהחלט פתרון לחלק מהנושאים שהיו לנו. ישנו פתרון אחר בתשלום מה-מרקט שנותן להכניס מספר רב של רשימות מקושרות. אפשר להשתמש בשדה רב-ערכי כזה בשאילתות JQL ובתוספים של דוחות כמו Rich Filters וכן eazyBI. כדם יש פתרונות בייבוא של שדות כאלה מה-QC לג'ירה.
2. הפתרון ההתנהגותי: כאמור וברוח האג'ייל אנו רוצים לפשט. אולי לא באמת יש צורך בכל הרשימות האלה.
1. הפתרון הטכני: Cascading Fields - שדה שבא עם ג'ירה. הוא מחבר שתי רשימות בלבד, אבל בהחלט פתרון לחלק מהנושאים שהיו לנו. ישנו פתרון אחר בתשלום מה-מרקט שנותן להכניס מספר רב של רשימות מקושרות. אפשר להשתמש בשדה רב-ערכי כזה בשאילתות JQL ובתוספים של דוחות כמו Rich Filters וכן eazyBI. כדם יש פתרונות בייבוא של שדות כאלה מה-QC לג'ירה.
2. הפתרון ההתנהגותי: כאמור וברוח האג'ייל אנו רוצים לפשט. אולי לא באמת יש צורך בכל הרשימות האלה.
אנחנו השתמשנו בשני הפתרונות במקרים שונים.
חלק מהשדות ב-QC היו מנדטוריים ואת חלקם הפכנו לכאה בג'ירה (המינוח בג'ירה הוא Required field).
יצירת Workflow (להלן WF)
החלטנו לא לשנות מאוד את ה-WF כיוון שמה שהיה היה סביר ולא מורכב מידי.
מה שכן, השתמשנו באפשרויות של הג'ירה, למשל בהקפצת מסך במעבר בין סטטוסים. אם למשל אתה מרג'קט באג, קופץ מסך מנדטורי שמבקש את הסיבות לריג'קט.
מבחינת הרשאות אין בעייה לתת לקבוצה ספציפית (הג'ירה מחוברת לאקטיב-דיירקטורי ושם יש קצוצות רלוונטיות כמו של אנשי הבדיקות).
במאמר הבא אעבור על המיגרציה בפועל.
מאמר לא רע אך רדוד מדי
השבמחק