הגדרת ארטיפקטים ב-CI/CD: GitLab ו-GitHub

לעיתים קרובות אנו רואים צוותים שמבזבזים שעות על בנייה מחדש של ארטיפקטים עקב תצורת CI/CD שגויה. במקום להעביר בינארי מהודר בין ג'ובים, הם מריצים מחדש את כל שלבי הבנייה. התוצאה: זמן הפייפסליין גדל והמפתחים ממתינים. תצורת ארטיפקטים שגויה מובילה לעלויות מיותרות של דקות CI ולבזבוז זמן מפתחים. במאמר זה נסקור את תצורת הארטיפקטים ב-CI/CD עבור GitLab CI ו-GitHub Actions.

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

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

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

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

טבלת השוואה:

כיצד ארטיפקטים מאיצים את הפייפסליין?

תצורת ארטיפקטים נכונה מאפשרת בניית פייפסליינים מסוג DAG שבהם ג'ובים מתחילים מיד לאחר קבלת הארטיפקטים הדרושים, ללא המתנה לסיום שלב שלם. כתוצאה מכך, זמן הביצוע מופחת ב-30–70%. לדוגמה, בפרויקט אחד החלפנו פייפסליין ליניארי ב-DAG באמצעות העברת ארטיפקטים—הפייפסליין רץ ב-8 דקות במקום 25. החיסכון החודשי הממוצע הסתכם ב-$630–910 עקב הפחתת עלויות דקות CI.

כיצד להגדיר ארטיפקטים ב-GitLab CI?

---
build:
  stage: build
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/
      - package.json
    expire_in: 1 hour
    when: always
test:
  stage: test
  needs:
    - job: build
      artifacts: true
  script:
    - npm run test
  artifacts:
    reports:
      junit: reports/junit.xml
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml
deploy:
  stage: deploy
  needs:
    - job: build
      artifacts: true
  script:
    - rsync -av dist/ user@server:/var/www/app/

build: stage: build script: - npm ci - npm run build artifacts: paths: - dist/ - package.json expire_in: 1 hour when: always test: stage: test needs: - job: build artifacts: true script: - npm run test artifacts: reports: junit: reports/junit.xml coverage_report: coverage_format: cobertura path: coverage/cobertura-coverage.xml deploy: stage: deploy needs: - job: build artifacts: true script: - rsync -av dist/ user@server:/var/www/app/ עם needs—הג'וב artifacts: true מוריד ארטיפקטים מ-deploy ללא המתנה לשלבי ביניים. זהו פייפסליין DAG—אלטרנטיבה מהירה יותר לשלבים ליניאריים. פרטים נוספים בתיעוד GitLab CI.

כיצד להעביר ארטיפקטים ב-GitHub Actions?

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build
      - uses: actions/upload-artifact@v4
        with:
          name: frontend-dist-${{ github.sha }}
          path: dist/
          retention-days: 1
          if-no-files-found: error
  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: frontend-dist-${{ github.sha }}
          path: dist/
      - run: ./scripts/deploy.sh dist/

build הוא הגדרה חשובה. כברירת מחדל, ההעלאה מצליחה גם אם אין קבצים, והג'וב הבא מוריד ארטיפקט ריק. עדיף להיכשל במפורש. jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - run: npm ci && npm run build - uses: actions/upload-artifact@v4 with: name: frontend-dist-${{ github.sha }} path: dist/ retention-days: 1 if-no-files-found: error deploy: needs: build runs-on: ubuntu-latest steps: - uses: actions/download-artifact@v4 with: name: frontend-dist-${{ github.sha }} path: dist/ - run: ./scripts/deploy.sh dist/ עבור ארטיפקטי בנייה ביניים—הם נדרשים רק בתוך הפייפסליין הזה. עבור ארטיפקטי שחרור, הגדר תקופה ארוכה יותר. פרטים נוספים בתיעוד GitHub Actions.

