Note sulla versione di Team Foundation Server 2017 Update 2

---

Developer Community Requisiti | disistema e condizioni | di licenza di compatibilità | TFS DevOps | Blog SHA-1 Hashes | Latest Visual Studio 2019 Releases Notes (Note sulle versioni più recenti di Visual Studio 2019)

---

---

Questo articolo contiene informazioni relative a Team Foundation Server 2017 Update 2. Fare clic sul pulsante per continuare.

Per altre informazioni su Team Foundation Server 2017, vedere la pagina compatibilità di Team Foundation Server .

Vedere la pagina di installazione di TFS per altre informazioni.

---

Data di rilascio versione: 24 luglio 2017

Riepilogo delle novità in Team Foundation Server 2017 Update 2

In Team Foundation Server 2017 Update 2 sono state aggiunte numerose nuove funzionalità. Tra le caratteristiche principali:

• Per quanto riguarda gli elementi di lavoro, a ogni tipo di elemento di lavoro sono ora associate icone.
• Sono stati introdotti i piani di recapito.
• È possibile cercare elementi di lavoro tramite la funzione di ricerca di elementi di lavoro.
• È disponibile una nuova esperienza di configurazione dei criteri ramo.
• Sono stati apportati numerosi miglioramenti alle richieste pull.
• Sono ora disponibili grafici Git per visualizzare la cronologia di Git.
• È ora possibile aggiungere e visualizzare tag Git.
• È disponibile una nuova esperienza di Gestione pacchetti.
• È disponibile un nuovo editor di definizioni di compilazione.
• Sono disponibili diversi aggiornamenti per la distribuzione ad app Web di Azure.
• Sono stati apportati numerosi miglioramenti alla distribuzione di contenitori.
• Sono stati introdotte attività di compilazione condizionale.
• Sono ora disponibili notifiche predefinite.

Per i dettagli di tutte le nuove funzionalità, visualizzare i miglioramenti per area:

• Gestione elementi di lavoro
• Controllo della versione
• Richieste pull
• Gestione pacchetti
• Compilazione e versione
• Test
• Warehouse
• Amministrazione
• Integrazione di Microsoft Teams

---

Dettagli delle novità in TFS 2017 Update 2

Miglioramenti alla verifica degli elementi di lavoro

Icone dei tipi di elemento di lavoro

Microsoft si è assunta a livello globale l'impegno di rendere i propri prodotti completamente accessibili ai clienti. Nell'ambito di tale impegno, sono stati individuati e affrontati numerosi problemi di accessibilità, dagli schemi della tastiera alla progettazione e al layout visivi.

In molti casi, per indicare il tipo di elemento di lavoro, la gestione degli elementi di lavoro si è finora basata esclusivamente sul colore. Questo metodo, tuttavia, crea problemi per gli utenti daltonici o ipovedenti, che potrebbero non essere in grado di distinguere alcuni elementi a causa dell'impossibilità di distinguerne i colori. Per favorire il riconoscimento dei tipi di elementi di lavoro da parte di tutti i clienti, nel linguaggio visivo del tipo di elemento di lavoro sono state introdotte le icone. È possibile personalizzare i tipi di elemento di lavoro scegliendo le icone da una selezione di quelle presenti nella libreria.

Le barre colorate indicanti il tipo nelle griglie del backlog e delle query sono state sostituite da icone colorate (Figura 1) .

Le schede sulla bacheca includono ora l'icona del tipo (Figura 2) .

Piani di recapito

I piani di recapito sono uno strumento organizzativo che promuove visibilità e allineamento tra team diversi, verificando lo stato del lavoro in base a un calendario basato sull'iterazione. È possibile personalizzare il piano in modo da includere qualsiasi team o livello di backlog da tutti i progetti dell'account. In più, i criteri campi dei piani consentono di personalizzare ulteriormente la vista, mentre i marcatori evidenziano le date importanti. 

Per altre informazioni e per installare l'estensione, vedere la pagina dei piani di recapito di Visual Studio Marketplace.

I piani di recapito degli utenti con un'istanza TFS disconnessa da Internet sono disponibili direttamente dall'opzione Gestisci estensioni dell'accesso Web, senza dover passare a Visual Studio Team Services Marketplace. In Gestisci estensioni, fare clic su Sfoglia le estensioni locali, quindi selezionare Piani di recapito e fare clic su Installa. Per altre informazioni, vedere la documentazione relativa alle estensioni preinstallate.

Collegamento automatico da elementi di lavoro a compilazioni

Con questa nuova impostazione nella definizione di compilazione è possibile tener traccia delle compilazioni in cui il lavoro è stato incorporato, senza dover effettuare una ricerca manuale all'interno di un ampio set di compilazioni. Ogni compilazione completata associata all'elemento di lavoro in questione viene visualizzata automaticamente nella sezione relativa allo sviluppo del form elemento di lavoro.

Per abilitare questa funzionalità, attivare o disattivare l'impostazione in Opzioni nella definizione di compilazione (Figura 3) .

Form elemento di lavoro precedente deprecato

Il feedback complessivo sul nuovo form elemento di lavoro è stato positivo ed è quindi stato adottato al 100% per gli account ospitati. Per garantire ai clienti locali lo stesso valore che ha reso estremamente soddisfatti gli utenti VSTS, è stato deciso di dichiarare deprecati il form elemento di lavoro e il modello di estendibilità precedenti. Per altre informazioni, vedere la pagina Microsoft Application Lifecycle Management.

Ricerca di elementi di lavoro

La funzione di ricerca di elementi di lavoro rappresenta uno strumento di ricerca rapido e flessibile all'interno di tutti gli elementi di lavoro di tutti i progetti di una raccolta (Figura 4) . È possibile usare il motore di ricerca full-text della funzione di ricerca di elementi di lavoro per cercare termini in tutti i campi degli elementi di lavoro in modo semplice e per individuare in modo efficiente gli elementi di lavoro pertinenti. Per ridurre l'elenco degli elementi di lavoro trovati, è possibile usare filtri di ricerca inline in base a qualsiasi campo di elemento di lavoro.

Una volta configurato il servizio di ricerca in TFS, è possibile effettuare ricerche senza dover installare altri strumenti. Tramite la funzione di ricerca di elementi di lavoro è possibile:

