רתמת Harness ל-CI/CD: פריסה והחזרה אוטומטית לאחור על בסיס מדדים

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

היכולות שלנו:

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1359
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

Harness ל-CI/CD: פריסה והחזרה אוטומטית לגרסה קודמת על בסיס מדדים

ראינו את התרחיש הזה: pipeline פורס בהצלחה גרסה חדשה, וחמש דקות לאחר מכן שיעור השגיאות מזנק ב-Prometheus, משתמשים מתלוננים, והמנהל בפאניקה. CI/CD מסורתי לא יכול לחזור לגרסה קודמת בעצמו—רק סקריפטים וטריגרים ידניים. הניסיון שלנו ביישום Harness מראה שהפלטפורמה פותרת את זה: לאחר הפריסה, היא מנתחת מדדים ומפעילה אוטומטית חזרה לגרסה קודמת במקרה של הידרדרות. זה לא רק CI/CD—זו פריסה חכמה עם אימות מתמשך. MTTR (זמן ממוצע לשיקום) יורד משעתיים ל-10 דקות, ועלויות החזרה לגרסה קודמת מופחתות ב-80%.

כיצד פועל אימות מתמשך ב-Harness

לאחר כל פריסה, Harness מריצה שלב Verify אשר, למשך תקופה מוגדרת (למשל, 15 דקות), משווה מדדים חדשים מול קו הבסיס של הגרסה הקודמת. מודלי ML מתחשבים בשעה ביום, יום בשבוע ודפוסים היסטוריים. אם שיעור השגיאות עולה או שהשהייה מתדרדרת מעבר לסף, rollbackSteps מופעלים ללא התערבות אנושית. זה מקצר את ה-MTTR משעות לדקות. בהשוואה ל-Jenkins, שבו חזרה לגרסה קודמת דורשת סקריפטים מותאמים אישית והגדרת ניטור נפרדת, Harness מאיצה את התגובה פי 3–5.

דוגמה להגדרת שלב Verify עם Prometheus:

---
- stage:
    name: Verify Staging
    identifier: verify_staging
    type: Deployment
    spec:
      execution:
        steps:
          - step:
              type: Verify
              name: CV Check
              identifier: cv_check
              spec:
                type: Rolling
                monitoredServiceRef: myapp-staging-monitored
                healthSources:
                  - identifier: prometheus-staging
                    spec:
                      sensitivity: MEDIUM
                      duration: 15m
                      deploymentTag: <+artifacts.primary.tag>

מדוע ה-Delegate חשוב לאבטחה

Harness לא מתחברת ישירות ל-Kubernetes cluster שלך מהענן. במקום זאת, מותקן Delegate—agent בתוך ה-cluster שמקבל משימות מ-Harness Platform ומבצע אותן מקומית. זה פותר את הבעיה של clusters פרטיים ללא גישה ציבורית. ה-Delegate רץ ברשת מבודדת, ללא צורך ביציאות (ports) נכנסות. הוא מתקשקם אופקית ומתעדכן אוטומטית. כל מופע Delegate דורש 2 vCPU ו-4 GB RAM, ותומך בעד 10 משימות מקבילות; לסביבת production, מומלצים לפחות 2 רפליקות.

התקנה דרך Helm:

helm install harness-delegate harness/harness-delegate \
  --namespace harness-delegate-ng \
  --create-namespace \
  --set delegateName=my-delegate \
  --set accountId=$HARNESS_ACCOUNT_ID \
  --set delegateToken=$DELEGATE_TOKEN \
  --set managerEndpoint=https://app.harness.io

מבנה Harness: Pipelines, Stages, Steps

Pipeline ב-Harness מורכב מ-Stages. סוג ה-stage מגדיר את ההקשר: CI, CD, Feature Flags, Approval, Custom.

הגדרה דרך YAML (Harness YAML):

---
pipeline:
  name: myapp-ci-cd
  identifier: myapp_ci_cd
  projectIdentifier: myproject
  orgIdentifier: myorg
  stages:
    - stage:
        name: Build and Test
        identifier: build_and_test
        type: CI
        spec:
          cloneCodebase: true
          platform:
            os: Linux
            arch: Amd64
          runtime:
            type: Cloud
            spec: {}
          execution:
            steps:
              - step:
                  type: Run
                  name: Install and Test
                  identifier: install_and_test
                  spec:
                    connectorRef: docker-hub-connector
                    image: node:20-alpine
                    command: |
                      npm ci
                      npm run lint
                      npm run test -- --coverage
              - step:
                  type: BuildAndPushDockerRegistry
                  name: Build and Push Image
                  identifier: build_push
                  spec:
                    connectorRef: docker-registry-connector
                    repo: registry.example.com/myapp
                    tags:
                      - <+pipeline.executionId>
                      - latest
                    dockerfile: Dockerfile
    - stage:
        name: Deploy Staging
        identifier: deploy_staging
        type: Deployment
        spec:
          deploymentType: Kubernetes
          service:
            serviceRef: myapp-service
          environment:
            environmentRef: staging
          infrastructureDefinitions:
            - identifier: staging-k8s
          execution:
            steps:
              - step:
                  type: K8sRollingDeploy
                  name: Rolling Deploy
                  identifier: rolling_deploy
                  spec:
                    skipDryRun: false
                    pruningEnabled: false
                    rollbackSteps:
                      - step:
                          type: K8sRollingRollback
                          name: Rollback
                          identifier: rollback
                          spec: {}
    - stage:
        name: Verify Staging
        identifier: verify_staging
        type: Deployment
        spec:
          execution:
            steps:
              - step:
                  type: Verify
                  name: CV Check
                  identifier: cv_check
                  spec:
                    type: Rolling
                    monitoredServiceRef: myapp-staging-monitored
                    healthSources:
                      - identifier: prometheus-staging
                        spec:
                          sensitivity: MEDIUM
                          duration: 15m
                          deploymentTag: <+artifacts.primary.tag>

