שרת Feature Toggle באירוח עצמי (Unleash/Flagsmith)

הפעלתם פיצ'ר חדש דרך משתנה סביבה, פרסתם מחדש את השירות — וגיליתם באג. רולבק? עוד דיפלוי, עוד 15–30 דקות. כל מחזור כזה מאריך את השחרור לשעות, ואין לוג ביקורת — לא ברור מי הפעיל את הדגל ומתי. שרת feature toggle פותר את זה: הוא מנתק בין דיפלוי לשחרור, מאפשר ניהול פיצ'רים בזמן אמת ללא אתחולים, ומספק תיעוד ביקורת לכל שינוי.

Feature flags בסביבת production הם לא if (process.env.ENABLE_NEW_CHECKOUT === 'true'). הם תשתית עם API, SDK ו-UI. כשהדגלים מיושמים דרך משתני סביבה, כל שינוי דורש דיפלוי — מה שהורס את כל הרעיון של הפרדה בין דיפלוי לשחרור. פתרון self-hosted (Unleash או Flagsmith) נפרס בקלאסטר Kubernetes שלכם, שומר מצב ב-PostgreSQL, וחושף מדדים ל-Prometheus. אנחנו עושים את זה turnkey: מבחירת מערכת ועד הדרכת צוות.

בעיות שאנחנו פותרים

• דיפלוי איטי: הפעלת פיצ'ר לוקחת 15–30 דקות. עם שרת — 0 שניות. מחזור השחרור מצטמצם ב-40%.
• חוסר תיעוד ביקורת: לא ידוע מי הפעיל פיצ'ר ומתי. לוג הביקורת מתעד כל שינוי עם חותמת זמן ומשתמש.
• אין A/B testing: בלי שחרור הדרגתי, אי אפשר להפעיל פיצ'ר ל-5% מהמשתמשים ולהשוות מדדים. עם שרת, עושים את זה ב-UI תוך דקה.

איך אנחנו עושים את זה: סטאק ומקרה בוחן

אנחנו משתמשים ב-Unleash או Flagsmith בהתאם למשימה. שניהם Open Source, רצים על PostgreSQL. אנחנו פורסים ב-Kubernetes עם autoscaling וניטור. דוגמה לדיפלוי מוכן ל-production:

---
# unleash-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: unleash
  namespace: feature-flags
spec:
  replicas: 2
  template:
    spec:
      containers:
        - name: unleash
          image: unleashorg/unleash-server:5.9
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: unleash-db
                  key: connection-string
            - name: INIT_ADMIN_API_TOKENS
              valueFrom:
                secretKeyRef:
                  name: unleash-tokens
                  key: admin-token
          resources:
            requests:
              memory: "256Mi"
              cpu: "100m"
            limits:
              memory: "512Mi"
              cpu: "500m"
---

Unleash דורש PostgreSQL. אם כבר יש לכם RDS מנוהל או Cloud SQL — אנחנו מתחברים אליו. מסד נתונים נפרד, משתמש נפרד עם הרשאות מינימליות. אנחנו ממליצים על גיבוי שעתי ועל dump מלא יומי.

אינטגרציית SDK באפליקציה:

import { initialize } from 'unleash-client';

const unleash = initialize({
  url: 'https://unleash.internal/api/',
  appName: 'payments-service',
  customHeaders: {
    Authorization: process.env.UNLEASH_API_TOKEN,
  },
});

if (unleash.isEnabled('new-checkout-flow', { userId: user.id })) {
  return newCheckoutHandler(req, res);
}

return legacyCheckoutHandler(req, res);

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

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

השוואה: משתני סביבה מול שרת Feature Toggle

איך להשתמש נכון בשחרור הדרגתי?

שחרור הדרגתי הוא התכונה המרכזית. הפעילו פיצ'ר ל-10% מהמשתמשים, עקבו אחרי מדדים (latency, שגיאות, המרות), הרחיבו ל-20%, ואז ל-100%. ב-Unleash זו אסטרטגיית ההפעלה # unleash-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: unleash namespace: feature-flags spec: replicas: 2 template: spec: containers: - name: unleash image: unleashorg/unleash-server:5.9 env: - name: DATABASE_URL valueFrom: secretKeyRef: name: unleash-db key: connection-string - name: INIT_ADMIN_API_TOKENS valueFrom: secretKeyRef: name: unleash-tokens key: admin-token resources: requests: memory: "256Mi" cpu: "100m" limits: memory: "512Mi" cpu: "500m" עם פרמטרים: אחוז שחרור ו-Stickiness לפי userId. Stickiness מבטיח שאותו משתמש רואה את אותו מצב בכל בקשה. בלי זה — חוויית משתמש גרועה. כפי שמצוין בתיעוד הרשמי של Unleash, זה קריטי לעקביות.

השוואת Unleash מול Flagsmith

אם אתם צריכים רק דגלים ומשתמשים ב-GitLab — בחרו ב-Unleash. אם אתם צריכים קונפיגורציה מרחוק — בחרו ב-Flagsmith. מבחינת latency של API, Unleash מהיר יותר בממוצע ב-30%.

אילו בעיות פותר שרת Feature Toggle?

שרת feature toggle פותר שלוש בעיות מרכזיות: התלות של הדיפלוי בשחרור, חוסר תיעוד ביקורת לשינויים, וחוסר היכולת לבצע A/B testing. הוא גם מאפשר רולבק מיידי — כיבוי דגל ב-UI תוך שניות.

התהליך שלנו

1. ניתוח: זיהוי אילו דגלים נדרשים, הערכת היקף האינטגרציה.
2. תכנון: בחירת מערכת (Unleash/Flagsmith), תכנון תשתית (K8s, PostgreSQL, מדדים).
3. יישום: פריסת השרת, הגדרת מסד הנתונים, אינטגרציית SDK לשירותים שלכם (אחד או שניים כדוגמה).
4. בדיקות: בדיקות פונקציונליות של הדגלים, בדיקות עומס לשרת.
5. דיפלוי: פריסה מוכנה ל-production עם ניטור וגיבויים.

מה כלול

• פריסת שרת self-hosted (Unleash/Flagsmith) בקלאסטר K8s שלכם.
• הגדרת PostgreSQL (RDS/Cloud SQL מנוהל).
• אינטגרציית SDK ב-2 שירותים מרכזיים כדוגמה.
• הדרכת צוות: מחזור חיי דגל, שימוש ב-UI, ניטור.
• תיעוד ארכיטקטורה ותהליכים.
• אחריות יציבות 24/7, תמיכה ל-30 יום לאחר היישום.

ניסיון ותוצאות

אנחנו עובדים עם feature toggles כבר 5 שנים. מעל 20 דיפלויים ל-production. זמן יישום טיפוסי — 3 ימים. MTTR ירד ב-60% בזכות רולבקים מיידיים. אנחנו בטוחים ש-feature flags יאיצו את השחרורים שלכם. בקשו ייעוץ — נבחר את המערכת האופטימלית ונעריך את היקף העבודה. עלות יישום טיפוסית מתחילה ב-$5,000, עם פוטנציאל חיסכון של $20,000 בשנה בהפחתת עלויות דיפלוי.

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

דיפלוי והגדרה — בין 2 ל-5 ימים בהתאם למורכבות. העלות מחושבת באופן אישי. נעריך את הפרויקט שלכם — צרו קשר לייעוץ. קבלו ייעוץ ליישום — האצו את השחרורים שלכם.