פיתוח ובדיקה של אפליקציות Node.js

בדף הזה מוסבר איך להשתמש ב-Cloud Build כדי ליצור ולבדוק Node.jsאפליקציות, לאחסן ארטיפקטים של גרסאות build במאגר npm ב-Artifact Registry וליצור מידע על אישור המקור של Build.

באמצעות Cloud Build אפשר להשתמש בכל קובץ אימג' של קונטיינר שזמין לכולם כדי להריץ את המשימות. קובץ האימג' הציבורי node מ-Docker Hub מגיע עם הכלי npm שכבר מותקן בו. אתם יכולים להגדיר את Cloud Build כך שיבנה את פרויקט Node.js באמצעות הכלי הזה.

לפני שמתחילים

ההוראות בדף הזה מניחות שאתם מכירים את Node.js. בנוסף:

בנייה באמצעות npm

כדי להריץ את המשימות שלכם בתמונה node מ-Docker Hub, מציינים את כתובת ה-URL של התמונה בשדה name בקובץ ההגדרות של Cloud Build. ‫Cloud Build מפעיל את הקונטיינר שצוין בשדה name באמצעות נקודת הכניסה שמוגדרת כברירת מחדל בתמונה. כדי לשנות את נקודת הכניסה שמוגדרת כברירת מחדל ולהגדיר איך שלב הבנייה יפעל כשהוא יופעל, מוסיפים שדה entrypoint לשלב הבנייה. קובץ האימג' node ב-Docker Hub מגיע עם הכלי npm שכבר מותקן מראש. מציינים את הכלים בשדה entrypoint כדי להפעיל אותם כנקודת הכניסה של שלב הבנייה.

בקובץ התצורה הבא של ה-build:

  • השדה name מציין ש-Cloud Build משתמש בתמונה node מ-Docker Hub כדי להפעיל את המשימה. כשמציינים את node התמונה, אפשר להשמיט את גרסת הצומת כדי להשתמש בגרסת ברירת המחדל :latest, או לציין גרסת צומת כדי להשתמש בגרסה ספציפית. לדוגמה, הפקודה name: node תשתמש בגרסה העדכנית ביותר של node, והפקודה name: node:12 תשתמש ב-node:12.
  • השדה entrypoint מציין שהכלי npm נמצא בשימוש כשמפעילים את התמונה node.

     steps:
     - name: 'node'
       entrypoint: 'npm'
    