אילו מדדים Harness מנתחת לצורך אימות?

Harness משתלבת עם Prometheus, DataDog, New Relic, Splunk ומערכות ניטור אחרות. כברירת מחדל, היא משתמשת בשיעור שגיאות, השהייה, תעבורה ורוויה—מה שנקרא Golden Signals. מודל ה-ML משווה אותם לקו בסיס היסטורי ומזהה חריגות. לדוגמה, אם שיעור השגיאות עולה ב-5% עם שונות אופיינית של 2%, זה מפעיל חזרה לגרסה קודמת. הרגישות ניתנת לכיוונון דרך פרמטר ה-sensitivity (LOW, MEDIUM, HIGH).

השוואת מדדים לצורך אימות

מדד מקור סף אופייני
שיעור שגיאות Prometheus, DataDog +5% מקו הבסיס
השהייה (p95) Prometheus, DataDog +20% מקו הבסיס
ירידת תעבורה Grafana, CloudWatch -10% תוך 15 דקות

Connectors ו-Secrets

Harness משתמשת ב-Connectors כדי להתחבר למערכות חיצוניות: Docker Registry, Kubernetes, Git, Helm Chart repos. Secrets נשמרים ב-Harness Secrets Manager או מועברים ל-Vault חיצוני:

---
connector:
  name: vault-connector
  identifier: vault_connector
  type: Vault
  spec:
    vaultUrl: https://vault.example.com
    authType: AppRole
    appRoleId: harness-app-role
    secretId: harness-vault-secret
    secretEngine: secret
    secretEngineVersion: 2

לאחר מכן, כל secret מ-Vault זמין ב-pipeline דרך - stage: name: Verify Staging identifier: verify_staging type: Deployment spec: execution: steps: - step: type: Verify name: CV Check identifier: cv_check spec: type: Rolling monitoredServiceRef: myapp-staging-monitored healthSources: - identifier: prometheus-staging spec: sensitivity: MEDIUM duration: 15m deploymentTag: <+artifacts.primary.tag> .

מה כוללת העבודה שלנו

אנחנו מספקים את מחזור היישום המלא של Harness. הניסיון שלנו כולל יותר מ-40 פרויקטים מוצלחים ב-clusters גדולים (10 עד 500 nodes). אנחנו מגדירים pipelines של GitOps, חזרה אוטומטית לגרסה קודמת וניטור פריסות. השירות כולל:

  • ביקורת על התשתית וה-pipelines הקיימים
  • עיצוב ארכיטקטורת CI/CD תוך התחשבות באבטחה ובמדרגיות
  • פריסת Delegate והגדרת Connectors (Docker Registry, K8s, Git, Vault)
  • בניית Pipelines עם שלבי CI, CD ו-Verify
  • אינטגרציה עם ניטור (Prometheus, DataDog, New Relic) לצורך אימות מתמשך
  • תיעוד pipelines ומדריך למפתחים
  • הכשרת צוות על Harness
  • תמיכה במהלך החודש הראשון לאחר ההשקה

תהליך העבודה

  1. ניתוח—ביקורת תשתית, איסוף דרישות, הגדרת מדדי הצלחה.
  2. עיצוב—ארכיטקטורת pipeline, תכנית גישה מאובטחת, אסטרטגיית פריסה (rolling, blue-green, canary).
  3. יישום—פריסת Delegate, הגדרת Connector, יצירת Pipeline עם CI, CD, Verify.
  4. בדיקות—אימות חזרה לגרסה קודמת, זיהוי חריגות, בדיקות עומס.
  5. פריסה—מעבר לייצור, הכשרה, העברת תיעוד.

לוחות זמנים משוערים

היקף לוח זמנים
הגדרה בסיסית + שירות אחד 2-3 ימים
מספר שירותים + CV + Vault 4-6 ימים
הגדרה ארגונית עם מספר clusters 6-10 ימים

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

טעויות נפוצות בהגדרת Harness

  • הגדרת healthSources שגויה—מדדים לא מגיעים, אימות לא מופעל.
  • רגישות נמוכה מדי—חריגות מתפספסות.
  • חוסר ב-rollbackSteps בשלב CD—הפריסה לא חוזרת לגרסה קודמת במקרה שגיאה.
  • Delegate ללא הרשאות מספקות—לא יכול לבצע פעולות cluster.
  • התעלמות מקו בסיס—אם קו הבסיס בנוי על נתונים לא מייצגים, ה-ML מפעיל אזעקות שווא.

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