הגדרת Git לפיתוח מבוסס טראנק

אימוץ פיתוח מבוסס טראנק (Trunk-Based Development) למאגר ה-Git שלך

שלושה מפתחים, שבועיים של עבודה בענפים (branches) נפרדים, יום שישי — וכאוס אינטגרציה: קונפליקטים ב-15 קבצים, בדיקות שבורות, יום אבוד על מיזוג. נשמע מוכר? אנחנו רואים את זה כל הזמן. פיתוח מבוסס טראנק (TBD) פותר את הבעיה באופן קיצוני: כולם מבצעים commit ל-main לפחות פעם ביום, קוד לא גמור מוסתר מאחורי Feature Flags, וענפים ארוכי-חיים נעלמים.

זה נשמע מסוכן. בפועל, זה אמין יותר מ-Git Flow הקלאסי. הניסיון שלנו ביישום TBD בעשרות פרויקטים מראה: תדירות הקונפליקטים יורדת ב-70%, וזמן שחרור הגרסה מתקצר בחצי. תצורות מוכנות, סקריפטים ותיעוד — מוכן לשימוש תוך 1-3 ימים.

למה ענפים ארוכי-חיים הם סיכון, לא ביטחון

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

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

Feature Flags: איך לפרוס קוד לא גמור בבטחה

השאלה המרכזית עם TBD: איך לבצע commit לתכונות לא גמורות ל-main מבלי לשבור את הייצור? התשובה — Feature Flags. קוד חדש עטוף בתנאי שמושבת בייצור:

# Python с Flagsmith или LaunchDarkly
from flagsmith import Flagsmith

flagsmith = Flagsmith(environment_key=os.environ["FLAGSMITH_KEY"])
flags = flagsmith.get_environment_flags()


def process_payment(order):
    if flags.is_feature_enabled("new_payment_flow"):
        return new_payment_processor.process(order)
    else:
        return legacy_payment_processor.process(order)

ה-flag # Python с Flagsmith или LaunchDarkly from flagsmith import Flagsmith flagsmith = Flagsmith(environment_key=os.environ["FLAGSMITH_KEY"]) flags = flagsmith.get_environment_flags() def process_payment(order): if flags.is_feature_enabled("new_payment_flow"): return new_payment_processor.process(order) else: return legacy_payment_processor.process(order) מופעל רק למפתחים (באמצעות מיקוד זהות משתמש) או לסביבות ספציפיות. בייצור, ה-flag כבוי — הקוד הישן עובד כמו קודם. המפתח מבצע commit ל-main מדי יום, CI עובר, הפריסה מתבצעת — התכונה הלא גמורה פשוט לא נגישה למשתמשים.

לתרחישים פשוטים יותר ללא שירותי צד שלישי — משתני סביבה:

ENABLE_NEW_PAYMENT_FLOW = os.environ.get("ENABLE_NEW_PAYMENT_FLOW", "false").lower() == "true" 

בייצור new_payment_flow → ENABLE_NEW_PAYMENT_FLOW = os.environ.get("ENABLE_NEW_PAYMENT_FLOW", "false").lower() == "true" . ב-staging → .env. תקורה מינימלית, ברור לכולם.

ענפים קצרי-חיים: לא יותר מ-1-2 ימים

TBD לא מבטל ענפים לחלוטין — הוא מבטל ענפים ארוכי-חיים. מפתח יוצר ענף, מבצע שינוי קטן, פותח PR, ממזג תוך 24-48 שעות. אם המשימה גדולה — פרק אותה לחלקים קטנים, כל אחד ממוזג בנפרד עם feature flag.

git checkout -b feat/add-user-avatar
# 3-5 коммитов за день
git push origin feat/add-user-avatar
# PR → CI → Review → Merge
# Ветка удаляется

אם ענף חי יותר מיומיים — זה סימן שהמשימה לא פורקה דיה.

CI כשער חובה