• Eseguire ricerche in tutti i progetti: cercare all'interno del proprio backlog e di quello dei team partner. Per effettuare una ricerca all'interno di tutti gli elementi di lavoro dell'organizzazione, è possibile cercare all'interno degli elementi di lavoro di più progetti. È possibile limitare la ricerca tramite filtri percorso di area e di progetto.
• Eseguire ricerche in tutti i campi degli elementi di lavoro: per trovare elementi di lavoro pertinenti in modo rapido e semplice è possibile cercare in tutti i campi degli elementi di lavoro, compresi i campi ere. Eseguire una ricerca full-text in tutti i campi per individuare in modo efficiente gli elementi di lavoro pertinenti. La visualizzazione frammento di codice indica dove sono state trovate corrispondenze.
• Eseguire ricerche all'interno di campi specifici: per limitare in pochi secondi l'elenco degli elementi di lavoro risultanti, è possibile usare i filtri di ricerca inline su qualsiasi campo di elemento di lavoro. L'elenco a discesa dei suggerimenti consente di completare la ricerca più velocemente. Ad esempio, la ricerca AssignedTo:Chris WorkItemType:Bug State:Active consente di trovare tutti i bug attivi assegnati a un utente con nome Chris.
• Sfruttare i vantaggi dell'integrazione con Verifica elementi di lavoro: l'interfaccia della funzionalità di ricerca degli elementi di lavoro si integra con controlli noti nell'hub Lavoro, consentendo di visualizzare, modificare, commentare, condividere e molto altro ancora.

Miglioramenti al controllo della versione

Nuova esperienza di configurazione dei criteri ramo

L'esperienza di configurazione dei criteri ramo è stata riprogettata con l'aggiunta di alcune nuove eccezionali funzionalità (Figura 5) .  Una delle funzionalità più avanzate è la possibilità di configurare criteri per le cartelle di rami.  È possibile eseguire questa operazione dalla vista Rami selezionando una cartella di ramo e scegliendo Criteri ramo dal menu di scelta rapida.  

Verrà aperta la nuova esperienza utente di configurazione dei criteri, in cui è possibile configurare i criteri che si applicano a tutti i rami nella cartella di rami (Figura 6) .  

Se si usano criteri di compilazione, è ora possibile configurare più compilazioni per un unico ramo.  Sono disponibili anche nuove opzioni per specificare un trigger automatico o manuale (Figura 7) . I trigger manuali sono utili per operazioni che possono richiedere tempi di esecuzione lunghi, ad esempio esecuzioni di test automatizzate, e che è necessario eseguire una sola volta prima di completare la richiesta pull.  I criteri di compilazione hanno anche un nome visualizzato, utile quando si configurano più compilazioni.

Dopo aver configurato criteri attivati manualmente, è possibile eseguirli selezionando l'opzione Accoda compilazione nella sezione Criteri per la richiesta pull (Figura 8) .

Per i criteri per revisori obbligatori (Figura 9) è stata aggiunta la possibilità per gli amministratori di specificare una nota da aggiungere alla sequenza temporale della richiesta pull quando i criteri vengono applicati (Figura 10) .

Nuovi criteri per i commenti non attivi

Verificare che per tutti i commenti nelle richieste pull vengano applicati i nuovi criteri Commenti. Se questi criteri sono abilitati, i commenti attivi bloccano il completamento della richiesta pull, imponendo la risoluzione di tutti i commenti. I revisori che lasciano commenti per l'autore della richiesta pull ma ottimisticamente approvano la richiesta pull hanno la certezza che se l'autore è desideroso di eseguire il merge non trascurerà alcun commento.

Miglioramenti all'hub dei file

Sono stati eseguiti diversi aggiornamenti per l'hub dei file per migliorarne l'esperienza di visualizzazione e modifica.

Per la visualizzazione sono stati aggiunti pivot che consentono di visualizzare il file LEGGIMI nella cartella corrente (Figura 11) , nonché di visualizzare l'anteprima dei file markdown, confrontare un file con una versione precedente (Figura 12) e visualizzare gli errori.

>

Per quanto riguarda la modifica, è ora possibile visualizzare in anteprima le modifiche, aggiungere facilmente un commento, eseguire il commit in un nuovo ramo e collegare elementi di lavoro (Figura 13) .

Visualizzare il repository Git

È ora possibile visualizzare un grafo durante la visualizzazione della cronologia dei commit per i repository o i file. Ciò consente di creare facilmente tramite un grafo Git un modello mentale di tutti i rami e di tutti i commit per i repository Git (Figura 14) . Il grafo mostra tutti i commit in ordine topologico.

Gli elementi principali del grafo Git sono (Figura 15) :

1. Il grafo Git è allineato a destra. Pertanto i commit associati al ramo predefinito o a quello selezionato sono visualizzati a destra, mentre il resto del grafo si espande a sinistra.
2. I commit di merge sono rappresentati da punti grigi connessi al primo e al secondo elemento padre.
3. I commit normali sono rappresentati da punti blu.
4. Se il commit padre di un commit non è visibile nel viewport per i 50 commit successivi, la connessione di commit viene interrotta. Quando si fa clic sulla freccia, il commit viene connesso al commit padre corrispondente.

Visualizzare tag Git per i commit

Se il team usa tag Git per contrassegnare punti specifici nella cronologia del repository, i commit ora visualizzano i tag creati dall'utente. È possibile visualizzare i tag (Figura 16) per un commit specifico nella visualizzazione dell'elenco dei commit e nella pagina dei dettagli.

Aggiungere tag ai commit

Anziché creare tag dalla riga di comando ed eseguirne il push nel repository, è ora possibile passare semplicemente a un commit e aggiungere un tag (Figura 17) . La finestra di dialogo di creazione di tag consente anche di aggiungere tag a qualsiasi altro tipo di riferimento nel repository.

La vista di elenco dei commit supporta anche un menu di scelta rapida (Figura 18) . Per creare tag e nuovi rami non è necessario passare alla pagina dei dettagli del commit(Figura 19) .

Aggiornamento delle pagine degli insiemi di modifiche e degli shelveset

Le pagine degli insiemi di modifiche e degli shelveset nel controllo della versione di Team Foundation sono state modernizzate. Entrambe le pagine sono ora più accessibili per gli utenti che usano dispositivi di assistive technology. Le nuove pagine hanno anche una nuova intestazione che contiene il titolo dell'insieme di modifiche e le informazioni associate, ad esempio i dettagli sull'autore (Figura 20) .

