Cos'è Azure Artifacts?
Questa unità comprende una breve panoramica su come usare Azure Artifacts per creare e gestire in modo sicuro pacchetti che possono essere usati dalle app.
Il team sta decidendo se Azure Artifacts è il modo appropriato per ospitare il pacchetto .NET.
Mara: Sembra che il nuovo pacchetto di modelli possa essere ospitato in Azure Artifacts. Facendo già parte dell'organizzazione Microsoft Azure DevOps, è più semplice eseguire l'autenticazione che configurare un'altra gestione pacchetti.
Andy: Ho esaminato la questione prima della riunione e mi sembra fattibile. Sono d'accordo con Mara.
Amita: Cos'è Azure Artifacts?
Andy: Azure Artifacts è un repository dell'organizzazione Azure DevOps in cui è possibile gestire le dipendenze per la codebase. Azure Artifacts consente di archiviare gli artefatti e i file binari. Consente di usare un contenitore, detto feed, per i gruppi di dipendenze. Gli sviluppatori che hanno accesso al feed possono usare o pubblicare facilmente i pacchetti.
Come si crea un pacchetto e lo si usa nella pipeline?
Tim: Quindi, se ho capito bene, il codice dell'app usa già i pacchetti di NuGet. Creeremo un nuovo pacchetto che verrà ospitato in Azure Artifacts. Puoi descrivere i vari componenti e il modo in cui interagiscono? Ho difficoltà a capire l'intero processo.
Andy: Certo. Ecco il processo di creazione di un pacchetto e come viene usato nella pipeline di Azure DevOps.
Andy si sposta verso la lavagna.
Creare il pacchetto
Prima di tutto dobbiamo creare un progetto in Azure Artifacts. 
Questa operazione può essere eseguita in Azure DevOps.
Viene poi creata una pipeline in Azure Pipelines che si connette al repository GitHub per il codice del pacchetto. La pipeline compila quindi il codice, lo inserisce in un pacchetto ed effettua il push del pacchetto ad Azure Artifacts. 
È necessario aggiornare l'app che usa questo pacchetto in modo che punti al feed di Azure Artifacts creato. 
Aggiorneremo poi la pipeline che crea l'app. L'aggiornamento consente di usare il feed di Azure Artifacts per effettuare il pull della nuova dipendenza del pacchetto e compilarla normalmente. 
Aggiornare il pacchetto
Tim: Cosa accade se qualcuno aggiorna il pacchetto?
Andy: Quando si aggiorna il pacchetto con una nuova funzionalità o con la correzione di un bug e si eseguono i test per assicurarsi che funzioni correttamente, si deve aumentare il numero di versione del pacchetto. E poi esegue il commit della modifica. La pipeline per il pacchetto visualizza il commit e crea un nuovo artefatto in Azure Artifacts con il nuovo numero di versione. Non c'è da preoccuparsi, il vecchio pacchetto con il numero di versione precedente è ancora disponibile per le app che dipendono da quella versione. Questo è il motivo per cui in genere non si annulla l'elenco di un pacchetto.
L'app potrebbe usare questa nuova versione del pacchetto. In tal caso, l'app viene aggiornata in modo da fare riferimento alla versione più recente e si eseguono i test in locale per assicurarsi che la nuova versione funzioni con l'app. Quando tutto funziona correttamente, la modifica dell'app viene inviata alla pipeline e compilata con la nuova versione della dipendenza del pacchetto.
Amita: Sembra un ottimo piano e sarà utile anche per l'altro team. Eviterà la deviazione del codice quando viene inserito. Questo faciliterà anche il lavoro del controllo di qualità.
Includere una strategia di controllo delle versioni nella pipeline di compilazione
Quando si usa una pipeline di compilazione, è necessario assegnare una versione ai pacchetti prima di poterli usare e testare. Tuttavia, solo dopo aver testato il pacchetto, è possibile conoscerne la qualità. Poiché le versioni dei pacchetti non devono mai essere modificate, diventa difficile scegliere in anticipo una determinata versione.
Nei propri feed Azure Artifacts associa un livello di qualità a ogni pacchetto, oltre a distinguere tra versioni non definitive e versioni di rilascio. Azure Artifacts offre diverse visualizzazioni dell'elenco di pacchetti e delle relative versioni, differenziate in base al livello di qualità. Questo approccio funziona bene con il controllo delle versioni semantico, che è utile per prevedere le finalità di una particolare versione. Azure Artifacts usa anche un descrittore per includere metadati aggiuntivi dal feed di Azure Artifacts. Un uso comune delle visualizzazioni consiste nel condividere le versioni dei pacchetti testate, convalidate o distribuite, ma trattenere i pacchetti ancora in fase di sviluppo e che non sono pronti per l'uso pubblico.
Per impostazione predefinita, i feed di Azure Artifacts hanno tre visualizzazioni diverse. Queste visualizzazioni vengono aggiunte nel momento in cui viene creato un nuovo feed. Le tre visualizzazioni sono:
- Versione: La visualizzazione @release contiene tutti i pacchetti considerati come versioni ufficiali.
- Versione preliminare: La visualizzazione @prerelease contiene tutti i pacchetti con un'etichetta nel numero di versione.
- Locale: La visualizzazione @local contiene tutti i pacchetti della versione definitiva e di quella non definitiva e i pacchetti scaricati dalle origini upstream.
Le visualizzazioni possono essere usate per consentire agli utenti di un feed del pacchetto di applicare un filtro che separi le versioni rilasciate dei pacchetti da quelle non rilasciate. In pratica, le visualizzazioni consentono a un utente di prendere una decisione cosciente e di scegliere tra i pacchetti rilasciati o di acconsentire esplicitamente alle versioni preliminari di un determinato livello di qualità.
Sicurezza del pacchetto in Azure Artifacts
Garantire la sicurezza dei pacchetti è importante quanto garantire la sicurezza del resto del codice. Un aspetto della sicurezza dei pacchetti è la protezione dell'accesso ai feed di pacchetti. Un feed, in Azure Artifacts, è la posizione in cui vengono archiviati i pacchetti. L'impostazione delle autorizzazioni nel feed consente di condividere i pacchetti con il numero di utenti necessario per lo scenario in uso.
Autorizzazioni di feed
I feed hanno quattro livelli di accesso: proprietari, autori di contributi, collaboratori e lettori. Ogni livello di accesso dispone di un determinato set di autorizzazioni. Ad esempio, i proprietari possono aggiungere qualsiasi tipo di identità, ovvero singoli utenti, team e gruppi, a qualsiasi livello di accesso. Per impostazione predefinita, il Servizio di compilazione raccolta di progetti è un Collaboratore e il team del progetto è Lettore.
Configurare la pipeline per accedere alle classificazioni di sicurezza e licenze
Sono disponibili diversi strumenti di terze parti che consentono di valutare la classificazione di sicurezza e delle licenze dei pacchetti software usati.
Alcuni di questi strumenti analizzano i pacchetti così come sono inclusi nella pipeline di compilazione o di distribuzione continua. Durante il processo di compilazione, lo strumento analizza i pacchetti e genera un feedback immediato. Durante il processo di distribuzione continua, lo strumento usa gli artefatti della compilazione ed esegue le analisi. Due esempi di questi strumenti sono Mend Bolt e Black Duck. Con Azure DevOps è possibile usare le attività di compilazione per incorporare l'analisi nella pipeline.