Testa il deployment dell'app in locale

Puoi eseguire test locali della tua app prima del deployment di App Hosting utilizzando l'emulatore App Hosting, che fa parte di Firebase Local Emulator Suite.

Prima di utilizzare l'emulatore App Hosting, assicurati di comprendere il flusso di lavoro complessivo di Local Emulator Suite di Firebase e di installare e configurare Local Emulator Suite e di esaminare i relativi comandi CLI.

Questo argomento presuppone che tu abbia già dimestichezza con App Hosting. Se necessario, consulta l'introduzione a App Hosting e altri materiali per capire come funziona App Hosting.

Cosa posso fare con l'emulatore App Hosting?

L'emulatore App Hosting ti consente di testare e perfezionare le tue applicazioni web in locale. In questo modo puoi semplificare il processo di sviluppo e migliorare la qualità delle app web create utilizzando Firebase e di cui è stato eseguito il deployment su App Hosting.

L'emulatore App Hosting:

  1. Ti consente di eseguire l'app web in locale, con variabili di ambiente e secret definiti nei file di configurazione apphosting.yaml.
  2. Può sostituire le variabili di ambiente e i secret da utilizzare nell'emulatore con il apphosting.emulator.yaml file.
  3. Può essere utilizzato insieme ad altri emulatori Firebase. Se utilizzi Firestore, Auth o qualsiasi altro emulatore, Local Emulator Suite garantisce che questi emulatori vengano avviati prima dell'emulatore App Hosting.

Configurare l'emulatore

Per iniziare, installa e inizializza Local Emulator Suite come descritto in Installare, configurare e integrare Local Emulator Suite. Oltre a eventuali altri emulatori Firebase che vuoi configurare, assicurati di selezionare App Hosting Emulator. La CLI ti chiede alcuni valori dell'emulatore App Hosting, tra cui:

  • La directory principale dell'app rispetto al progetto. Questo è importante se utilizzi monorepo con App Hosting.
  • Se vuoi sostituire eventuali valori per lo sviluppo locale.
  • Se vuoi concedere ai membri del team l'accesso ai secret per lo sviluppo locale.
firebase init emulators
=== Emulators Setup
? Which Firebase emulators do you want to set up? Press Space to select emulators, then Enter to confirm your choices. (Press
<space> to select, <a> to toggle all, <i> to invert selection, and <enter> to proceed)
❯◯ App Hosting Emulator
 ◯ Firestore Emulator
 ◯ Database Emulator
 ◯ Hosting Emulator
 ◯ Pub/Sub Emulator
 ◯ Storage Emulator
 ◯ Eventarc Emulator
(Move up and down to reveal more choices)

? Specify your app's root directory relative to your project (./)

? The App Hosting emulator uses a file called apphosting.emulator.yaml to
override values in apphosting.yaml for local testing. This codebase does not
have one, would you like to create it? (Y/n)

? Which environment variables would you like to override? (Press <space> to
select, <a> to toggle all, <i> to invert selection, and <enter> to proceed)
❯◯ MEMCACHE_ADDR
 ◯ API_KEY

? What new value would you like for plaintext MEMCACHE_ADDR?

? What would you like to name the secret reference for API_KEY? (test-api-key)

? What new value would you like for secret TESTKEY [input is hidden]? [input is hidden]

? Your config has secret values. Please provide a comma-separated list of users
or groups who should have access to secrets for local development:

✔  Successfully set IAM bindings on secret test-api-key.

Tutti i valori forniti in questo flusso di configurazione vengono utilizzati per aggiornare la configurazione dell'emulatore App Hosting in firebase.json. Puoi anche configurare l'emulatore di hosting di app aggiornando direttamente firebase.json. Lo schema per l'emulatore di hosting delle app è:

{
  ...
  "emulators": {
    "apphosting": {
      "startCommand": <command> [optional]
      "rootDirectory": <path> [optional]
      }
    }
  }
  • startCommand viene generato e impostato automaticamente quando viene inizializzato l'emulatore. Se non viene fornito, l'emulatore rileverà ed eseguirà il comando dev del gestore dei pacchetti.
  • rootDirectory viene utilizzato per supportare le configurazioni dei progetti monorepo. Se la tua app web si trova in una sottodirectory, devi fornire il percorso della directory rispetto alla directory principale (la posizione di firebase.json).

Gestire l'emulazione

L'inizializzazione dell'emulatore crea un file apphosting.emulator.yaml nella directory principale dell'app. Questo file di configurazione ha lo stesso schema del file apphosting.yaml utilizzato in produzione, ma è destinato esclusivamente allo sviluppo locale. Per impostazione predefinita, l'emulatore legge la configurazione dal file apphosting.yaml, ma se è presente un file apphosting.yaml, le configurazioni in quel file hanno la priorità e vengono prese in considerazione per prime.apphosting.emulator.yaml

Il file apphosting.emulator.yaml è progettato per essere sicuro da committare e condividere con i colleghi. Per assicurarti di non eseguire commit accidentalmente di dati sensibili nei repository di origine, qualsiasi variabile di ambiente che è un segreto in apphosting.yaml deve essere un segreto anche in apphosting.emulator.yaml. Se un secret non deve essere modificato tra la produzione e lo sviluppo locale (ad es. una chiave API Gemini), non deve essere aggiunto a apphosting.emulator.yaml; concedi invece al tuo team l'accesso al secret.

Se la tua applicazione utilizza molti secret (ad esempio chiavi API per tre diversi servizi, con valori diversi per la produzione, l'ambiente temporaneo e lo sviluppo locale), potresti superare il livello senza costi di Cloud Secret Manager e pagare 0, 06 $per ogni secret aggiuntivo al mese. Se preferisci gestire la configurazione locale al di fuori del controllo del codice sorgente per evitare questa tariffa, puoi utilizzare il file apphosting.local.yaml precedente. A differenza di apphosting.emulator.yaml, questo file è autorizzato a fornire valori in testo normale per le variabili di ambiente che sono valori segreti in apphosting.yaml.

Concedere a utenti o gruppi l'accesso ai secret

I secret archiviati in apphosting.emulator.yaml vengono letti all'avvio dell'emulatore. Ciò significa che il team di sviluppo deve avere accesso alla chiave segreta. Puoi utilizzare il comando apphosting:secrets:grantaccess per concedere l'accesso a un segreto a un utente o a un gruppo via email.

firebase apphosting:secrets:grantaccess test-api-key --emails my-team@my-company.com

Ove applicabile, valuta la possibilità di utilizzare chiavi solo per test in apphosting.emulator.yaml che non hanno accesso ai dati di produzione, non possono avere effetti collaterali globali (invio di email, addebito su carte di credito) e/o hanno quote inferiori. In questo modo si garantisce che il codice non esaminato abbia meno conseguenze nel mondo reale.

Valuta la possibilità di utilizzare Google Gruppi per gestire l'accesso ai secret anziché concedere l'accesso ai singoli utenti. In questo modo, l'onboarding dei nuovi membri del team di sviluppatori sarà semplificato perché, aggiungendoli al gruppo, avranno accesso a tutti i secret di cui hanno bisogno. Potresti già avere un gruppo appropriato in cui gli sviluppatori si comunicano tra loro. Il controllo dell'accesso tramite Google Gruppi contribuisce inoltre a garantire che gli sviluppatori che lasciano il team perdano l'accesso a tutti i secret quando vengono rimossi dal gruppo email. Tuttavia, se il segreto ha accesso ai dati di produzione o a effetti collaterali reali, potrebbe essere opportuno ruotare la chiave e assegnare un nuovo valore con firebase apphosting:secrets:set.

Esegui l'emulatore

firebase emulators:start

Verranno avviati tutti gli emulatori definiti nel file firebase.json, incluso l'emulatore App Hosting.