Sia le pagine degli insiemi di modifiche che quelle degli shelveset ospitano anche un nuovo controllo di discussione markdown (Figura 21) che consente di digitare i commenti in markdown, usare @mention per gli utenti, associare elementi di lavoro tramite # e allegare facilmente file e immagini.

Filtro dei commit migliorato

È ora possibile filtrare i risultati della cronologia di commit (Figura 22) in base a opzioni di filtro avanzate. È possibile filtrare i commit per:

• cronologia completa;
• cronologia completa con semplificazione dei merge;
• primo elemento padre;
• cronologia semplice (impostazione di filtro predefinita).

Importare repository dal controllo della versione di Team Foundation a Git

È possibile eseguire la migrazione di codice dai repository del controllo della versione di Team Foundation a repository Git nell'ambito dello stesso account. Per avviare la migrazione, selezionare Importa repository dall'elenco a discesa di selezione del repository (Figura 23) .

È possibile importare nel repository Git singole cartelle o singoli rami oppure l'intero repository del controllo della versione di Team Foundation, meno i rami (Figura 24) . È anche possibile importare un massimo di 180 giorni di cronologia.  

Blocco di file Git LFS

È stata aggiunta la funzionalità di blocco di file Git LFS. Questa funzionalità consente ai team che usano file di grandi dimensioni su cui non è possibile eseguire Diff di evitare di perdere il proprio lavoro se due o più utenti tentano di modificare lo stesso file contemporaneamente. Prima di iniziare a modificare il file, un utente acquisisce un blocco, di cui viene informato il server. Se un altro utente tenta di acquisire un blocco, il server rifiuta la richiesta, informando il secondo utente che il file è già in corso di modifica. Per usare questa funzionalità, eseguire l'aggiornamento a Git LFS 2.1 o versione successiva.

I commenti di commit Git usano il nuovo controllo di discussione

La funzionalità dei commenti brevi ai commit Git è stata aggiornata in modo da consentire l'uso del nuovo controllo di discussione. Grazie all'aggiornamento, tali commenti ora supportano Markdown ed è possibile usare tutte le funzionalità di commento di codice nel Web sia in Git che nel controllo della versione con l'interfaccia più recente.

Nuovo controllo di visualizzazione albero

La visualizzazione dei file di richiesta pull e i dettagli dei commit Git, dei push Git, degli shelveset e degli insiemi di modifiche del controllo della versione di Team Foundation, nonché l'hub degli insiemi del controllo della versione di Team Foundation e l'hub della cronologia Git sono stati aggiornati con un nuovo controllo di visualizzazione albero (figura 25) .  La visualizzazione struttura ad albero contiene alcuni miglioramenti di usabilità.  Prima di tutto, la visualizzazione ora contiene una visualizzazione struttura ad albero ridotta che comprime automaticamente i nodi cartella vuoti, ottimizzando il numero di file visibili.  

L'albero poi mostra i commenti in modo più compatto. Per i file con commenti è visualizzato un elemento figlio per ogni thread di commenti, con l'avatar dell'utente che ha creato il thread.  I thread di commenti nuovi e quelli con risposte sono indicati da un punto blu e il conteggio delle risposte è riepilogato da un numero.

Miglioramenti alle richieste pull

Inviti all'azione migliorati per l'autore della richiesta pull e i revisori

Per i team che usano criteri ramo può essere talvolta difficile sapere esattamente qual è l'azione richiesta quando è visualizzata una richiesta pull. Se l'invito all'azione principale corrisponde al pulsante Completa, significa che la richiesta è pronta per il completamento? Usando le informazioni sull'utente che visualizza la pagina e sullo stato dei criteri ramo configurati, la vista della richiesta pull presenta ora l'invito all'azione più appropriato per tale utente.

Se sono configurati criteri, ma questi non sono stati ancora soddisfatti, il pulsante Completa(Figura 26) lascia il posto alla funzionalità Completamento automatico.  Non è probabile che si riesca a completare la richiesta pull correttamente se i criteri causano un blocco. È quindi disponibile un'opzione che consente di completare automaticamente la richiesta pull quando i criteri vengono infine soddisfatti.

Per i revisori è più probabile dover approvare una richiesta pull piuttosto che doverla completare. Per i revisori viene quindi visualizzato il pulsante Approva(Figura 27) , evidenziato come invito all'azione principale se l'approvazione non è ancora stata effettuata.

Dopo l'approvazione, per i revisori viene visualizzato il pulsante Completa (o Completamento automatico) evidenziato come invito all'azione principale nei casi in cui il revisore è anche l'utente che completa la richiesta pull.

Commenti interattivi

In una richiesta pull con un certo numero di commenti può essere difficile tenere traccia di tutte le conversazioni. Per consentire una gestione più efficace dei commenti, sono stati apportati alcuni miglioramenti per semplificare il processo di risoluzione degli elementi presi in considerazione:

• Nell'intestazione di ogni richiesta pull è ora visualizzato il numero dei commenti risolti (Figura 28) .

• Quando un commento è stato preso in considerazione, è possibile risolverlo con un solo clic (Figura 29) . 

• Se si vogliono aggiungere commenti durante la risoluzione, è possibile rispondere e risolvere con un unico movimento (Figura 30) .

• Man mano che i commenti vengono risolti, si vedrà aumentare il numero finché tutti non saranno stati presi in considerazione (Figura 31) .

• Il filtro nella panoramica è stato migliorato per consentire l'applicazione di filtri in base al diverso stato dei commenti e la visualizzazione del numero di commenti per ogni opzione di filtro (Figura 32) .

La vista Aggiornamenti mostra riassegnazioni e force push

Nella vista dei dettagli della richiesta pull la scheda Aggiornamenti è stata migliorata e ora visualizza quando si è verificato un force push e se il commit di base è stato modificato (Figura 33) .  Queste due funzionalità sono molto utili se si riassegnano le modifiche nei rami a tema prima di completare le richieste pull.  I revisori hanno ora informazioni sufficienti su ciò che è avvenuto.

Filtro di richieste pull per utente

Trovare le richieste pull è ora più semplice. Sono state aggiunte nuove opzioni di filtro che consentono di trovare le richieste pull create da un autore specifico o assegnate a un revisore particolare (Figura 34) . È sufficiente selezionare un utente dal filtro degli autori o dei revisori. L'elenco verrà aggiornato in modo da visualizzare solo le richieste pull che corrispondono al filtro. 

Motivo obbligatorio quando si ignorano i criteri di una richiesta pull

