Flaggor på flaggor: Hur Optimizely använder feature flags

Har du någonsin undrat om leverantörer av feature flags använder sina egna produkter?

På Optimizely säljer vi inte bara feature flags - vi lever och andas dem varje dag.

Faktum är att vi använder vår Feature Experimentation-plattform för att leverera nya funktioner till ... vår Feature Experimentation-plattform. Ja, det är meta. Vi använder feature flags för att släppa feature flags. 🤯

Det här är inte "trevligt att ha". Det är så vi bygger snabbare, distribuerar säkrare och innoverar i skala upp.

Innan vi dyker in i våra specifika användningsfall, låt oss ta itu med varför detta är viktigt:

Den hårda sanningen om funktionsreleaser

De flesta team tar onödiga risker med sina funktionsreleaser genom att:

• De skickar direkt till produktion och hoppas att inget går sönder
• Behandla alla funktioner med samma utrullningsprocess oavsett risk
• Skapa flaskhalsar där produktbeslut kräver tekniska implementeringar
• Bygga komplexa förgreningsstrategier som försenar integrationen

Vi vet det eftersom vi har varit där.

Utan feature flags blir varje release ett högt spel med din UX, ingenjörstid och intäkter på spel.

Så, exakt hur använder Optimizely vår egen teknik för feature flags?

Här är tre verkliga exempel från vårt ingenjörsteam:

1. Finjustera AI-funktioner utan tekniska flaskhalsar

Möt Optimizely One - din oändliga arbetsstyrka som hjälper användare att skapa bättre experiment, analysera resultat och generera nya idéer.

Under huven drivs Opal av avancerade LLM-modeller från våra strategiska partners som Google och Microsoft. Men det är här det blir intressant.

Vi använder feature flags inte bara för att kontrollera om AI-funktioner är PÅ eller AV, utan för att finjustera exakt hur de fungerar.

Vi använder till exempel feature flags för att kontrollera:

• Vilken LLM-modell som driver Opal (växling mellan modeller efter behov)
• Hur dessa modeller konfigureras (temperatur, tokens, parametrar)
• Vilka promptmallar vi använder
• Vilka användarsegment som får tillgång till vilka AI-funktioner

Vid instrumentering av en sådan här feature flags är ett tillvägagångssätt att hårdkoda konfigurationen av LLM för varje variation:

const { createInstance } = require("@optimizely/optimizely-sdk"); import OpenAI from "openai"; const Optimizely = createInstance({ sdkKey: "<YOUR_SDK_KEY>", }); const openAIClient = new OpenAI(); const user = optimizely.createUserContext("user123"); const decision = user.decide("llm_flag"); const variationKey = decision["variationKey"]; if (variationKey === "control") { // Exekvera kod för kontrollvariationen const completion = await openAIClient.chat.completions.create({ model: "gpt-4o", messages: [ { roll: "användare", innehåll: 
"Du är en historieberättare som specialiserar sig på nyckfulla berättelser. Skriv en godnattsaga på en mening om en enhörning.", // med betoning på nyckfullhet }, ], }); } else if (variationKey === "treatment") { // Exekvera kod för behandlingsvariationen const completion = await openAIClient.chat.completions.create({ model: "gpt-4o-mini", messages: [ { roll: "användare", innehåll: 
"Du är en barnboksförfattare. Skriv en godnattsaga på en mening om en enhörning.", // betoning på åldersanpassning }, ], }); }

Problemet? Varje förändring kräver att utvecklaren ingriper, vilket skapar flaskhalsar när du behöver agera snabbt.

Vi gör det på ett annat sätt.

Gamla sättet? Hårdkodade konfigurationer = långsam iteration.

Vårt sätt? Dynamiska flaggvariabler = total kontroll, noll driftsättningar.

Det här tillvägagångssättet innebär att vårt produktteam kan ändra AI-beteendet utan tekniska beroenden. Vi kan testa olika uppmaningar, byta modeller och justera parametrar från vår Feature Experimentation dashboard med noll kodändringar.

const { createInstance } = require("@optimizely/optimizely-sdk"); import OpenAI from "openai"; const optimizely = createInstance({ sdkKey: "<YOUR_SDK_KEY>", }); const openAIClient = new OpenAI(); const user = optimizely.createUserContext("user123"); const decision = user.decide("llm_flag"); const completion = await openAIClient.chat.completions.create({ model: decision.variables.model, // returneras av Optimizely One decision messages: [ { roll: "user", innehåll: decision.variables.prompt, // returneras av Optimizely decision }, ], });

Det ledde till:

• Dramatiskt snabbare tid från idé till produktion för AI-funktioner
• Fler experiment som utförs av produktteam med samma tekniska resurser
• Färre samtal till teknikavdelningen sent på kvällen (tack och lov, kill switches 💙)

Men det finns en ännu viktigare fördel: sömn.

Våra ingenjörer blir inte längre uppringda på nätterna för att lösa akuta problem med nya AI-funktioner, eftersom vi kan inaktivera problematiska funktioner direkt via vår dashboard för feature flags.

2. Minska risken vid lanseringar med canary testing

Låt oss prata om lanseringsångest.

Den där känslan när du ska släppa en viktig funktion och väntar på att supportärendena ska strömma in? Den där "lanseringsdagsångesten"? Ja, vi saknar den inte heller.

Vi använder feature flags för att köra canary testing för gradvisa, datainformerade utrullningar som förvandlar riskfyllda releaser till säkra, skalbara lanseringar.

När vi släppte vår Custom Flags Dashboard, en betydande förändring av kärnfunktionaliteten, skickade vi inte bara ut den till alla på en gång.

Istället gjorde vi följande:

• Lanserade vi den först till 5 % av kunderna (mestadels mindre konton)
• Övervakade felfrekvenser, prestandamätvärden och feedback från användare
• Gradvis ökade exponeringen till 20 %, sedan 50 % och sedan 100
• Meddelade kunderna i förebyggande syfte innan de fick ta del av ändringen

Det här tillvägagångssättet var både försiktigt och nödvändigt. Eftersom vår plattform fungerar som en kritisk infrastruktur för våra kunders funktionsreleaser kan alla störningar även drabba deras användare.

När vi migrerade hela vår datapipeline till Google Cloud Platform (GCP) använde vi feature flags i stor utsträckning för att hantera övergången. Men canary testing är inte bara för front-end-förändringar. Vi använde det också för att rulla ut infrastrukturuppdateringar, vilket minimerade risken under distributionen gradvis.

Att använda feature flags för att kontrollera migreringen gjorde det möjligt för oss att:

1. Riskreducering: Vi kunde omedelbart återgå om prestandan försämrades
2. Företagets kontinuitet: Våra kunder är beroende av kontinuerlig databehandling
3. Validering i skala upp: Vi kunde verifiera att de nya systemen hanterade verklig belastning innan vi gick in för fullt

Vi slutförde denna massiva infrastrukturmigrering med ett fåtal kundrapporterade incidenter, trots att vi flyttade miljarder dagliga händelser.

Lärdomen av detta? Ju större förändring, desto mer behöver du feature flags för att minska risken.

3. Avstängningsknappar: Din nödutmatningsknapp

Ibland går saker sönder (det är programvara, vi fattar).

Men det är en enorm skillnad mellan "Vi undersöker problemet och kommer att distribuera en fix snart ..." och "Vi stängde av det. Det är hanterat."

Kill switches är viktiga eftersom de omvandlar produktionsincidenter från alla händer nödsituationer till kontrollerade, metodiska svar.

På Optimizely har varje funktion en kill switch - en feature flag som låter oss inaktivera den direkt. Inga kodändringar. Inga utplaceringar. Ingen dramatik.

Vår tjänst för att bygga datafiler säkerställer att flagguppdateringar når slutanvändarna på bara några sekunder, vilket konkurrerar med streamingtjänster utan den komplicerade infrastrukturen.

När vi upptäcker problem genom våra övervakningssystem kan vi omedelbart inaktivera den problematiska funktionen, undersöka utan press och distribuera en korrekt lösning under normal arbetstid. Inga fler nödlösningar sent på kvällen.

Den här funktionen är särskilt viktig för vår verksamhet av flera skäl:

1. Bevarande avförtroendet: Som en plattform som ligger till grund för våra kunders upplevelser är det inte förhandlingsbart att minimera driftstopp
2. Global påverkan: Med kunder i olika tidszoner finns det aldrig en "bra tidpunkt" för ett avbrott
3. Komplexa beroenden: Funktioner samverkar ofta på oväntade sätt, och snabb isolering underlättar diagnos

Flaggor är dock inte en silverkula...

Feature flags är inte en ersättning för en solid rollback-strategi.

Vi använder vår produkt för att släppa uppdateringar till sig själv ("flaggor på flaggor"). I ett värsta scenario där en buggig funktion gör användargränssnittet otillgängligt, skulle vi inte kunna inaktivera funktionen på distans.

Det är därför vårt teknikteam har robusta rollback-processer tillsammans med feature flags, vilket ger oss flera lager av skydd. Denna strategi med flera lager är viktig när du bygger kritisk infrastruktur som andra är beroende av.

Feature flags som en produktstrategi

Användningsfallen ovan - från AI-fintrimning, canary testing och kill switches - visar att feature flags inte bara är ett tekniskt verktyg. De är en möjliggörare för produktstrategi.

Genom att skilja utrullning från lansering kan vi

• Gå snabbare fram: Skicka kod till produktion kontinuerligt utan att exponera ofärdiga funktioner
• Experimentera mer: Testa idéer med riktiga användare innan vi satsar på dem
• Minska risken: Begränsa exponeringen och tillhandahåll omedelbara återkallningsalternativ
• Stärk produktteamen: Ge icke-tekniska intressenter kontroll över utrullningar av funktioner

För vårt team har feature flags i grunden förändrat hur de tänker kring releaser. I stället för lanseringar med högt tryck och allt eller inget ser vi nu lanseringar som en ratt som de kan vrida upp gradvis samtidigt som de mäter effekten.

Feature flags let us move fast without breaking things. They're our safety net and our secret weapon.

Britt Hall

Sr. Director, Product Management

Vart är feature flags på väg härnäst

När vi blickar framåt ser vi att feature flags utvecklas på flera viktiga sätt:

1. Viktiga dödsbrytare för autonom AI: När företag går från att bygga funktioner som ökar användarnas funktioner till funktioner som automatiserar dem helt (som agenter som självständigt agerar för att uppnå mål), blir feature flags kritiska dödsbrytare. När din AI arbetar med allt större självständighet blir möjligheten att omedelbart inaktivera problematiskt beteende ett kritiskt krav.
2. AI-säkerhet genom kontinuerlig övervakning och justering: AI-säkerhet är nu ett aktivt forskningsområde. Särskilt i B2C-sammanhang kommer användarna från en mängd olika bakgrunder, vilket gör det viktigt att övervaka AI:s potential att förstärka identitetsbaserade fördomar (ålder, kön etc.). Feature flags gör det möjligt för team att finjustera AI-modeller i farten när det dyker upp mönster.
3. Hantera komplexitet i AI-assisterad utveckling: AI är utmärkt på att skriva kod för nya projekt, men har svårt att förstå komplexiteten i etablerade, omfattande kodbaser. Idag är AI bra för uppgifter som att skriva enhetstester, men när systemen blir mer komplexa blir verktyg som feature flags viktiga för säker testning, distribution och iteration, särskilt i en AI-driven värld.
4. Testning av AI-modeller utan teknisk overhead: När företag utvecklar sina egna AI-funktioner gör feature flags det möjligt att testa olika AI-modeller utan ytterligare kodändringar. När du har implementerat flaggan kan du utvärdera vilka modeller som fungerar bäst under verkliga förhållanden - allt från din dashboard för feature experimentation utan ytterligare ingenjörsarbete.

Kom igång med din strategi för feature flags

Om du inte använder feature flags ännu, eller om du bara använder dem för grundläggande av/på-brytare, kan du göra så här för att höja nivån:

• Börja med de mest riskfyllda funktionerna: Identifiera var du behöver kill-switchar mest.
• Lägg till variabler i dina flaggor: Kontrollera inte bara om en funktion är på, utan även hur den fungerar.
• Definiera tydligt ägande: Fastställ vem som kan växla mellan vilka flaggor och när
• Bygg upp utrullningsmönster: Skapa mallar för olika typer av releaser (högrisk vs. lågrisk)
• Koppla flaggor till observerbarhet: Se till att du snabbt kan korrelera problem som identifieras i APM-plattformar som Datadog medflaggändringar.
• Etablera styrning av flaggor: Skapa processer för att skapa, granska och dra tillbaka flaggor för att undvika teknisk skuld.

Den vanligaste invändningen vi hör handlar om teknisk skuld - "Kommer inte alla dessa flaggor att göra vår kodbas rörig?"

Även om detta är en befogad oro har vi upptäckt att det finns ett enormt värde i strategiska, långlivade flaggor. Överväg att implementera permanenta flaggor i områden som du kontinuerligt kommer att experimentera med, till exempel dina landningssidor eller checkout-flöde. Med flaggvariabler kan du styra alla aspekter av dessa högtrafikerade områden utan kodändringar.

Detta tillvägagångssätt låser upp "oändlig A/B-testning", möjligheten att köra iterativa experiment utan tekniska beroenden. Börja med att testa vad som fungerar bäst för alla, kör sedan målgruppsinriktade tester för värdefulla kundsegment. Resultatet är en kontinuerligt optimerande upplevelse som utvecklas med dina affärsbehov, allt hanterat via din feature flag dashboard.

På Optimizely har vi sett hur feature flags förvandlar utveckling från en serie stora, stressiga lanseringar till en smidig, kontinuerlig process med kontrollerade utrullningar och datadrivna beslut.

Vill du se hur feature flags kan förbättra ditt teams utvecklingsprocess?

👉 Prova Feature Experimentation gratis - Få gratis feature flags hela livet!

Om du är nyfiken på hur andra företag flaggar smartare kan du kolla in vår sida med kundberättelser.

Och om du använder flaggor på ett coolt sätt, låt oss prata. Vi vill gärna höra från dig.