אוטומציית בדיקות - כיצד ליצור תשתית אוטומציה עצמאית באמצעות GitHub Actions

מבוא

במאמר זה, אסביר כיצד לבנות תשתית אוטומציה עצמאית באמצעות GitHub actions.

מאמר זה משתמש ב-Java כדי לתאר את תהליך הארכיטקטורה. בשפות תכנות אחרות, למונחים module ו-project עשויות להיות משמעויות שונות, לדוגמה, ב-C# מודול (module) מקביל לפרויקט (project) ופרויקט (project) מקביל ל-solution.

בואו נבחן שלוש גישות ליצירת תשתית אוטומציה:

תשתית ובדיקות נמצאות באותו מודול באותו פרויקט

זוהי הגישה הפשוטה והישירה ביותר, ומשמעותה היא שאין הפרדת אחריות (separation of concerns) בין הבדיקות האוטומטיות שלנו לתשתית האוטומציה. החלוקה עשויה להיות לחבילות (packages) או מחלקות (classes) שונות, או שלא תהיה חלוקה כלל. גישה זו מתאימה לפרויקטי אוטומציה קטנים המתמקדים בתחום יחיד (למשל, רק UI או מובייל) ובפלטפורמה יחידה (למשל, נקודת כניסה יחידה לאפליקציה הנבדקת).

יתרונות:

• זו הדרך המהירה ביותר להתחיל את פרויקט האוטומציה שלכם.

חסרונות:

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

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

תשתית ובדיקות נמצאות במודולים שונים באותו פרויקט

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

יתרונות:

• היא מאפשרת הפרדה (decoupling) של התשתית שלנו מהבדיקות.

חסרונות:

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

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

תשתית ובדיקות נמצאות בפרויקטים שונים

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

יתרונות:

• היא מאפשרת הפרדה (decoupling) של התשתית שלנו מהבדיקות.
• רק מפתחים בעלי הרשאות יכולים לשנות את התשתית.

חסרונות:

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

לאחר שכיסינו את ההיבטים התיאורטיים, בואו נצלול לפרטים הטכניים של יישום הגישה האחרונה:

הכלים הטכנולוגיים המשמשים למימוש הפתרון הם:

שפת תכנות: Java

כלי בנייה (Build tool): Maven

קישור לפרויקט.

מהם GitHub Actions?

לפי מאמר זה:

GitHub Actions הוא API של סיבה ותוצאה ב-GitHub: תזמור כל זרימת עבודה (workflow), המבוסס על כל אירוע, בזמן ש-GitHub מנהלת את הביצוע, מספקת משוב עשיר ומאבטחת כל שלב בדרך. עם GitHub Actions, זרימות עבודה ושלבים הם פשוט קוד בפרוייקט, כך שתוכלו ליצור, לשתף, לעשות שימוש חוזר ולבצע פיצול (fork) לפרקטיקות פיתוח התוכנה שלכם.

GitHub Actions הם בחינם ותומכים בפרוייקטים ציבוריים. המאמר יודגם באמצעות הפרוייקט הציבורי שלי, המכיל מתודה סטטית יחידה שפשוט אומרת שלום :)

מימוש הפתרון

עלינו ליצור תיקיית .github בשורש הפרויקט שלנו, ובתוכה ליצור תיקיית workflows. בתוכה, ניצור את זרימות העבודה שלנו, שהן קבצי YAML.

זהו תוכן זרימת העבודה:

name: Publish package to GitHub Packages

on:
  release:
    types: [created]

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-java@v1
        with:
          java-version: 1.8
      - name: Publish package
        run: mvn --batch-mode deploy
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

הסבר מפורט (Walkthrough)

אנו מריצים את זרימת העבודה לאחר יצירת שחרור (release)

on:
  release:
    types: [created]

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

runs-on: ubuntu-latest

כעת סדרה של שלבי זרימת עבודה מבוצעים לפי הסדר:

• ביצוע checkout לקוד העדכני ביותר עם הפעולה הבאה:

- uses: actions/checkout@v2

• התקנת JDK גרסה 8 עם הפעולה הבאה:

- uses: actions/setup-java@v1
  with:
    java-version: 1.8

• השלב האחרון בזרימת העבודה דוחף (pushes) את החבילה (package) ל-GitHub packages עם הפעולה הבאה:

- name: Publish package
  run: mvn --batch-mode deploy
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

שימו לב שאנו משתמשים ב-GitHub token שלנו כמשתנה סביבה כדי ששלב זה יעבוד.

קובץ ה-pom.xml שלנו מכיל תגית מיוחדת בשם “distributionManagement” המצביעה על הפרוייקט שלנו

<distributionManagement>
    <repository>
        <id>github</id>
        <name>GitHub nirtal85 Apache Maven Packages</name>
        <url>https://maven.pkg.github.com/nirtal85/githubPackageExample</url>
    </repository>
</distributionManagement>

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

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

נצטרך לעדכן את קובץ ה-settings.xml המקומי שלנו, הממוקם בתיקיית ה-.m2, עם כתובת ה-URL של הפרוייקט שלנו, שם המשתמש שלנו ב-GitHub, וטוקן אישי שעלינו ליצור.

<?xml version="1.0" encoding="UTF-8"?>
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
    <activeProfiles>
        <activeProfile>github</activeProfile>
    </activeProfiles>
    <profiles>
        <profile>
            <id>github</id>
            <repositories>
                <repository>
                    <id>central</id>
                    <url>https://repo1.maven.org/maven2</url>
                </repository>
                <repository>
                    <id>github</id>
                    <url>https://maven.pkg.github.com/nirtal85/githubPackageExample</url>
                    <snapshots>
                        <enabled>true</enabled>
                    </snapshots>
                </repository>
            </repositories>
        </profile>
    </profiles>
    <servers>
        <server>
            <id>github</id>
            <username>USERNAME</username>
            <password>TOKEN</password>
        </server>
    </servers>
</settings>

כעת בפרויקטי בדיקה אחרים, נוכל להשתמש בחבילת תשתית האוטומציה כתלות (dependency) בקובץ ה-pom.xml:

<dependency>
    <groupId>github.nirtal85</groupId>
    <artifactId>automation-infra</artifactId>
    <version>0.1</version>
</dependency>

ולהשתמש במתודה sayHello כדי לקבל ברכה מפרויקט התשתית :)

infra.CommonOperations.sayHello();

לסיכום

במאמר זה, סקרנו את יצירתה של תשתית אוטומציה עצמאית באמצעות GitHub actions, Java ו-Maven. כמה חלופות בולטות למימוש פתרון זה עבור Java הן JFrog Artifactory ו-שרת Nexus.

קריאה נוספת על תכונות GitHub actions ניתן למצוא בקישור זה.

בדיקות מהנות!