Quando si ignorano i criteri di una richiesta pull, è necessario specificare un motivo.  Se si sceglie di ignorare i criteri, nella finestra di dialogo Completa richiesta pull viene visualizzato il nuovo campo Motivo(Figura 35) .

Dopo aver immesso il motivo e aver completato la richiesta pull, il messaggio viene visualizzato nella panoramica(figura 36).

Condividere richieste pull con altri team

L'azione Condividi richiesta pull è un modo pratico per inviare notifiche ai revisori (Figura 37) .  In questa versione è stato aggiunto il supporto per team e gruppi. È quindi possibile informare tutti i soggetti coinvolti nella richiesta pull in un unico passaggio.

Miglioramenti alle richieste pull per i team

Se si fa parte di più team, ora sarà possibile visualizzare l'elenco di tutte le richieste pull assegnate ai team a cui si appartiene nella visualizzazione Richieste pull personali(Figura 38) . La vista Richieste pull personali rappresenta quindi l'unico punto di riferimento che occorre consultare per visualizzare tutte le richieste pull di proprio interesse.

In una versione futura i team verranno aggiunti all'hub Richieste pull in Codice, per semplificare la visualizzazione di tutte le richieste pull personali per un unico progetto.

Notifiche predefinite per i commenti a richieste pull

La nuova funzionalità relativa alle notifiche predefinite dei commenti consente di seguire tutti gli aggiornamenti alle conversazioni sulle richieste pull di proprio interesse (Figura 39) .  Per le richieste pull create dall'utente, quest'ultimo riceverà automaticamente una notifica ogni volta che un altro utente aggiungerà un nuovo thread di commenti o risponderà a un thread esistente. Quando si inserisce un commento per una richiesta pull di un altro utente, si riceverà una notifica per le eventuali future risposte al thread di commenti creato o a cui si risponde.  

Queste notifiche, disponibili nell'ambito delle sottoscrizioni predefinite, sono configurabili nella pagina di impostazioni Notifiche. 

Miglioramenti a Gestione pacchetti

Aggiornamento dell'esperienza di Gestione pacchetti

