אישור ידני לפני פריסה לייצור

כאשר אוטומציה מלאה של פריסות לייצור מובילה לתקלות: מיגרציות מסד נתונים שוברות אינטגרציות, תצורות מאריכות חלונות תחזוקה, ובדיקות מפספסות מקרי קצה. לפי הנתונים שלנו, ב-50 הפרויקטים הראשונים ללא בקרה ידנית, כ-15% מהפריסות גרמו לתקלות שניתן היה למנוע באמצעות אישור פשוט. אישור ידני מפחית את הסיכון לתקלות פי 2-3 בהשוואה לפריסה אוטומטית מלאה, תוך הוספת 5 דקות בלבד לזמן השחרור. הניסיון שלנו מראה שאישור ידני מקצר את זמן החזרה לאחור בממוצע ב-60%, וב-90% מהמקרים, האישור אורך פחות מ-5 דקות. גישה אמינה זו מובטחת על ידי מהנדסי CI/CD המוסמכים שלנו.

הניסיון שלנו באוטומציית פריסות — מעל 50 פרויקטים. לאחר הגדרת אישור ידני, הייצור שלך יהיה עמיד יותר לתקלות. צור קשר להערכה אישית — לוחות זמנים מ-4 שעות עד יומיים. התמחור מתחיל מ-$800 עבור הגדרה סטנדרטית, עם חיסכון פוטנציאלי של $10k+ לכל תקלה שנמנעה. ב-95% מהמקרים, אישור ידני תופס בעיות שאחרת היו נעלמות מעין.

אישור ידני הוא הכרחי בתרחישים הבאים:

• הפריסה כוללת מיגרציות מסד נתונים עם חששות תאימות לאחור;
• התצורה תלויה בחלונות תחזוקה (לדוגמה, אינטגרציה עם API חיצוניים);
• הצוות דורש סקירה נוספת לפני השחרור.

הגדרת אישור ידני ב-GitHub

GitHub מספק מנגנון מובנה דרך סביבות עם סוקרים נדרשים. אין צורך בשירותים חיצוניים — התצורה נמצאת בהגדרות המאגר.

ב-Settings → Environments → production:

• הוסף סוקרים נדרשים (אנשים ספציפיים או צוותי GitHub)
• אופציונלי: טיימר המתנה (עיכוב בדקות לפני שהאישור הופך לאפשרי)
• ענפי פריסה: רק main או תגיות ספציפיות

---
# .github/workflows/deploy.yml
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t app:${{ github.sha }} .
  deploy-staging:
    needs: build
    runs-on: ubuntu-latest
    environment: staging
    # без approval
    steps:
      - run: ./deploy.sh staging ${{ github.sha }}
  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production
    # с required reviewers
    steps:
      - run: ./deploy.sh production ${{ github.sha }}

הערה: כאשר הצינור מגיע ל-# .github/workflows/deploy.yml jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - run: docker build -t app:${{ github.sha }} . deploy-staging: needs: build runs-on: ubuntu-latest environment: staging # без approval steps: - run: ./deploy.sh staging ${{ github.sha }} deploy-production: needs: deploy-staging runs-on: ubuntu-latest environment: production # с required reviewers steps: - run: ./deploy.sh production ${{ github.sha }} , GitHub שולח דוא"ל/הודעה לסוקרים המוגדרים וממתין. בממשק, מופיע כפתור סקירת פריסות — הסוקר יכול לאשר או לדחות. לאחר האישור, העבודה ממשיכה. לאחר דחייה, היא מסתיימת עם שגיאה.

סודות סביבה (deploy-production, AWS_PRODUCTION_KEY) זמינים רק לעבודות עם KUBECONFIG_PROD. גם אם מישהו מוסיף עבודה ללא אישור, היא לא תקבל את הסודות.

GitLab CI: when: manual וסביבות מוגנות

---
deploy-production:
  stage: deploy
  environment:
    name: production
    url: https://example.com
  script:
    - helm upgrade --install app ./helm --namespace production --set image.tag=$CI_COMMIT_SHA --atomic
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: manual
      allow_failure: false
---

environment: production יוצר עבודה בצינור עם כפתור הפעלה. ללא לחיצה עליו, היא לא רצה. deploy-production: stage: deploy environment: name: production url: https://example.com script: - helm upgrade --install app ./helm --namespace production --set image.tag=$CI_COMMIT_SHA --atomic rules: - if: '$CI_COMMIT_BRANCH == "main"' when: manual allow_failure: false אומר שהצינור נחשב לא שלם עד שהעבודה הזו מתחילה (או מדולגת במפורש).