השוואה בין GitLab CI ל-GitHub Actions

מתי להשתמש באחסון חיצוני?

עבור ארטיפקטים הנדרשים מחוץ לפייפסליין יחיד—בינאריים לשחרור, תמונות Docker, חבילות npm—אחסון CI אינו מתאים. כאן יש צורך באחסון חיצוני:

• GitHub Releases / GitLab Releases—ארטיפקטים המצורפים לתג, נגישים דרך API.
• S3 / GCS—עבור בינאריים וקבצים סטטיים עם גרסאות.
• Nexus / Artifactory—עבור Maven, npm, Docker בתשתית ארגונית.
• Docker Registry—תמונות עם תגי git SHA ו/או תג semver.

פרסום ל-Nexus מ-GitLab CI:

---
publish:
  stage: publish
  needs:
    - job: build
      artifacts: true
  script:
    - mvn deploy -s .mvn/settings.xml \
        -Dnexus.url=$NEXUS_URL \
        -Dnexus.username=$NEXUS_USER \
        -Dnexus.password=$NEXUS_PASS \
        -DskipTests
  rules:
    - if: '$CI_COMMIT_TAG =~ /^v\d+\.\d+\.\d+/'
---

פריסה ל-Nexus רק על תגים היא מדיניות טובה. אחסון ארטיפקטים באחסון חיצוני מפחית עלויות דקות CI ומפנה מקום ב-CI.

תוכנית הגדרת ארטיפקטים שלב אחר שלב

1. בצע ביקורת על הפייפסליינים הקיימים—זהה את כל המקומות שבהם ארטיפקטים נוצרים ונצרכים.
2. קבע אילו ארטיפקטים נדרשים—הפרד בין ביניים (dist/, reports/) לסופיים (בינארי שחרור).
3. הגדר artifacts/upload-artifact—קבע נתיבים נכונים, תקופות שמירה ותנאי שמירה.
4. שלב עם אחסון חיצוני—חבר S3, Nexus או Docker Registry לאחסון ארוך טווח.
5. בדוק ונטר—ודא שהארטיפקטים מועברים כראוי, הגדר התראות על ארטיפקטים ריקים.

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

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

• ביקורת פייפסליין: אילו ארטיפקטים נוצרים, כמה זמן הם חיים, היכן הם מאוחסנים.
• הגדרת artifacts: true / needs: עם git SHA ו-publish: stage: publish needs: - job: build artifacts: true script: - mvn deploy -s .mvn/settings.xml \ -Dnexus.url=$NEXUS_URL \ -Dnexus.username=$NEXUS_USER \ -Dnexus.password=$NEXUS_PASS \ -DskipTests rules: - if: '$CI_COMMIT_TAG =~ /^v\d+\.\d+\.\d+/' אופטימליים.
• אינטגרציה עם אחסון חיצוני (S3, Nexus, Docker Registry) במידת הצורך.
• תיעוד התהליך והמלצות להמשך אופטימיזציה.
• תמיכה לחודש אחד לאחר היישום.

עזרנו לצוותים להפחית את זמן הפייפסליין ב-30–70% באמצעות הגדרת ארטיפקטים נכונה. צור קשר לביקורת פייפסליין—אנו מעריכים את התצורה הנוכחית שלך ביום אחד ומציעים פתרון אופטימלי. הזמן הגדרת ארטיפקטים במפתח אחד והתחל לחסוך זמן ותקציב היום.

טעויות נפוצות בהגדרת ארטיפקטים

• תקופת שמירה ארוכה מדי: artifacts סותם את האחסון. הגדר מגבלות סבירות.
• חסר upload-artifact ב-GitHub Actions—השלב הבא עלול לפרוס בשקט ארטיפקט ריק.
• העברת תלויות במקום תוצאות: שמור קאש expire_in בנפרד, אל תגרור אותם כארטיפקטים.