הגדרת בנייה של Node.js

  1. בתיקיית השורש של הפרויקט, יוצרים קובץ הגדרות בשם cloudbuild.yaml.

  2. התקנת יחסי תלות: לפני שיוצרים את האפליקציה, צריך לוודא שכל יחסי התלות של הפרויקט מותקנים מ-npm. אפשר להתקין יחסי תלות באמצעות הפקודה install בשלב npm build. השדה args של שלב בנייה מקבל רשימה של ארגומנטים ומעביר אותם לתמונה שאליה מתייחס השדה name. בקובץ הגדרות ה-build, מוסיפים את install לשדה args כדי להפעיל את הפקודה install:

     steps:
     - name: 'node'
       entrypoint: 'npm'
       args: ['install']
    
  3. הוספת בדיקות: אם הגדרתם סקריפט test ב-package.json, אתם יכולים להגדיר את Cloud Build להפעיל את הסקריפט על ידי הוספת test לשדה args:

     steps:
     - name: 'node'
       entrypoint: 'npm'
       args: ['install']
     - name: 'node'
       entrypoint: 'npm'
       args: ['test']
    
  4. הפעלת פקודות בהתאמה אישית: אם הקובץ package.json מכיל פקודות בהתאמה אישית, אפשר להגדיר את Cloud Build להפעלת הפקודה הזו. בשדה args מוסיפים run כארגומנט הראשון ואחריו את השם של הפקודה המותאמת אישית. בקובץ התצורה הבא של ה-build יש ארגומנטים להרצת פקודה בהתאמה אישית בשם build:

     steps:
     - name: 'node'
        entrypoint: 'npm'
        args: ['install']
     - name: 'node'
        entrypoint: 'npm'
        args: ['test']
     - name: 'node'
        entrypoint: 'npm'
        args: ['run', 'build']
    
  5. העלאה אל Artifact Registry:

    בקובץ ההגדרות, מוסיפים את השדה npmPackages ומציינים את מאגר ה-npm ב-Artifact Registry:

     artifacts:
        npmPackages:
        - repository: 'https://LOCATION-npm.pkg.dev/PROJECT-ID/REPOSITORY_NAME'
          packagePath: 'PACKAGE_PATH'
    

    מחליפים את הערכים הבאים:

    • LOCATION: המיקום של המאגר ב-Artifact Registry.
    • PROJECT_ID: מזהה Google Cloud הפרויקט שמכיל את מאגר Artifact Registry.
    • REPOSITORY_NAME: השם של מאגר npm ב-Artifact Registry.
    • PACKAGE_PATH: הנתיב לספרייה המקומית שמכילה את חבילת ה-npm שרוצים להעלות ל-Artifact Registry. מומלץ להשתמש בנתיב מוחלט. PACKAGE_PATH הערך יכול להיות . כדי להשתמש בספריית העבודה הנוכחית, אבל אי אפשר להשמיט את השדה או להשאיר אותו ריק. הספרייה הזו חייבת להכיל קובץ package.json.
  6. אופציונלי: הפעלת יצירת שיוך מקור

    ‫Cloud Build יכול ליצור מטא נתונים של מקורות build שניתנים לאימות של Supply chain Levels for Software Artifacts‏ (SLSA) כדי לעזור לכם לאבטח את צינור השילוב הרציף שלכם.

    כדי להפעיל את יצירת המקור, מוסיפים את השורה requestedVerifyOption: VERIFIED לקטע options בקובץ ההגדרות.

  7. מתחילים את ה-build: באופן ידני או באמצעות טריגרים של build.

    אחרי שהבנייה מסתיימת, אפשר לראות את פרטי המאגר ב-Artifact Registry.

    אפשר גם לראות את המטא-נתונים של מקור ה-build ולאמת את המקור.

הרצת בדיקות על כמה גרסאות של node

לפעמים צריך לוודא שהפרויקט פועל בכמה גרסאות של node. אתם יכולים ליצור ולהגדיר טריגרים של Cloud Build כך ש:

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

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

  1. בשורש המאגר, מוסיפים קובץ הגדרות build שמציין את nodeversion כמשתנה החלפה. בדוגמה הבאה של קובץ הגדרות build, ‏ $_NODE_VERSION הוא משתנה החלפה שהוגדר על ידי המשתמש:

     steps:
     - name: 'node:$_NODE_VERSION'
       entrypoint: 'npm'
       args: ['install']
     - name: 'node:$_NODE_VERSION'
       entrypoint: 'npm'
       args: ['test']
    
  2. לכל גרסה של node שרוצים לבצע בשבילה build, יוצרים טריגר לפיתוח גרסת Build באמצעות השלבים הבאים:

    1. פותחים את הדף Triggers במסוף Google Cloud :

      פתיחת הדף Triggers

    2. בוחרים את הפרויקט מהתפריט הנפתח לבחירת פרויקט בחלק העליון של הדף.

    3. לוחצים על פתיחה.

    4. לוחצים על Create trigger (יצירת ביטוי להפעלה).

      בדף Create trigger, מזינים את ההגדרות הבאות:

      1. מזינים שם לטריגר.

      2. בוחרים את אירוע המאגר כדי להפעיל את הטריגר.

      3. בוחרים את המאגר שמכיל את קובץ ההגדרות של קוד המקור וה-build.

      4. מציינים את הביטוי הרגולרי לשם הענף או התג שיפעיל את הטריגר.

      5. Configuration: בוחרים את קובץ הגדרות ה-build שיצרתם קודם.

      6. בקטע משתני החלפה, לוחצים על הוספת משתנה.

        1. בקטע Variable (משתנה), מציינים את משתנה הגרסה node שבו השתמשתם בקובץ הגדרות ה-build, ובקטע Value (ערך), מציינים את הגרסה של node. לדוגמה, _NODE_VERSION ו-12.
    5. לוחצים על יצירה כדי לשמור את טריגר לפיתוח גרסת Build.

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

המאמרים הבאים