בסדרת הפוסטים הבאה זה אני הולך לדבר על מייבן (Maven), תחילה מה זה ולמה הוא חשוב מאוד בבניית תוכנה ואח"כ איך אנו יכולים לרתום את יכולותיו של מייבן כשאנו באים לכתוב פרוייקט אוטומציה.
מייבן (לקוח משפת היידיש – מבין) מוגדר ככלי לניהול בניית תוכנה (Build Management Tool) , רגע, מה ? אנחנו אנשי QA, אנחנו לא בונים תוכנה, אנחנו בודקים אותה, מה זה בעצם אומר המושג הזה: "בניית תוכנה" ?
תחשבו על זה שמצד אחד יש לכם קבוצה של מפתחי מוצר שבאים יום יום לעבודה וכותבים קוד, או מתקנים את הפאשלות שלהם 🙂 , בסופו של תהליך נכתב קוד רב שמחולק למחלקות, לחבילות, לפרוייקטים, לספריות, לקבצים וכו'… ומצד שני יש לכם את הלקוח, ה-End User. הלקוח אינו חשוף לכל אותן מחלקות, חבילות, פרויקטים… זה לא מעניין אותו, הוא בכלל לא מודע אליהם, הוא מקבל, לצורך הדוגמא, קובץ התקנה (executable) שעליו הוא מקליק הקלקה כפולה ומתקין את התוכנה, את מוצר שעמלו עליו הרבה מפתחים מאחורי הקלעים.
התהליך הזה בו אנו לוקחים את כל הקוד שהמפתחים כתבו והופכים אותו למוצר מוגמר ללקוח נקרא בניית תוכנה – Build, הוא כולל בתוכו כמה שלבים כמו העתקת קבצים, קומפילציה, הפעלת Pre-Post Processing על תוצרי הקומפילציה, אריזה, ניהול ה-CLASSPATH , ניקוי ומחיקת קבצים זמניים, התקנה מקומית ועוד.
מייבן כאמור הוא כלי אחד שקיים בשוק לניהול התהליך הזה של בניית התוכנה והוא מיועד למפתחים בשפת Java, זהו כלי מאוד פופולרי, הדגם המתקדם יותר של כלי אחר – ANT (שניהם מבית היוצר של פרוייקט Apache) והמתחרה העיקרי ל-Gradle (שכתוב בשפת Groovy).
ניתן לעבוד עם מייבן ישירות מול ה-Command Line אך הוא תומך בכל ה-IDE's הפופולריים, ביניהם: IntelliJ , Eclipse, NetBeans ועוד.
בניית התוכנה
הרעיון הכללי ב-Maven הוא שבשביל לבנות תוכנה אנו נבצע את אותם שלבים לפרוייקטים שונים (בין אם זה פרוייקט בתחום הסייבר, או המובייל), למשל כולם יצטרכו לקמפל את הקוד שלהם, כולם יצטרכו לוודא את תקינות הקוד, כולם יצטרכו לארוז את החבילה וכו'. לכן במייבן יצרו לנו כל מיני תבניות שמבצעות את הפעולות הללו ולא רק, הם הכניסו גם את התלויות בין הפעולות (לדוגמא, לא ניתן לעשות לחבילה deploy אם הפרוייקט לא עבר את תהליך התקינות).
התבניות הללו נקראות במייבן: Archetypes ויש לנו כאלו לפרוייקטים שונים, למשל יש לנו Archetype לפרוייקט אפליקציית Web או לפרוייקט J2EE , כפי שניתן לראות כאן:
אז ה-Archetype מגדיר לנו את המודל שעימו אנו נרצה לעבוד, מי שיריץ את הפעולות (העתקת קבצים, וולידציה, קומפילציה…) המודל הזה מורכב מה-Plugins של מייבן ומי שאחראי על האפיון (או ה-Strategy) הוא ה-POM.xml עליו ארחיב בהמשך.
יצירת פרוייקט Maven:
כשאנו ניצור פרוייקט מייבן, אנו ניתקל בכמה מושגים חדשים:
GroupID : זהו השם הכולל שנרצה לתת, תחשבו כאילו זהו שם המשפחה, למשל נכתוב כאן את שם החברה (שמייצרת כמה מוצרים).
ArtifactID: שם הפרוייקט, או שם המוצר אותו אנו כותבים
Version: מספר הגרסה של הפרוייקט שלנו
בשלב הבא, הפרוייקט יווצר ב-IDE ויראה כפי שהגדרנו בבחירת התבנית (בדוגמא הנ"ל, בחרנו ב-maven-archetype-quickstart)
שימו לב למבניות של מערכת הקבצים, יש לנו את ספריית ה-src שם ימוקם הקוד ותחת ספריית target אמורים לשבת תוצרי הפרוייקט, קבצי class לאחר קומפילצה למשל.
יש גם את ספריית ה-src/main כאן ישב הקוד שלנו לכתיבת המוצר, שימו לב כי מכאן הוא גם מחולק לשפות שונות, למשל יכול להיות src/main/java או למשל src/main/javascript
תחת ספריית ה- src/test אנו נכתוב את הבדיקות שלנו , בדיקות היחידה עם Junit או TestNG (על זה נרחיב בחלק ב' של הפוסט)
קובץ ה-POX.xml הוא קובץ הקונפיגורציה של מייבן, זהו הקובץ עימו אנחנו לרוב נתעסק, בקובץ זה אנו נגדיר את ה-Dependencies שלנו לפרוייקט (ראו בהמשך הפוסט), בקובץ זה אנו נגדיר את ה-Plugins עימם נרצה לעבוד, את הפרופילים לקביעת הרצה של בדיקות מסויימות וכו'.
מערכת לניהול תלויות – Dependency Management System:
אחד המפתחות של מייבן הוא מערכת לניהול לתלויות, בעזרת מערכת זו, איננו צריכים להוריד באופן ידני, בשיטת הטלאים (טלאי על טלאי…) את ספריות הקוד (source code) עימן נרצה לעבוד, ובכך נוכל למנוע מצב של Dependency Hell.
זהו עניין קריטי כשאנו עובדים עם ספריות שונות, בכדיי להסביר את זה בצורה הטובה ביותר, אתן דוגמא לפרוייקט באוטומציה.
כתבתי פרוייקט בסלניום, זה אומר שהורדתי (נגיד, ללא מייבן – באופן ידני) את ספריות הקוד של סלניום, עבר שבוע ועכשיו אני רוצה לעבוד גם עם אפיום, אוקיי אז אוריד גם את ספריות הקוד של אפיום לאותו פרוייקט, עבר שבוע נוסף וכעת ארצה להטמיע גם בדיקות אוטומטיות על צד הסרבר עם ספריות של REST Assured למשל , ואח"כ להוסיף גם את ה- Winium או ה-White לבדיקות על אפליקציות דסקטופ…. מי ינהל את כל הספריות האלו ? מה יקרה כשארצה לעדכן אחת מהן ? או לשנמך אחת מהן בעקבות באג ?
עד כאן אלו בעיות מעצבנות, אבל שניתן לפתור אותן בעבודה מסודרת, מה שבאמת מפריע זה, מה קורה כשיש התנגשויות בין קבצים ? לדוגמא, הידעתם שקובץ ה-guava.jar קיים הן ב-Selenium, הן ב-Appium, הן ב-Winium, והן ב-REST Assured ? זה אומר שבפרוייקט שלכם יהיו 4 מופעים (לפחות…) של קובץ זה, ותאמינו או לו – הם מתנגשים וגורמים לפרוייקט שלנו לא לעבוד.
מערכת לניהול התלויות באה למנוע מצבים כאלו, וכמו כן לעבוד בצורה מאוד נוחה כשנרצה להוסיף \ לעדכן \ להסיר ספריות קוד חיצוניות לפרוייקט.
הניהול של המערכת הזו מתבצע ע"י קובץ ה-POM.xml אותו הזכרנו בשלבים הקודמים של פוסט זה ונרחיב עליו יותר בחלק ב' של הפוסט.
מחזור החיים – Life Cycle:
מחזור החיים של מייבן כולל בתוכו כמה שלבים "עליונים" ועוד תתי שלבים שלרוב ניקח אותם כ-"מובן מאליו".
כל שלב במחזור החיים מכיל בתוכו כבר את השלבים הקודמים, תוכלו לראות בתמונה הבאה:
למשל כשארצה להריץ את הפקודה: mvn validate , המייבן יוודא את תקינותו של הפרוייקט וכשאקרא לפקודה mvn compile הוא קודם ייוודא את תקינותו של הפרוייקט (ע"י שלב ה-validate) ואח"כ יקמפל את הקוד שיושב תחת ספריית src.
פקודת ה-test מאוד חשובה לנו אנשי האוטומציה כי זוהי הפקודה בה אנו מריצים את הטסטים שלנו, למעשה השלבים הבאים הם מאוד חשובים עבור מפתחי המוצר, אך במידה והמוצר שלנו הינו אוטומציה ואין לנו צורך לדלוור אותו ללקוחות, השימוש ב-test יספק את צרכינו.
עד כאן להפעם לחלק זה, בחלק הבא נראה איך אנחנו משתמשים ב-Maven לפרוייקט האוטומציה שלנו.
