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
- תמיכה במהלך החודש הראשון לאחר ההשקה
תהליך העבודה
- ניתוח—ביקורת תשתית, איסוף דרישות, הגדרת מדדי הצלחה.
- עיצוב—ארכיטקטורת pipeline, תכנית גישה מאובטחת, אסטרטגיית פריסה (rolling, blue-green, canary).
- יישום—פריסת Delegate, הגדרת Connector, יצירת Pipeline עם CI, CD, Verify.
- בדיקות—אימות חזרה לגרסה קודמת, זיהוי חריגות, בדיקות עומס.
- פריסה—מעבר לייצור, הכשרה, העברת תיעוד.
לוחות זמנים משוערים
| היקף | לוח זמנים |
|---|---|
| הגדרה בסיסית + שירות אחד | 2-3 ימים |
| מספר שירותים + CV + Vault | 4-6 ימים |
| הגדרה ארגונית עם מספר clusters | 6-10 ימים |
העלות נקבעת באופן אישי לאחר ביקורת תשתית. צרו קשר להערכת פרויקט—קבלו ייעוץ מהנדס. אנחנו מבטיחים יציבות pipeline וזמן חזרה מינימלי לגרסה קודמת.
טעויות נפוצות בהגדרת Harness
- הגדרת healthSources שגויה—מדדים לא מגיעים, אימות לא מופעל.
- רגישות נמוכה מדי—חריגות מתפספסות.
- חוסר ב-rollbackSteps בשלב CD—הפריסה לא חוזרת לגרסה קודמת במקרה שגיאה.
- Delegate ללא הרשאות מספקות—לא יכול לבצע פעולות cluster.
- התעלמות מקו בסיס—אם קו הבסיס בנוי על נתונים לא מייצגים, ה-ML מפעיל אזעקות שווא.
הזמינו יישום Harness מהצוות שלנו. קבלו ייעוץ מהנדס והערכת לוח זמנים לפרויקט שלכם.







