דגל תכונה

דגל תכונה, המכונה גם feature toggle, הוא תנאי בקוד אפליקציה שקובע בזמן ריצה האם פונקציונליות מסוימת פעילה עבור משתמש או בקשה נתונה. במקום שתכונה תהיה קיימת או נעדרת בהתאם לגרסת הקוד שנפרסה, היא קיימת בקוד אך מופעלת או כבויה על ידי תצורה. זה מנתק את הפריסה מהגרסה: קוד יכול להישלח לייצור ברציפות בעוד שהתכונות שהוא מכיל נשארות בלתי נראות עד שמישהו מחליט לחשוף אותן.

עבור ניסויים, דגלי תכונות הם המנגנון הבסיסי של בדיקות בצד השרת. הקצאת משתמש לוריאנט דגל זהה מבחינה פונקציונלית להקצאתו לזרוע ניסוי, ומכיוון שההחלטה מתרחשת באפליקציה ולא בדפדפן, הוריאנט יכול להשפיע על כל דבר שהאפליקציה שולטת בו: לוגיקת תמחור, דירוג חיפוש, אלגוריתמי המלצות, טריגרים של דוא"ל, כללי תשלום והתנהגות backend שאף כלי בדיקה בצד הלקוח לא יכול להגיע אליהם. זה גם מבטל את ההבהוב החזותי שמניפולציה בצד הלקוח מייצרת, והוא בלתי נראה לחוסמי פרסומות ולהגדרות דפדפן החוסמות סקריפטים.

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

הצטברות זו היא הסיכון העיקרי. כל דגל הוא ענף, ומספר נתיבי הקוד האפשריים גדל באופן כפול ככל שדגלים מצטברים. בדיקת כל שילוב הופכת לבלתי אפשרית, אינטראקציות בלתי צפויות בין דגלים גורמות לפגמים שקשה לשחזר, והקוד הופך להיות קשה יותר ויותר להיגיון. צוותים ממושמעים מתייחסים להסרת דגלים כחלק מהגדרת "בוצע", ​​שומרים רשימת מלאי עם בעלים ותאריך תפוגה עבור כל דגל, ומבצעים ביקורת מעת לעת עבור דגלים שהיו בערכם קבוע במשך חודשים.

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

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

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