Scrivere codici per Funzioni di Azure e testarle in locale

Quando possibile, è necessario creare e convalidare il progetto di codice di Funzioni di Azure in un ambiente di sviluppo locale. Azure Functions Core Tools offre una versione di runtime locale di Funzioni di Azure che si integra con gli strumenti di sviluppo più diffusi per uno sviluppo integrato, il debug e le distribuzioni. Le funzioni locali possono anche connettersi ai servizi di Azure in tempo reale.

Questo articolo fornisce alcune indicazioni condivise per lo sviluppo locale, ad esempio l'uso del file dilocal.settings.json. Sono inoltre disponibili collegamenti a linee guida specifiche dell'ambiente di sviluppo.

Ambienti di sviluppo locale

Il modo in cui si sviluppano le funzioni nel computer locale dipende dal linguaggio e dalle preferenze relative agli strumenti. Assicurarsi di scegliere la lingua preferita nella parte superiore dell'articolo.

È possibile usare questi ambienti di sviluppo per codificare le funzioni in locale nel linguaggio preferito:

Ognuno di questi ambienti di sviluppo locale consente di creare progetti di app per le funzioni e di usare modelli di funzione predefiniti per creare nuove funzioni. Ognuno di essi usa gli strumenti di base per consentire di testare ed eseguire il debug delle funzioni con il runtime reale di Funzioni di Azure nel proprio computer esattamente come qualsiasi altra app. È anche possibile pubblicare il progetto dell'app per le funzioni da uno di questi ambienti in Azure.

File di progetto locali

Una directory del progetto Functions contiene i file seguenti nella cartella radice del progetto, indipendentemente dalla lingua:

Gli altri file nel progetto dipendono dal linguaggio e dalle funzioni specifiche. Per altre informazioni, vedere la guida per sviluppatori per il linguaggio in uso.

File di impostazioni locali

Il file local.settings.json archivia le impostazioni dell'app e le impostazioni utilizzate dagli strumenti di sviluppo locali. Le impostazioni nel file local.settings.json vengono usate solo quando si esegue il progetto in locale. Quando si pubblica il progetto in Azure, assicurarsi di aggiungere anche le impostazioni necessarie alle impostazioni per l'app per le funzioni.

Il local.settings.json file ha questa struttura:

{
  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "<language worker>",
    "AzureWebJobsStorage": "<connection-string>",
    "MyBindingConnection": "<binding-connection-string>",
    "AzureWebJobs.HttpExample.Disabled": "true"
  },
  "Host": {
    "LocalHttpPort": 7071,
    "CORS": "*",
    "CORSCredentials": false
  },
  "ConnectionStrings": {
    "SQLConnectionString": "<sqlclient-connection-string>"
  }
}

Queste impostazioni sono supportate quando si eseguono progetti in locale:

Le impostazioni dell'applicazione seguenti possono essere incluse nella matrice Values durante l'esecuzione in locale:

Sincronizzare le impostazioni

Quando si sviluppano le funzioni in locale, tutte le impostazioni locali richieste dall’app devono essere presenti anche nelle impostazioni dell’app della app per le funzioni in cui viene distribuito il codice. Potrebbe anche essere necessario scaricare le impostazioni attuali dall'applicazione di funzione nel progetto locale. Sebbene sia possibile configurare manualmente le impostazioni dell'app nel portale di Azure, gli strumenti seguenti consentono anche di sincronizzare le impostazioni dell'app con le impostazioni locali nel progetto:

• Visual Studio Code
• Visual Studio
• Strumenti di base di Funzioni di Azure

Trigger e associazioni

Quando si sviluppano le funzioni in locale, è necessario prendere in considerazione i comportamenti di trigger e binding. Per i trigger HTTP, è possibile chiamare l'endpoint HTTP nel computer locale usando http://localhost/. Per le funzioni attivate non HTTP, sono disponibili diverse opzioni per l'esecuzione in locale:

• Il modo più semplice per testare le associazioni durante lo sviluppo locale consiste nell'usare stringhe di connessione destinate ai servizi di Azure in tempo reale. È possibile impostare come destinazione i servizi live aggiungendo le impostazioni della stringa di connessione appropriate nella matrice Values nel file local.settings.json. Quando si esegue questa operazione, le esecuzioni locali durante i test potrebbero influire sui servizi di produzione. Prendere invece in considerazione la configurazione di servizi separati da usare durante lo sviluppo e il test e quindi passare a servizi diversi durante l'ambiente di produzione.
• Per i trigger basati sull'archiviazione, è possibile usare un emulatore di archiviazione locale.
• È possibile eseguire manualmente funzioni di trigger non HTTP usando endpoint di amministratore speciali. Per altre informazioni, vedere Eseguire manualmente una funzione non attivata da HTTP.

Durante i test locali, è necessario eseguire l'host fornito da Core Tools (func.exe) in locale. Per altre informazioni, vedere Azure Functions Core Tools.

Strumenti di test HTTP

Durante lo sviluppo, è facile chiamare uno qualsiasi degli endpoint di funzione da un Web browser quando supportano il metodo HTTP GET. Tuttavia, per altri metodi HTTP che supportano payload, ad esempio POST o PUT, è necessario usare uno strumento di test HTTP per creare e inviare queste richieste HTTP agli endpoint di funzione.

È possibile proteggere i dati scegliendo uno strumento di test HTTP che funzioni offline o in locale, non sincronizza i dati nel cloud e non richiede l'accesso a un account online. Alcuni strumenti possono anche proteggere i dati dall'esposizione accidentale implementando funzionalità di sicurezza specifiche.

Evitare di usare strumenti che archiviano centralmente la cronologia delle richieste HTTP (incluse le informazioni riservate), non seguono le procedure di sicurezza consigliate o non rispettano i problemi di privacy dei dati.

Prendere in considerazione l'uso di uno di questi strumenti per l'invio sicuro di richieste HTTP agli endpoint di funzione:

• Visual Studio Code con un'estensione di Visual Studio Marketplace, ad esempio client REST.
• PowerShell Invoke-RestMethod
• Microsoft Edge - Strumento console di rete
• Bruno
• curl

Emulatore di archiviazione locale

Durante lo sviluppo locale, è possibile usare l'emulatore Azurite locale durante il test delle funzioni con le associazioni di Archiviazione di Azure (archiviazione code, archiviazione BLOB e archiviazione tabelle), senza dover connettersi ai servizi di archiviazione remota. Azurite si integra con Visual Studio Code e Visual Studio ed è anche possibile eseguirlo dal prompt dei comandi usando npm. Per altre informazioni, vedere Usare l'emulatore Azurite per lo sviluppo locale di Archiviazione di Azure.

L'impostazione seguente nella raccolta Values del file local.settings.json indica all'host funzioni locale di usare Azurite per la connessione predefinita AzureWebJobsStorage:

"AzureWebJobsStorage": "UseDevelopmentStorage=true"

Con questo valore di impostazione, qualsiasi trigger o associazione di Archiviazione di Azure che usa AzureWebJobsStorage come connessione si connette a Azurite durante l'esecuzione in locale. Tenere presenti queste considerazioni quando si usa l'emulazione dell'archiviazione durante l'esecuzione locale:

• È necessario che Azurite sia installato e in esecuzione.
• È necessario testare con una connessione di archiviazione effettiva ai servizi di Azure prima di eseguire la pubblicazione in Azure.
• Quando si pubblica il progetto, non pubblicare l'impostazione AzureWebJobsStorage come UseDevelopmentStorage=true. In Azure l'impostazione AzureWebJobsStorage deve essere sempre la stringa di connessione dell'account di archiviazione usato dall'app per le funzioni. Per altre informazioni, vedere AzureWebJobsStorage.

Articoli correlati

• Per altre informazioni sullo sviluppo locale di funzioni con Visual Studio Code in un computer Mac, Linux o Windows, vedere Sviluppare funzioni di Azure con Visual Studio Code.
• Per altre informazioni sullo sviluppo di funzioni al prompt dei comandi o terminal, vedere la pagina relativa agli strumenti di base per Funzioni di Azure.