עם TBD, CI חייב להיות מהיר — אחרת לחכות 30 דקות למיזוג זה בלתי נסבל. מטרה: ריצת בדיקות מלאה מתחת ל-10 דקות.

כדי להשיג זאת:

• בדיקות יחידה תמיד רצות במלואן (< 3 דקות)
• בדיקות אינטגרציה — במקביל עם פיצול מודולים
• בדיקות E2E — רק ערכת smoke ב-PR, ריצה מלאה אחרי מיזוג ל-main

---
# GitHub Actions с параллельными тестами
jobs:
  unit-tests:
    runs-on: ubuntu-latest
    steps:
      - run: pytest tests/unit/ -n auto # pytest-xdist для параллелизма
  integration-tests:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        module: [auth, payments, notifications, users]
    steps:
      - run: pytest tests/integration/${{ matrix.module }}/

ניטור בריאות הטראנק

עם TBD פעיל, main חייב להיות תמיד ירוק. אם בדיקות על main שבורות — כל הצוות חסום. התראה ב-Slack על main אדום היא חובה:

---
# После каждого merge в main
- name: Notify on failure
  if: failure()
  uses: slackapi/slack-github-action@v1
  with:
    payload: |
      {"text": "🔴 Main branch is broken! @channel Check CI immediately."}
    env:
      SLACK_WEBHOOK_URL: ${{ secrets.SLACK_MAIN_ALERTS }}

כלל צוות: אם שברת את main — העדיפות הראשונה היא לתקן. אין עבודה חדשה עד שהטראנק ירוק.

מה צריך להשתנות בתהליכים

TBD דורש מספר הסכמות מהצוות:

• כל commit ל-main עובר CI (ללא יוצאים מן הכלל)
• Feature flags הם כלי סטנדרטי, לא חריג
• PR חי לא יותר מ-24-48 שעות — אם יותר, המשימה גדולה מדי
• ביקורת קוד מתבצעת במהירות: כלל "לא יותר מ-4 שעות ללא תגובה ל-PR" מהסוקר

מה כלול בעבודה

• ביקורת על אסטרטגיית ה-Git הנוכחית והתשתית
• הגדרת מאגר Git וכללי הגנת ענפים
• תצורת CI/CD (GitHub Actions/GitLab CI) עם בדיקות מקבילות וזמני timeout <10 דקות
• הטמעת מערכת Feature Flags (Flagsmith/LaunchDarkly או פתרון מותאם)
• אינטגרציה של התראות על כשל ב-main (Slack/Telegram)
• תיעוד התהליך לצוות
• הכשרת מפתחים וביקורת קוד על ה-PRs הראשונים
• תמיכה בשלב ההסתגלות (שבועיים)

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

ההתקנה הטכנית אורכת 1-3 ימים בהתאם למורכבות ה-CI/CD הנוכחי שלך. הסתגלות הצוות אורכת כמה שבועות. חבילת הפתיחה עולה $1,500. העלות מחושבת באופן אישי: נבחן את הפרויקט שלך — צור קשר. המהנדסים שלנו מוסמכים ובעלי ניסיון של 5+ שנים בטרנספורמציית DevOps. אנחנו מבטיחים: המעבר ל-TBD יפחית קונפליקטים ב-70% ויאיץ את ה-CI פי 2-3.

איך ליישם TBD בפרויקט קיים?

התחל בקטן: בחר צוות אחד ושירות אחד. הגדר Feature Flags לתכונות חדשות. אכוף את הכלל: "אין ענפים בני יותר מיומיים." אחרי חודש, מדוד תקלות אינטגרציה — הן יופחתו משמעותית. כבר ביצענו את המעבר הזה עבור 20+ צוותים — התוצאה יציבה. קבל ייעוץ — נציע תוכנית מותאמת לתשתית שלך.

פרטים נוספים על האסטרטגיה ניתן למצוא ב-ויקיפדיה. כדי לקבל פתרון מוכן — צור קשר, נקים TBD מוכן לשימוש תוך 1-3 ימים.