שומרים על השומרים: בניית שער איכות לפני מיזוג (Pre-Merge) למסגרת האוטומציה שלכם ב-TypeScript

הקדמה: פרדוקס האוטומציה

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

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

במאמר קודם, פירטתי כיצד לבנות תהליך pre-merge עבור פרויקט Selenium/Python. היום, ניקח את הפילוסופיה הזו ונחיל אותה על סטאק מודרני: Playwright, TypeScript, ו-GitHub Actions. זה לא רק עניין של כלים שונים; זוהי גישה יותר משולבת וממוקדת לאיכות.

מדריך זה מבוסס על תהליך ה-CI/CD מפרויקט Playwright-TypeScript-Example שלי ב-GitHub.

למה פרויקט האוטומציה שלך זקוק לשער איכות משלו

סקירות קוד ידניות אינן מספיקות. מסגרת אוטומציה היא מוצר תוכנה קריטי למשימה בפני עצמו. מגיעה לה אותה רמת הגנה כמו לאפליקציה הראשית שלנו. תהליך חזק לפני מיזוג (pre-merge) לפרויקט האוטומציה שלך משיג שלוש מטרות קריטיות:

1. הגנה על ה-CI/CD שלך: הוא מבטיח שמסגרת בדיקה שבורה לעולם לא תגיע לענף הראשי, ומונע כשלים קטסטרופליים של הרגרסיות הליליות שלך.
2. אכיפת סטנדרטים: הוא מבצע אוטומציה של עיצוב קוד, לינטינג ושיטות עבודה מומלצות, ומשחרר את סקירות הקוד שלך להתמקד בלוגיקה ובארכיטקטורה, לא בוויכוחי סגנון.
3. בניית ביטחון: הוא נותן לכל תורם את הביטחון לבצע שינויים, בידיעה שיש רשת ביטחון שתתפוס טעויות בסיסיות לפני שהן הופכות לבעיות גדולות.

בניית השער: מדריך צעד-אחר-צעד עם GitHub Actions

שער האיכות שלנו הוא workflow של GitHub Actions שרץ על כל Pull Request המכוון לענף main. זוהי סדרה של בדיקות אוטומטיות שחייבות לעבור לפני שניתן למזג קוד כלשהו.

את קובץ ה-YAML המלא של ה-workflow ניתן למצוא כאן.

שלב 1: הטריגר – מתי להפעיל את השער?

אנו מגדירים את ה-workflow לרוץ רק כאשר זה חשוב: על כל PR שנוגע בקבצים קריטיים.

on:
  pull_request:
    branches: [main]
    paths:
      - '''**/*.ts'''
      - '''package.json'''
      - '''playwright.config.ts'''
      - '''.github/workflows/devRun.yml'''

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

שלב 2: הסביבה – עקביות היא המפתח

אנו מריצים את כל ה-workflow שלנו בתוך קונטיינר המשקף את סביבת הבדיקות שלנו בפרודקשן.

container:
  image: mcr.microsoft.com/playwright:v1.54.2

זה מבטל את בעיית “זה עובד על המחשב שלי”. אם זה עובר כאן, זה יעבור בריצה הלילית.

שלב 3: הבדיקות – מסגנון ועד שפיות

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

1. התקנת תלויות: אנו משתמשים ב-pnpm install --frozen-lockfile כדי להבטיח שהתלויות מותקנות בדיוק כפי שהן מוגדרות בקובץ הנעילה. זה מונע עדכוני חבילות בלתי צפויים מלשבור את ה-build.
2. (אופציונלי אך מומלץ) לינטינג ועיצוב: עוד לפני הרצת בדיקה, אנו יכולים להוסיף שלבים להרצת ESLint ו-Prettier. זה תופס בעיות סגנון ובאגים פוטנציאליים עוד לפני הפעלת דפדפן.
3. בדיקת השפיות (Sanity Test): זהו השלב הקריטי ביותר. אנו מריצים בדיקת E2E קטנה, מהירה ואמינה במיוחד. תפקידה היחיד הוא לאשר שהליבה של המסגרת פונקציונלית.

בדיקת השפיות שלנו (@devRun):

test(
  "get started link",
  { tag: "@devRun" },
  async ({ page, homePage }) => {
    // בדיקה זו אינה בודקת זרימה עסקית מורכבת.
    // היא בודקת אם המסגרת יכולה:
    // 1. להפעיל דפדפן.
    // 2. לנווט לדף.
    // 3. לתקשר עם אלמנט בסיסי.
    // 4. לבצע טענה פשוטה.
    await page.goto("/");
    await homePage.clickGetStarted();
    await expect(
      page.getByRole("heading", { name: "Installation" })
    ).toBeVisible();
  },
);

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

שלב 4: לולאת המשוב – דיווח

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

התמונה הגדולה: זה אינו שער איכות למוצר

חיוני להבין את ההבחנה:

• שער לפני מיזוג לאוטומציה (מה שבנינו זה עתה): שומר על מסגרת האוטומציה עצמה. הוא עונה על השאלה: “האם קוד הבדיקות שלנו בריא?”. הוא יכול לרוץ מול כל סביבה יציבה (Dev או Canary).
• שער האיכות של המוצר (הרמה הבאה): שומר על האפליקציה. זה דורש התקנה מורכבת הרבה יותר, עם סביבות דינמיות לפי דרישה עבור כל PR, נושא לדיון עתידי ומעמיק יותר.

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

מסקנה

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

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