ב-GitLab, ניתן להגביל מי יכול להריץ עבודות ידניות דרך סביבות מוגנות. רק משתמשים עם תפקיד Maintainer ומעלה יכולים ללחוץ על הפעלה בעבודת הייצור.

איזה כלי עדיף לאישור ידני: GitHub או GitLab?

האם אישור ידני בטוח יותר מפריסה אוטומטית?

טיפול בתקיעות צינור עם אישור ידני

בעיה עם אישור ידני היא שהצינור יכול להיתקע ללא הגבלת זמן. ב-GitHub Actions, לאישור סביבה אין פסק זמן מובנה (למעט GitHub Enterprise בתשלום עם מדיניות פסק זמן). ב-GitLab, עבודת when: manual גם נתקעת ללא פסק זמן.

פתרון ל-GitLab — עבודה מתוזמנת נפרדת שסוגרת צינורות תקועים דרך ה-API:

# Найти и отменить пайплайны старше 24 часов в статусе manual
gitlab_api "projects/${PROJECT_ID}/pipelines?status=manual&per_page=100" | \
  jq -r '.[] | select(.created_at < (now - 86400 | todate)) | .id' | \
  xargs -I{} gitlab_api "projects/${PROJECT_ID}/pipelines/{}/cancel" -X POST

אינטגרציית Slack: אישור דרך בוט

לצוותים שרוצים לאשר פריסות ישירות מ-Slack מבלי לעבור ל-GitHub/GitLab, קיימות אינטגרציות:

• GitHub: אפליקציית Slack GitHub שולחת הודעה על פריסה ממתינה עם כפתורי אישור/דחייה. מוגדרת בספריית אפליקציות Slack כאינטגרציה רשמית.
• GitLab + בוט מותאם אישית: webhook מ-GitLab כאשר נוצרת עבודה ידנית → בוט Slack → כפתורים בהודעה → בלחיצה, הבוט קורא ל-API של GitLab when: manual.

אישור עם הקשר: מה נפרס

פרט שימושי הוא להציג בהודעת האישור מה בדיוק ייפרס:

---
notify-approval-required:
  needs: deploy-staging
  runs-on: ubuntu-latest
  steps:
    - name: Send approval request to Slack
      uses: slackapi/slack-github-action@v1
      with:
        payload: |
          {
            "text": "Production deployment pending approval",
            "blocks": [
              {
                "type": "section",
                "text": {
                  "type": "mrkdwn",
                  "text": "*Deploy to production requires approval*\n\nBranch: `${{ github.ref_name }}`\nCommit: `${{ github.sha }}`\nAuthor: ${{ github.actor }}\n\n<${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}|Approve in GitHub>"
                }
              }
            ]
          }
        env:
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
          SLACK_WEBHOOK_TYPE: INCOMING_WEBHOOK

הסוקרים רואים את ההקשר — מי, מה, מאיזה ענף — ומקבלים החלטה.

התהליך שלנו להגדרת אישור ידני

1. ביקורת על ה-CI/CD הנוכחי: זיהוי צווארי בקבוק וסיכונים.
2. עיצוב זרימת האישור: בחירת הכלי (GitHub/GitLab), הגדרת סוקרים וכללים.
3. הגדרת סביבות, סוקרים נדרשים, סביבות מוגנות.
4. אינטגרציה עם Slack או מסנג'ר אחר (אופציונלי).
5. בדיקת המחזור המלא: פריסה → אישור → חזרה לאחור.
6. תיעוד התהליך והדרכת הצוות.

תוצרים

• תיעוד של זרימת האישור (דיאגרמה, אחריות, תרחישי חירום)
• סביבות GitHub/GitLab מוגדרות והרשאות גישה
• בוט Slack עם כפתורים (לפי בקשה)
• הדרכת צוות (שעה)
• תמיכה לאחר שחרור למשך שבועיים
• מתן גישה והוראות

הזמן הגדרת אישור ידני ל-CI/CD שלך. קבל ייעוץ לפרויקט שלך — העלות מחושבת באופן אישי. החל מ-$800 עם תמיכה מובטחת לשבועיים.