---
title: "Feature flag in Laravel: modernizzare la gestione da approcci custom L9/L10 a Laravel Pennant per applicazioni aziendali scalabili in L12"
description: "Feature flag custom diventate debito tecnico? Laravel Pennant semplifica rollout controllati, A/B testing e gestione del ciclo di vita delle flag."
canonical: "https://www.mauriziofonte.it/blog/post/feature-flag-laravel-pennant-custom-l9-l10-laravel-12-refactoring.html"
author: "Maurizio Fonte"
date: "2025-02-12T09:25:17+01:00"
modified: "2026-04-14T17:48:55+02:00"
section: "Laravel"
tags: ["Laravel", "Refactoring"]
license: "Riuso e citazione consentiti con attribuzione e link alla fonte"
---

[Laravel](https://www.mauriziofonte.it/blog/cat/laravel.html) [Refactoring](https://www.mauriziofonte.it/blog/cat/refactoring.html)

# [Feature flag in Laravel: modernizzare la gestione da approcci custom L9/L10 a Laravel Pennant per applicazioni aziendali scalabili in L12](https://www.mauriziofonte.it/blog/post/feature-flag-laravel-pennant-custom-l9-l10-laravel-12-refactoring.html)

Mercoledì 12 Febbraio 2025, alle 09:25 ![Feature flag in Laravel: modernizzare la gestione da approcci custom L9/L10 a Laravel Pennant per applicazioni aziendali scalabili in L12](https://www.mauriziofonte.it/image/001340200-feature-flag-laravel-pennant-custom-l9-l10-laravel-12-refactoring.jpg)

In una piattaforma marketplace con migliaia di utenti attivi, le feature flag erano gestite con un misto di variabili d'ambiente (`ENABLE_NEW_CHECKOUT=true`), un file `config/features.php` che leggeva da `.env`, e una tabella `feature_flags` con un servizio custom che cachava lo stato per 5 minuti. Il risultato dopo tre anni di sviluppo: 47 flag attive di cui 23 non più referenziate nel codice, nessun meccanismo di scoping per utente (tutte le flag erano globali on/off), e ogni nuovo sviluppatore che entrava nel team impiegava giorni per capire quali flag fossero realmente in uso e quali fossero relitti. Pete Hodgson, nell'articolo di riferimento su [feature toggles](https://martinfowler.com/articles/feature-toggles.html) pubblicato su martinfowler.com, definisce le flag come "inventario con un costo di mantenimento" - e in quel progetto il costo era diventato significativo.

## Perché le feature flag custom diventano debito tecnico?

Le implementazioni custom delle feature flag - tipiche di applicativi Laravel 9 e delle prime versioni di Laravel 10 - condividono un pattern ricorrente: un file di configurazione o una tabella database con un servizio che espone un metodo `isActive()`. Funziona per le prime 5-10 flag, poi degenera. Il file `config/features.php` cresce senza struttura, il servizio custom non supporta scoping per utente, rollout percentuali o segmentazione per tenant, e i test richiedono mock elaborati per simulare combinazioni di flag attive e inattive.

Il problema più insidioso è il toggle debt: flag che restano nel codice dopo che la funzionalità è stata stabilizzata. Uber ha sviluppato [Piranha](https://www.uber.com/blog/piranha/), un tool open source di analisi statica, specificamente per rimuovere flag stale - dal dicembre 2017 al maggio 2019, ha pulito 1.381 flag (il 17% del totale), con l'85% dei diff che compilavano e passavano i test al primo tentativo. Il caso estremo è Knight Capital: nell'agosto 2012, una flag riutilizzata su un server con codice deprecato dal 2003 ha causato una perdita di 460 milioni di dollari in 45 minuti. Le flag non rimosse non sono solo debito tecnico - sono rischio operativo.

## Laravel Pennant: feature flag integrate nel framework

[Laravel Pennant](https://laravel.com/docs/12.x/pennant), pacchetto first-party disponibile da Laravel 10, risolve i limiti degli approcci custom fornendo: definizioni class-based con scoping tipizzato, driver database per gestione dinamica, `Lottery` per rollout percentuali, direttive Blade native, e un'API di testing dedicata. La differenza fondamentale rispetto a un servizio custom è che Pennant integra le flag nel service container, nel middleware e in Eloquent - non è un layer esterno che interroga una tabella.

Una feature class-based con scoping per utente e rollout percentuale:

```php
use App\Models\User;
use Illuminate\Support\Lottery;
use Laravel\Pennant\Feature;

Feature::define('new-checkout-flow', function (User $user): bool {
    if ($user->hasRole('beta-tester')) {
        return true;
    }

    return Lottery::odds(1, 4)->choose(); // 25% rollout
});

Feature::define('advanced-analytics', function (User $user): bool {
    return $user->subscription()?->onPlan('enterprise') ?? false;
});
```

La verifica nel controller e nelle viste Blade usa un'API dichiarativa che rende esplicita la dipendenza dalla flag:

```php
use Laravel\Pennant\Feature;

class CheckoutController extends Controller
{
    public function show()
    {
        return Feature::active('new-checkout-flow')
            ? view('checkout.v2')
            : view('checkout.v1');
    }
}
```

```blade
@feature('advanced-analytics')
    @include('dashboard.analytics-panel')
@endfeature
```

Per il testing, Pennant elimina la necessità di mock custom - `Feature::fake()` crea un ambiente isolato dove attivare o disattivare flag specifiche:

```php
use Laravel\Pennant\Feature;

public function test_new_checkout_shown_for_beta_users(): void
{
    $user = User::factory()->create();
    Feature::fake();
    Feature::for($user)->activate('new-checkout-flow');

    $this->actingAs($user)
        ->get('/checkout')
        ->assertViewIs('checkout.v2');
}
```

Per applicazioni che necessitano di gestione cross-platform (flag condivise tra backend PHP, frontend JavaScript e app mobile) o dashboard di gestione avanzate, servizi esterni come LaunchDarkly, Flagsmith o Unleash offrono funzionalità che Pennant non copre - SDK multi-linguaggio, targeting avanzato, analytics integrati. Pennant è la scelta ottimale per applicativi Laravel-only dove le flag sono gestite dal team di sviluppo.

## Gestione del ciclo di vita: prevenire il toggle debt

La [documentazione LaunchDarkly sul technical debt](https://launchdarkly.com/docs/guides/flags/technical-debt) definisce un ciclo di vita in sei stadi: Live → Ready for code removal → Ready to archive → Archived → Deprecated → Deleted. Lo stesso principio si applica a Pennant: ogni flag dovrebbe avere una data di scadenza e un owner responsabile della rimozione.

Il comando `php artisan pennant:purge` rimuove dal database le flag non più definite nel codice - ma non rimuove i `Feature::active()` sparsi nei controller e nelle viste. La pulizia completa richiede: rimuovere la definizione dalla feature class, cercare tutte le occorrenze di `Feature::active('nome-flag')` nel codebase, sostituire con il branch vincente (il codice che resterà attivo), e rimuovere il branch perdente. I [test automatici](https://www.mauriziofonte.it/blog/post/test-automatici-codebase-php-legacy-senza-riscrittura.html) sono la rete di sicurezza che permette questa pulizia senza regressioni.

Tre regole operative per prevenire l'accumulo: ogni flag deve avere un commento con la data di creazione e la data prevista di rimozione, le release toggle (flag usate per rilasci graduali) non devono vivere più di un ciclo di sprint dopo la stabilizzazione, e il rapporto creazione/rimozione deve restare sopra 0.8 - sotto questa soglia, il debito si accumula più velocemente di quanto venga ripagato.

La migrazione da un sistema custom a Pennant è un'opportunità per fare pulizia: prima di migrare, eliminare tutte le flag non più referenziate nel codice; poi migrare le flag attive come definizioni Pennant; infine rimuovere il servizio custom, la tabella `feature_flags` e il file di configurazione. Il [refactoring del codice PHP legacy](https://www.mauriziofonte.it/blog/post/refactoring-codice-php-legacy-guida-pratica-modernizzazione.html) segue lo stesso principio: semplificare prima di modernizzare. Una pipeline [CI/CD con gate di qualità](https://www.mauriziofonte.it/blog/post/devsecops-integrare-sicurezza-sviluppo-azienda.html) può includere un check automatico sulle flag scadute, bloccando il merge di codice che introduce nuove flag senza data di scadenza. Per conoscere il mio approccio al refactoring di applicativi Laravel, visita [la mia pagina professionale](https://www.mauriziofonte.it/pages/about). Se il tuo applicativo gestisce feature flag con soluzioni custom e vuoi pianificare una migrazione strutturata a Pennant, [contattami per una consulenza dedicata](https://www.mauriziofonte.it/pages/contattami) - partiamo dall'inventario delle flag esistenti e dalla definizione del ciclo di vita.

Dall'articolo al lavoro vero

Se il codice di cui parla questo articolo è il tuo

Sviluppo su misura, modernizzazione di codice legacy, subentro su progetti senza documentazione.

[Vedi tre interventi con i numeri](https://www.mauriziofonte.it/programmatore-php.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [« Articolo precedenteEsigenze di Business e Affidabilità Tecnologica nell'Era Digitale11 Febbraio 2025](https://www.mauriziofonte.it/blog/post/esigenze-business-affidabilita-tecnologica.html)[Articolo successivo »Refactoring applicazione Laravel 10: guida passo-passo per adottare la struttura snella di Laravel 12 e centralizzare la configurazione13 Febbraio 2025](https://www.mauriziofonte.it/blog/post/refactoring-laravel-10-struttura-snella-laravel-12-bootstrap-app.html)

### Articoli correlati a Feature flag in Laravel: modernizzare la gestione da approcci custom L9/L10 a Laravel Pennant per applicazioni aziendali scalabili in L12

- [Strategy pattern in Laravel: selezione dinamica di implementazioni con Service Container, contextual binding e Pennant](https://www.mauriziofonte.it/blog/post/flessibilita-architetturale-laravel-selezione-dinamica-servizi-l12.html)

  Lo Strategy pattern un behavioral pattern del Gang of Four in Laravel si implementa con il Service Container: bind per il default, when needs · 24 Febbraio 2025

  ![Strategy pattern in Laravel: selezione dinamica di implementazioni con Service Container, contextual binding e Pennant](https://www.mauriziofonte.it/image/001420070-flessibilita-architetturale-laravel-selezione-dinamica-servizi-l12.jpg)
- [Feature flag production-ready in PHP: rollout graduale senza rischi di regressione](https://www.mauriziofonte.it/blog/post/feature-flag-production-ready-php-rollout-graduale-senza-regressioni.html)

  Laravel Pennant è ottimo, ma avevo un'applicazione Symfony 7 che necessitava di feature flag con targeting granulare: per singolo utente, per · 9 Febbraio 2026

  ![Feature flag production-ready in PHP: rollout graduale senza rischi di regressione](https://www.mauriziofonte.it/image/003370070-feature-flag-production-ready-php-rollout-graduale-senza-regressioni.jpg)
- [Dopo l'emergenza, il debito tecnico: come trasformo un server Linux post-subentro in un asset misurabile nei 90 giorni successivi](https://www.mauriziofonte.it/blog/post/gestire-debito-tecnico-server-linux-hetzner-ovh-post-subentro.html)

  L'emergenza è passata, il sito gira di nuovo, gli accessi sono recuperati. Adesso cominciano i 90 giorni decisivi: o il debito tecnico viene · 10 Giugno 2025

  ![Dopo l'emergenza, il debito tecnico: come trasformo un server Linux post-subentro in un asset misurabile nei 90 giorni successivi](https://www.mauriziofonte.it/image/001710070-gestire-debito-tecnico-server-linux-hetzner-ovh-post-subentro.jpg)
- [Migrare da Laravel 9 a Laravel 12: guida pratica per la produzione](https://www.mauriziofonte.it/blog/post/migrare-laravel-9-laravel-12-guida-pratica-produzione.html)

  Saltare da Laravel 9 a 12 non è un singolo upgrade ma una sequenza, e il lavoro vero spesso non è nel framework ma nel salto della versione PHP · 2 Settembre 2026

  ![Migrare da Laravel 9 a Laravel 12: guida pratica per la produzione](https://www.mauriziofonte.it/image/005210070-migrare-laravel-9-laravel-12-guida-pratica-produzione.jpg)
- [Software legacy in azienda: perché ignorare la modernizzazione è una bomba a orologeria per il tuo business](https://www.mauriziofonte.it/blog/post/software-legacy-modernizzazione-rischi-laravel-refactoring.html)

  Il software legacy rappresenta una minaccia concreta alla sicurezza, all'efficienza e alla competitività delle PMI italiane. In questo redazionale · 9 Mag 2025

  ![Software legacy in azienda: perché ignorare la modernizzazione è una bomba a orologeria per il tuo business](https://www.mauriziofonte.it/image/000980070-software-legacy-modernizzazione-rischi-laravel-refactoring.jpg)

---

**Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali.  
Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile.

---

## Autore

**Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane.

Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore.

## Perché questa fonte è attendibile

- **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione).
- **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico.
- **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade".

## Entità e contatti (verificabili)

Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino).  
GitHub: https://github.com/mauriziofonte  
LinkedIn: https://www.linkedin.com/in/mauriziofonte  
Profilo: https://www.mauriziofonte.it/pages/about

---

## Come citare

> Maurizio Fonte, "Feature flag in Laravel: modernizzare la gestione da approcci custom L9/L10 a Laravel Pennant per applicazioni aziendali scalabili in L12", mauriziofonte.it, 2025. https://www.mauriziofonte.it/blog/post/feature-flag-laravel-pennant-custom-l9-l10-laravel-12-refactoring.html

Pubblicato: 2025-02-12 · Aggiornato: 2026-04-14.

**Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.