L'esperienza utente di Gestione pacchetti è stata aggiornata per renderla più veloce, risolvere problemi comuni segnalati dagli utenti e fare spazio per le funzionalità future relative al ciclo di vita dei pacchetti (Figura 40) .  Per altre informazioni sull'aggiornamento, vedere la pagina Updated Package Management UX (Aggiornamento dell'esperienza utente di Gestione pacchetti).

Aggiunta a Gestione pacchetti dei file LEGGIMI di npm e del pulsante Scarica

È ora possibile visualizzare il file LEGGIMI di qualsiasi pacchetto npm che include un file README.md (Figura 41) . I file LEGGIMI semplificano la documentazione e la condivisione di conoscenze relative ai pacchetti da parte del team.

È anche possibile scaricare qualsiasi pacchetto npm tramite il pulsante Scarica sulla barra dei comandi.

Attività di compilazione di NuGet Restore e NuGet Command

Sono stati implementati aggiornamenti importanti all'attività del programma di installazione NuGet (ora denominato Ripristino NuGet) ed è stata aggiunta una nuova attività NuGet: Comando NuGet. In particolare, per impostazione predefinita le attività Comando NuGet e Ripristino NuGet ora usano nuget.exe 4.0.0.

NuGet Restore è ora ottimizzato per lo scenario più comune di ripristino dei pacchetti prima di un passaggio di compilazione di Visual Studio. Offre anche un supporto più efficiente dei progetti di piccole dimensioni che condividono un unico feed NuGet: è ora possibile selezionare un feed di Team Services e aggiungerlo a un file NuGet.Config generato automaticamente.

Per operazioni NuGet più complesse, l'attività NuGet Command offre la flessibilità necessaria per specificare qualsiasi comando e set di argomenti (Figura 42) .

Miglioramenti alle compilazioni e alle versioni

Nuovo editor delle definizioni di compilazione

L'editor delle definizioni di compilazione è stato riprogettato per offrire un'esperienza più intuitiva, risolvere alcuni punti deboli e aggiungere nuove funzionalità, nella speranza che risulti più semplice usare i modelli, aggiungere attività e modificare le impostazioni. E ora è possibile usare parametri di processo per facilitare l'indicazione dei dati più importanti senza dover addentrarsi nelle attività.

Cercare modelli

È possibile cercare il modello voluto e quindi applicarlo oppure iniziare con un processo vuoto (Figura 43) .

Trovare un'attività e aggiungerla esattamente nel punto voluto

È possibile cercare l'attività che si vuole usare e quindi, dopo averla individuata, è possibile aggiungerla dopo l'attività attualmente selezionata a sinistra oppure trascinarla nel punto in cui si vuole eseguirla (Figura 44) .

È anche possibile trascinare un'attività per spostarla oppure trascinarla tenendo premuto CTRL per copiarla.

Passare argomenti chiave alle attività tramite parametri di processo

È ora possibile usare parametri di processo (Figura 45) per facilitare l'indicazione dei dati più importanti, senza alcuna necessità di addentrarsi nelle attività, per gli utenti che usano la definizione o il modello di compilazione creato.

Se si crea una nuova compilazione da alcuni modelli incorporati, ad esempio Visual Studio e Maven, è possibile visualizzare esempi del loro funzionamento.   Il nuovo editor include alcuni altri miglioramenti, ad esempio una maggiore rapidità di accesso alle impostazioni delle origini.

Per una procedura dettagliata per la creazione della prima definizione di compilazione tramite il nuovo editor, vedere CI/CD for newbies (CI/CD per principianti).

Per altre informazioni, vedere la pagina sull'esperienza utente 2017.

Versioni multiple delle attività di estensione

Gli autori delle estensioni possono ora creare estensioni con più versioni di un'attività specifica. Ciò consente di inviare patch per ogni versione principale in produzione.

Vedere Reference for creating custom build tasks within extensions (Informazioni di riferimento per la creazione di attività di compilazione personalizzate nelle estensioni).

Attività di compilazione condizionale

Se si vuole avere un maggiore controllo sulle attività di compilazione, ad esempio un'attività per eseguire la pulizia o inviare un messaggio quando si verifica un problema, sono ora disponibili quattro opzioni predefinite per controllare un'attività in esecuzione (Figura 46) .

Se si vuole una maggiore flessibilità, ad esempio per eseguire un'attività solo per rami specifici, con trigger particolari, in determinate condizioni, è possibile definire condizioni personalizzate:

and(failed(), eq(variables['Build.Reason'], 'PullRequest'))

Vedere la pagina Specify conditions for running a task (Specificare le condizioni per l'esecuzione di un'attività).

Attività predefinite per la compilazione e la distribuzione di applicazioni basate su contenitore

In questa versione, per impostazione predefinita la maggior parte delle attività presenti nell'estensione Docker è stata spostata nel prodotto e migliorata. È stato anche introdotto un set di nuove attività e di nuovi modelli per rendere più semplice la creazione di un set di scenari contenitore.

• Docker: consente di compilare o eseguire immagini Docker, effettuare il push di tali immagini o eseguire un comando Docker. Questa attività può essere usata con Docker o con il Registro Azure Container. È ora possibile usare l'autenticazione dell'entità servizio incorporata con il Registro Azure Container per renderne ancora più semplice l'uso.
• Docker-Compose: consente di compilare, eseguire o effettuare il push di applicazioni Docker con più contenitori. Questa attività può essere usata con Docker o con il Registro Azure Container.
• Kubernetes: consente di distribuire, configurare o aggiornare il cluster Kubernetes nel servizio Azure Container eseguendo i comandi kubectl.
• Service Fabric: consente di distribuire contenitori in un cluster di Service Fabric. Service Fabric è oggi la scelta migliore per l'esecuzione di contenitori di Windows nel cloud.

Aggiornamenti della distribuzione di app Web di Azure

Sono stati apportati numerosi miglioramenti alle applicazioni Web di Azure:

• L'attività di distribuzione del servizio app di Azure supporta la distribuzione di file WAR Java e Node.js, nonché di applicazioni Python e PHP.
• Tramite i contenitori l'attività di distribuzione del servizio app di Azure supporta la distribuzione di app Web di Azure per Linux.
• La funzionalità di recapito continuo del portale di Azure è stata espansa e ora supporta le applicazioni Node.
• Nel servizio app di Azure è stata aggiunta un'attività di gestione per l'avvio, l'arresto, il riavvio o lo scambio di slot. È ora supportata anche l'installazione di estensioni di siti per consentire l'installazione della versione di PHP o Python richiesta, di Gestione IIS o di Application Insights.

La versione più recente dell'interfaccia della riga di comando di Azure supporta CI/CD e ne consente la configurazione. Ecco un esempio:

az appservice web source-control config --name mywebapp --resource-group mywebapp_rg --repo-url https://myaccount.visualstudio.com/myproject/_git/myrepo --cd-provider vsts --cd-app-type AspNetCore

Supporto dei file di progetto da parte delle attività .NET Core

L'aggiornamento corrente prevede il miglioramento delle attività .NET Core perché supportino i file con estensione csproj oltre al file project.json. È ora possibile usare Visual Studio 2017 con gli agenti di compilazione per compilare applicazioni .NET Core usando file csproj.

Miglioramenti alla distribuzione SSH

L'attività di compilazione/versione Copia file tramite SSH supporta ora il carattere tilde (\~) nel percorso di destinazione, per semplificare la copia di file nella directory home di utenti remoti.   Una nuova opzione, poi, fa in modo che la compilazione/versione non riesca se non sono presenti file da copiare.

L'attività di compilazione/versione SSH supporta ora l'esecuzione di script con terminazioni di riga Windows in computer remoti Linux o macOS.

Installare una chiave SSH durante una compilazione o una versione

Una nuova attività di anteprima, Install SSH Key (Preview) (Installa chiave SSH (anteprima)), consente di installare una chiave SSH prima di una compilazione o di una versione, rimuovendola dall'agente quando la compilazione o la versione è completata. La chiave installata può essere usata per recuperare codice da un repository o da un modulo secondario Git oppure per eseguire script di distribuzione o altre attività che richiedono l'autenticazione SSH. Questa funzionalità verrà migliorata in futuro con il supporto di passphrase e altre funzionalità.

Le attività hanno esito negativo se Visual Studio 2017 è specificato ma non è presente nell'agente

Le attività Compilazione Visual Studio e MSBuild consentono di selezionare una versione di Visual Studio specifica. Finora, se la versione Visual Studio 2017 non era disponibile, queste attività selezionavano automaticamente la versione successiva.

Questo comportamento cambierà. Ora la compilazione ha esito negativo se si seleziona Visual Studio 2017 ma questa versione non è presente nell'agente.

Questa modifica è stata effettuata per i motivi seguenti:

• I tipi di app più recenti, ad esempio .NET Core, non possono essere compilati con strumenti di compilazione precedenti ma richiedono in modo esplicito Visual Studio 2017 o una versione successiva.

• Si ottengono risultati più coerenti e prevedibili se si usa esattamente la stessa versione di Visual Studio.

• Quando l'attività di compilazione non riesce, si potrebbero ricevere errori di compilazione difficili da comprendere.

Pulizia automatica dell'area di lavoro degli agenti privati

È ora possibile configurare un pool di agenti che pulisca periodicamente le directory di lavoro e i repository non aggiornati (Figura 47) . Il pool, ad esempio, eliminerà le aree di lavoro rimaste dopo l'eliminazione di definizioni di compilazione e versione.

Questa opzione riduce la possibilità che gli agenti privati di compilazione e versione esauriscano lo spazio su disco. La manutenzione viene effettuata per agente, non per computer. Pertanto se in un unico computer sono presenti più agenti, sono ancora possibili problemi di spazio su disco.

Stato di aggiornamento degli agenti di compilazione

Quando un agente viene aggiornato, il suo stato di aggiornamento è ora indicato nel portale di gestione delle code e dei pool.

Selezione di agenti privati in computer non in uso

Il sistema ora usa il nome del computer come fattore per l'allocazione di una compilazione o di una versione a un agente privato. Di conseguenza, al momento di allocare un processo il sistema preferisce un agente in un computer inattivo a un agente in un computer occupato.

Coda di pipeline

È stato effettuato il passaggio dal modello di determinazione prezzi basato sull'agente a un modello di determinazione prezzi basato su pipeline. In questo nuovo modello gli utenti possono eseguire simultaneamente un numero di build o versioni corrispondente al numero di pipeline configurate nei rispettivi account. Le build e le versioni aggiuntive che superano questo limite vengono accodate e attendono il completamento delle build e delle versioni precedenti. La funzionalità Coda pipeline offre agli utenti una maggiore visibilità sullo stato delle rispettive build o versioni.

All'avvio della Coda pipeline è possibile visualizzare le informazioni seguenti:

1. Build e versioni in attesa dell'esecuzione di una pipeline e rispettiva posizione nella coda di attesa. 2. Build e versioni attualmente in esecuzione usando le pipeline disponibili.

Durante l'attesa di una pipeline da parte di una build/versione, è anche possibile avviare direttamente questa visualizzazione dalla pagina dei log di build/versione e trovare la rispettiva posizione corrente nella coda di pipeline e altri dettagli.

Azione di rilascio nel riepilogo della compilazione

È attualmente supportata un'azione Versione, disponibile nella barra delle azioni del riepilogo di Build, in modo da semplificare la creazione di una versione per una build.

Sicurezza per gruppi variabili

La sicurezza per i gruppi variabili è ora regolamentata tramite un set di ruoli, ad esempio Autore e Amministratore.

Per impostazione predefinita, vengono assegnati i ruoli seguenti.

• Ruolo Autore per collaboratori
• Amministratori raccolta di progetti, Amministratori progetto, Amministratori compilazione raccolta di progetti, Amministratori compilazione e Amministratori versione
• Ruolo Lettore per utenti validi del progetto

Le impostazioni predefinite possono essere sostituite per tutti i gruppi variabili o per un gruppo specifico.

Miglioramenti a DevOps iOS

L'estensione per App Store di Apple supporta ora la verifica in due passaggi (autenticazione a due fattori) e il rilascio di build a tester esterni (Figura 48) .

Installa certificato Apple (anteprima) è una nuova attività di compilazione che installa un certificato di firma P12 nell'agente per l'uso da parte di una compilazione Xcode o Xamarin.iOS successiva.

Install Apple Profile (Preview) (Installa profilo Apple (anteprima)) è una nuova attività di compilazione per l'installazione di profili di provisioning nell'agente per l'uso da parte di una compilazione Xcode o Xamarin.iOS successiva.

Le attività di compilazione MSBuild, Xamarin.Android e Xamarin.iOS ora supportano la compilazione tramite il set di strumento di Visual Studio per Mac.

Miglioramenti alla code coverage Java

L'attività di compilazione Pubblica risultati di code coverage segnala la code coverage Cobertura o JaCoCo come parte di una compilazione.   Ora l'attività supporta l'uso di caratteri jolly e criteri di corrispondenza minima nei campi File di riepilogo e Directory dei report, consentendo la risoluzione di file e directory in base alla compilazione per i percorsi che cambiano tra una compilazione e l'altra.

Miglioramenti a Maven e SonarQube

L'attività di compilazione Maven consente ora di specificare un progetto di SonarQube per i risultati dell'analisi nei casi in cui ci siano differenze rispetto a quanto specificato nel file pom.xml di Maven.

Miglioramento dell'integrazione di Jenkins

L'attività di compilazione/versione Accoda il processo nel server Jenkins ora supporta l'esecuzione di processi di pipeline Jenkins a più rami durante la visualizzazione dell'output della console Jenkins in Team Services (Figura 49) .   I risultati di pipeline vengono pubblicati nel riepilogo della compilazione di Team Services

Distribuzione di set di scalabilità di macchine virtuali di Azure

Un criterio comunemente usato per la distribuzione consiste nel creare un'immagine completa del computer per ogni versione dell'applicazione da distribuire. Per semplificare questa procedura è disponibile la nuova attività Crea immagine non modificabile. Questa attività usa lo strumento di creazione pacchetti per generare l'immagine di un computer dopo la distribuzione di applicazioni e di tutti i prerequisiti necessari. L'attività accetta lo script di distribuzione o il modello di configurazione dello strumento di creazione pacchetti per creare l'immagine del computer, che archivia in un account di Archiviazione di Azure. Questa immagine può quindi essere usata per distribuzioni di set di scalabilità di macchine virtuali di Azure. Tali distribuzioni sono molto efficienti con questo tipo di distribuzione di immagini non modificabili.

Override dei parametri di modello nelle distribuzioni di gruppi di risorse di Azure

Attualmente nelle attività di distribuzione di gruppi di risorse di Azure si selezionano i file template.json e parameters.json e si specificano i valori dei parametri di override in una casella di testo secondo una sintassi specifica. Questa esperienza è stata ora migliorata in modo che i parametri del modello vengano visualizzati in una griglia che consente di modificarli e di sottoporli a override (figura 50) . È possibile accedere a questa funzionalità facendo clic su ... accanto al campo dei parametri di override. Si aprirà una finestra di dialogo con i parametri di modello e i relativi valori predefiniti e consentiti, se definiti nei file template.json e parameters.json. Questa funzionalità richiede che siano abilitate le regole CORS per l'origine. Se i file template.json e parameters.json sono presenti nel BLOB del servizio di archiviazione di Azure, per abilitare CORS vedere la documentazione dei servizi di Archiviazione di Azure.

Più trigger di rilascio con filtri di ramo e tag

La gestione del rilascio ora supporta l'impostazione di trigger di distribuzione continua per più origini artefatto di tipo "Build". Se aggiunta, una nuova versione viene creata automaticamente quando una nuova versione dell'artefatto è disponibile per qualsiasi origine dell'artefatto specificato. È anche possibile specificare il ramo di origine della nuova compilazione perché si attivi una versione. È poi possibile impostare filtri di tag per filtrare ulteriormente le compilazioni che devono attivare una versione.

Impostare i valori predefiniti per le origini di artefatti in una versione

Gli utenti possono definire la versione di artefatto predefinita da distribuire in una versione al momento di collegare l'origine di un artefatto all'interno di una definizione (Figura 51) . Quando una versione viene creata automaticamente, verrà distribuita la versione predefinita per tutte le origini di artefatto.

Separazione dei compiti per il richiedente e per i responsabili approvazione di una distribuzione

In precedenza, il proprietario di un ambiente poteva impedire agli autori delle versioni di approvare le distribuzioni della versione nell'ambiente in questione. Era possibile, tuttavia, avviare manualmente la distribuzione di una versione creata da un altro utente e approvarla personalmente.

Questa lacuna è stata ora risolta creando per le distribuzioni un ruolo utente separato per l'autore della distribuzione. È possibile impedire l'approvazione delle distribuzioni o all'autore della distribuzione o all'autore della versione.

Approvazioni a livello di versione

È ora possibile scegliere di approvare automaticamente le distribuzioni attivate automaticamente a seguito del completamento della distribuzione in un altro ambiente (Figura 52) . L'approvazione di una catena di distribuzioni, in cui i responsabili approvazione sono gli stessi, può essere eseguita in un'unica operazione se si sceglie di non approvare le distribuzioni una per una.

Si supponga di avere due ambienti, Sviluppo e Test, i cui responsabili approvazione pre-distribuzione sono"utenteA" e "utenteB". La distribuzione deve essere approvata da entrambi. Se i criteri dell'ambiente Test sono impostati come illustrato di seguito, durante il periodo di distribuzione utenteA e utenteB dovranno approvare solo l'ambiente Sviluppo. La distribuzione in Test verrà approvata automaticamente. Se la distribuzione di Test viene attivata manualmente, perché il processo di approvazione si svolga correttamente, l'approvazione esplicita prima della distribuzione sarà invece necessaria.

Distribuire in Azure Government Cloud

I clienti con sottoscrizioni di Azure in Government Clouds possono ora configurare l'endpoint di servizio Azure Resource Manager per l'uso di cloud nazionali come destinazioni.

In questo modo è ora possibile usare Release Management per distribuire qualsiasi applicazione a risorse di Azure ospitate nei cloud per enti pubblici tramite le stesse attività di distribuzione (figura 53) .

Impostare il numero massimo di distribuzioni parallele

Questa funzionalità consente di controllare il numero di versioni in sospeso da distribuire in un ambiente specifico (Figura 54) . Se ad esempio la pipeline di versione esegue la convalida delle compilazioni in un ambiente di controllo di qualità e la frequenza di generazione delle compilazioni è maggiore della velocità di completamento delle distribuzioni, è possibile configurare un certo numero di agenti e lo stesso numero di compilazioni da convalidare in parallelo. Ciò significa che ognuna delle compilazioni generate viene convalidata e che il tempo di attesa dipende dal numero di agenti disponibili. Questa funzionalità consente di ottimizzare il processo di convalida, poiché permette di convalidare le n compilazioni più recenti in parallelo e di annullare le richieste di distribuzione precedenti.

Miglioramenti relativi al timeout per l'attività Intervento manuale

L'attività Intervento manuale può ora essere rifiutata o ripresa automaticamente dopo che è rimasta in sospeso per il periodo di timeout specificato o per 60 giorni, a seconda di quale dei due eventi si verifica per primo.  È possibile specificare il valore di timeout nella sezione delle opzioni di controllo dell'attività. 

Esecuzione parallela di Release Management

Release Management supporta ora l'opzione di esecuzione parallela per una fase (Figura 55) . Selezionare questa opzione per effettuare il fan-out di una fase usando più configurazioni o più agenti come opzione di moltiplicatore della fase.

Più configurazioni: selezionare questa opzione per eseguire la fase per ogni valore di configurazione multipla. Se ad esempio si vuole eseguire la distribuzione in due aree geografiche diverse nello stesso momento, l'uso della variabile ReleasePlatform definita nella scheda Variabili con i valori "east-US, west-US" consente di eseguire la fase in parallelo, in un caso con il valore "east-US" e nell'altro con il valore "west-US". Più agenti: selezionare questa opzione per eseguire la fase con una o più attività in più agenti in parallelo.

Cronologia della distribuzione di app Web nel portale di Azure

La gestione del rilascio ora aggiorna i log di distribuzione del servizio app di Azure quando viene completata una distribuzione tramite l'attività di distribuzione del servizio app. È possibile visualizzare la cronologia di distribuzione nel portale di Azure selezionando l'opzione Recapito continuo nel pannello Servizio App.

Miglioramenti ai test

Eseguire test tramite fasi agente

Tramite l'attività Test di Visual Studio è ora possibile eseguire test automatizzati usando fasi agente (Figura 56) .

Viene ora usato un agente di automazione unificato per compilazione, versione e test, con i vantaggi seguenti:

1. È possibile sfruttare un pool di agenti per le esigenze del test.
2. Eseguire test in modalità diverse usando la stessa attività di test di Visual Studio, in base alle esigenze, ovvero esecuzione basata su agente singolo, esecuzione di test distribuita basata su più agenti o esecuzione di più configurazioni per eseguire test su browser diversi.

Per altre informazioni, fare riferimento a questo post in Microsoft Application Lifecycle Management.

Attivazione di test automatizzati su richiesta

L'hub Test ora supporta il trigger di test case automatizzati da piani di test e gruppi di test (Figura 57) . L'esecuzione di test automatizzati dall'hub Test richiede una configurazione simile a quella usata per eseguire test pianificati in ambienti di versione. Per eseguire test automatizzati, nella definizione di versione è necessario configurare un ambiente usando il modello Run automated tests from test plans (Esegui test automatizzati da piani di test) e associare il piano di test. Vedere la documentazione per le linee guida dettagliate su come configurare gli ambienti ed eseguire test automatizzati dall'hub Test.

Miglioramenti del warehouse

Miglioramenti delle prestazioni dell'elaborazione del cubo di Analysis Services

Le prestazioni della visualizzazione vDimWorkItemTreeOverlay, usata per creare la dimensione Gerarchia albero degli elementi di lavoro in base ai collegamenti, sono state ottimizzate. Anche se dipende dai collegamenti System.LinkTypes.Hierarchy, risulta che la durata dell'elaborazione è influenzata anche da altri collegamenti, ad esempio System.LinkTypes.Related. La visualizzazione è stata ottimizzata in modo da ignorare i tipi di collegamento aggiuntivi che limitano la quantità di dati letti. Questa modifica riduce notevolmente il tempo di elaborazione per determinati warehouse.

Riconciliazione dello schema senza distinzione tra maiuscole e minuscole

Lo schema del database warehouse viene creato unendo i campi di tutti i database della raccolta allegati nel processo di riconciliazione dello schema. In precedenza, tutti i confronti venivano eseguiti facendo distinzione tra maiuscole e minuscole e gli amministratori dovevano verificare la presenza di una corrispondenza esatta per i nomi di riferimento dei campi. Ciò causava problemi nei casi in cui le differenze tra maiuscole e minuscole erano meno evidenti. In questa versione il processo è più tollerante rispetto a tali differenze.

Miglioramenti all'amministrazione

Combinazione dei destinatari per le notifiche tramite posta elettronica

I destinatari della stessa notifica tramite posta elettronica sono ora inclusi tutti insieme nella riga A: e viene inviato un unico messaggio di posta elettronica. In precedenza, venivano inviati messaggi singoli a ogni destinatario. Ciò rendeva difficile sapere chi avesse ricevuto la notifica e stabilire una conversazione sull'evento tramite posta elettronica. Questa funzionalità si applica alle sottoscrizioni sia predefinite che di team, purché siano indirizzabili a più destinatari. A tutti i revisori di una richiesta pull, ad esempio, viene ora inviato un unico messaggio di posta elettronica quando viene apportata una modifica alla richiesta pull stessa.

Altre informazioni sulla combinazione di destinatari di posta elettronica.

Notifiche predefinite

Gli utenti e i team ricevono ora una notifica automatica tramite posta elettronica quando vengono eseguite attività nell'ambito di un account a cui sono direttamente interessati, ad esempio:

• quando un elemento di lavoro viene assegnato a un utente;
• quando un utente o un team viene aggiunto come revisore a una richiesta pull;
• quando un utente o un team è revisore di una richiesta pull che viene aggiornata;
• quando un altro utente risponde a un commento su una richiesta pull;
• quando viene completata una compilazione richiesta da un utente;
• quando un'estensione viene installata o richiesta (solo amministratori).

Gli utenti possono annullare ognuna di queste sottoscrizioni passando alle impostazioni Notifica disponibili nel menu del profilo utente e quindi disattivando l'opzione o le opzioni corrispondenti.

Un account amministratore può disabilitare una o più di queste sottoscrizioni automatiche passando all'hub Notifiche a livello di raccolta tramite l'icona delle impostazioni. Per disabilitare ognuna di queste sottoscrizioni, fare clic su Disabilita nell'azione "…". Una volta disabilitata, una sottoscrizione non compare più nella pagina delle impostazioni delle notifiche personali di ogni utente.

Altre informazioni sulle notifiche predefinite.

Autorizzazioni di gestione delle estensioni

Un amministratore può ora concedere ad altri utenti e a gruppi l'autorizzazione a gestire le estensioni per la raccolta (Figura 58) . In precedenza solo gli amministratori delle raccolte (ad esempio i membri del gruppo Project Collection Administrators) potevano esaminare le richieste di estensione e installare, disabilitare o disinstallare estensioni. 

Per concedere questa autorizzazione, un amministratore può passare all'hub di amministrazione delle estensioni aprendo il menu Marketplace, selezionando Gestisci le estensioni e quindi facendo clic sul pulsante Sicurezza:

Ricevere notifiche quando le estensioni vengono installate, richiedono attenzione e così via

Gli amministratori o gli utenti autorizzati a gestire le estensioni ricevono ora una notifica automatica quando un'estensione viene installata, disinstallata, abilitata o disabilitata oppure quando richiede l'attenzione dell'utente. Questa funzionalità è particolarmente utile nelle distribuzioni di grandi dimensioni, in cui la responsabilità della gestione delle estensioni è condivisa da più utenti. Gli amministratori possono disattivare le notifiche nelle impostazioni Notifica disponibili dal menu del profilo disattivando l'opzione relativa alle estensioni.

Gli amministratori possono anche definire sottoscrizioni personalizzate per gli eventi correlati alle estensioni. Un amministratore, ad esempio, può ricevere una notifica ogni volta che un'estensione viene aggiornata.

Ora gli utenti possono anche disattivare le notifiche automatiche relative alle proprie richieste relative alle estensioni.

Autorizzazione agli amministratori TFS per l'aggiunta di sottoscrittori al livello di accesso avanzato

Il livello di accesso Avanzato verrà rimosso dalle versioni future di Team Foundation Server. Fino a quel momento, tuttavia, gli amministratori di TFS avranno la possibilità di aggiungere sottoscrittori della piattaforma MSDN e di Visual Studio Test Professional al livello di accesso Avanzato con Update 2.

I sottoscrittori di Visual Studio Enterprise devono essere aggiunti al livello di accesso di Visual Studio Enterprise anziché al livello di accesso Avanzato. Se si è acquistata l'estensione Test Manager, continuare a gestirla nell'hub Utenti all'interno del progetto team da cui l'acquisto è stato effettuato.

Integrazione di Microsoft Teams

Le organizzazioni che usano Microsoft Teams per collaborare ora possono visualizzare l'attività dai propri progetti TFS all'interno dei canali del team. Questo consente ai team di essere sempre informati in caso di modifiche importanti apportate a elementi di lavoro, richieste pull, build, rilascio di versioni e altro ancora mentre lavorano in Microsoft Teams. Per altre informazioni, vedere la documentazione.

---

Problemi noti

Il rendering dei form dell'elemento di lavoro non viene eseguito correttamente nel Web

• Problema:

  Se si ha un controllo personalizzato, ad esempio il controllo multivalore, installato per il client Visual Studio ma non per il client Web, non viene eseguito il rendering dei form dell'elemento di lavoro nel Web.

• Soluzione alternativa:

  È necessario eseguire l'aggiornamento alla versione più recente del controllo. È necessario aggiungere un layout Web che non contenga l'elemento del controllo mancante. È possibile trovare il controllo multivalore più recente per l'aggiornamento a TFS 2017 nella pagina Custom Controls for TFS Work Item Tracking (Controlli personalizzati per la verifica di elementi di lavoro TFS). Per altre informazioni sul layout, vedere la pagina All FORM XML elements reference (TFS 2015) (Informazioni di riferimento su tutti gli elementi XML FORM (TFS 2015)).

La versione di TFS è RC2 invece della versione finale

• Problema:

  Dopo aver scaricato e installato Team Foundation Server 2017 Update 2 prima del 1 agosto 2017, è presente una versione RC2.

• Soluzione alternativa:

  Ciò è dovuto a un problema temporaneo dei collegamenti di installazione che è stato risolto il 1 agosto 2017. Scaricare di nuovo Team Foundation Server 2017 Update 2 e installare questa versione finale.

Vedere i problemi segnalati dai clienti per Team Foundation Server 2017.

---

Feedback e suggerimenti

Le opinioni dei nostri clienti sono molto importanti per noi. È possibile segnalare un problema e tenerne traccia tramite la community degli sviluppatori per suggerimenti sull'overflow dello stack.

---

Inizio pagina