Microsoft AZ-400: Gestione dei pacchetti e gestione degli artefatti — Guida allo studio

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Fa parte della Microsoft DevOps Engineer Expert AZ-400 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

La gestione dei pacchetti è la colonna portante di build riproducibili, deployment affidabili e supply chain sicure in Azure DevOps. Azure Artifacts centralizza l’archiviazione e la governance dei pacchetti attraverso vari ecosistemi — NuGet, npm, Maven, Gradle e Universal packages — abilitando al contempo il caching upstream da registri pubblici e controlli granulari per la promozione, la conservazione e le autorizzazioni. In combinazione con l’automazione del versioning semantico e gli strumenti di sicurezza/conformità, consente di standardizzare come le dipendenze interne ed esterne vengono prodotte, individuate, approvate e utilizzate su larga scala.

Concetti Fondamentali di Azure Artifacts

Un feed è l’unità di archiviazione e controllo degli accessi per i pacchetti. I team tipicamente organizzano i feed per prodotto, piattaforma o confine di attendibilità (trust boundary) (ad es., un feed per tutte le dipendenze OSS pubbliche tramite upstream, uno per le librerie interne condivise e uno per ogni prodotto). I feed supportano più tipi di pacchetto, ognuno con i propri strumenti client.

Le viste (view) implementano un modello di promozione controllata (gated) all’interno di un singolo feed:

local: tutti i pacchetti appena pubblicati compaiono qui
prerelease: usata per esporre build beta/nightly a early adopter e pipeline di integrazione
release: solo i pacchetti approvati per la produzione vengono promossi qui per un utilizzo su vasta scala I consumer puntano a una vista specifica per evitare automaticamente contenuti instabili. Promuovi o degrada le versioni come parte del tuo processo di rilascio per controllare il raggio d’impatto (blast radius).

Le origini upstream (upstream source) collegano un feed a registri pubblici (NuGet.org, npmjs.com, Maven Central). Quando abilitate, gli sviluppatori risolvono le dipendenze pubbliche attraverso il tuo feed. Azure Artifacts funge da proxy e memorizza nella cache in modo trasparente le versioni esatte che vengono utilizzate, migliorando l’affidabilità, abilitando scenari air-gapped e consentendo di “congelare” in seguito la supply chain disabilitando nuovi download upstream. È possibile definire l’ambito (scope) di quali upstream sono abilitati per ogni feed per soddisfare le policy.

La conservazione (retention) viene applicata per ridurre i costi di archiviazione preservando ciò che è importante. Definisci policy per conservare le ultime N versioni per pacchetto, mantenere solo le versioni promosse a ‘release’ ed eliminare automaticamente le vecchie prerelease. Fissa (pin) versioni specifiche per escluderle dalla pulizia (ad es., quelle incorporate in un branch di prodotto a lunga vita). Allinea le finestre di conservazione ai requisiti di audit e rollback per bilanciare la tracciabilità con i costi di archiviazione.

Le autorizzazioni del feed seguono il principio del privilegio minimo (least-privilege):

Owner: gestisce le impostazioni del feed, le autorizzazioni, le viste e le policy di conservazione
Contributor: pubblica, rimuove (unlist), depreca e promuove pacchetti; non può modificare le impostazioni a livello di feed
Reader: solo ripristino/utilizzo (restore/consume); non può modificare i pacchetti Nota: “Collaborator” non è un ruolo di un feed di Azure Artifacts. Se si incontra questo termine, mappare la sua capacità prevista (spesso “può pubblicare”) al ruolo di Contributor in Azure Artifacts.

Gestione degli Ecosistemi di Pacchetti

NuGet (dotnet/C#)

Versioning: Preferire SemVer 2.0.0 (es. 1.4.0, 1.4.1-alpha.3+build.45). Le etichette di pre-release controllano la distribuzione tramite le viste; i consumer della vista ‘release’ non incontrano mai le varianti -alpha/-beta.
Pubblicazione: dotnet pack o nuget pack, poi dotnet nuget push o nuget push verso l’endpoint del tuo feed. Usa i task NuGet di Azure Pipelines e promuovi alle viste ‘prerelease’/‘release’ al superamento dei quality gate.
Utilizzo: configurare nuget.config con l’URI di origine del feed (opzionalmente limitato a una vista). Ripristinare tramite dotnet restore o il task NuGet Restore.
Feed autenticati: usare l’Azure Artifacts Credential Provider (integrato negli SDK dotnet recenti) o il task di pipeline NuGet Authenticate. Per gli sviluppatori, accedere tramite Visual Studio/Azure CLI; per la CI, concedere al service principal della build i permessi di Reader/Contributor secondo necessità.

npm (JavaScript/TypeScript)

Pacchetti con scope: pubblicare i pacchetti interni sotto uno scope organizzativo, es. @fabrikam/button. Gli scope si mappano naturalmente alle autorizzazioni del feed e consentono di limitare l’utilizzo tra progetti diversi.
.npmrc: impostare registry=https://pkgs.dev.azure.com/ORG/PROJECT/_packaging/FEED/npm/registry/, always-auth=true, e opzionalmente @scope:registry=... per configurazioni multi-registro. In CI, usare il task npm Authenticate per iniettare un token di autenticazione temporaneo. In locale, npm login con un PAT.
Registro privato: Azure Artifacts agisce come un registro npm privato con upstream verso npmjs.com. Utilizzare pacchetti solo dalla vista ‘release’ per bloccare le prerelease non approvate.

Maven e Gradle (Java/Kotlin)

Pubblicazione (Maven): definire distributionManagement nel pom.xml che punta al tuo feed e una voce server nel settings.xml con le credenziali (PAT o service connection). Usare mvn deploy o il task Maven in Azure Pipelines.
Pubblicazione (Gradle): applicare il plugin maven-publish e configurare repositories { maven { url = "https://pkgs.dev.azure.com/..." credentials { } } }, quindi pubblicare con gradle publish.
Risoluzione delle dipendenze: aggiungere l’endpoint del feed (opzionalmente con il suffisso della vista) a repositories in Gradle o a repositories nel pom.xml per Maven. Adottare SNAPSHOT per le build di sviluppo e promuovere le versioni di rilascio alla vista ‘release’ per i consumer stabili.

Universal packages (blob binari, script, modelli)

Versioning: seguire uno stile SemVer o versioni intere; ogni pubblicazione è immutabile. Usare questo tipo per artefatti che non si adattano agli ecosistemi specifici di un linguaggio.
Task di pubblicazione/download: usare i task di Azure DevOps Universal Publish e Universal Download nelle pipeline, o l’Azure CLI (az artifacts universal publish/download). Autenticarsi tramite una service connection di Azure DevOps o un’identità autenticata.
Casi d’uso: CLI condivise, moduli IaC, dati di test, modelli di ML o asset cross-linguaggio per cui sono necessari RBAC, conservazione e promozione ma non strumenti specifici del linguaggio.

Controlli di Sicurezza e Conformità

La scansione delle vulnerabilità deve essere applicata al momento del commit e della build. Integrare strumenti che identificano le dipendenze con vulnerabilità note e forniscono indicazioni per l’aggiornamento. In molti ambienti Azure DevOps, SonarQube è utilizzato come parte della strategia di quality gate per segnalare problemi, includendo regole che evidenziano i rischi legati alle dipendenze; è possibile integrarlo con strumenti SCA dedicati (es. Snyk, Mend/WhiteSource o Black Duck) per una copertura CVE più esaustiva tra gli ecosistemi. Per .NET, dotnet list package –vulnerable e per npm, npm audit possono fornire segnali aggiuntivi; per Java, OWASP Dependency-Check può essere aggiunto come passaggio della build.

La conformità delle licenze viene applicata scansionando SBOM o manifest a fronte di una lista di licenze approvate. Black Duck è comunemente aggiunto ad Azure Pipelines per bloccare le build quando vengono rilevate licenze con restrizioni. Archiviare i report di scansione come artefatti della pipeline e allegarli alle release per garantirne l’auditabilità.

La gestione dei pacchetti consentiti/bloccati è implementata al meglio come policy piuttosto che con eccezioni ad hoc:

Limitare i consumer alla vista di release; promuovere solo le versioni verificate.
Disabilitare i nuovi download da upstream quando è necessario un freeze, garantendo che siano disponibili solo le versioni memorizzate nella cache.
Usare gli scope npm e i permessi per-feed per limitare i namespace.
Aggiungere controlli nella pipeline per far fallire le build in caso di pacchetti o licenze non consentiti e usare la promozione degli artefatti come flusso di lavoro di approvazione.

Le attività di audit e governance traggono vantaggio da feed centralizzati con caching upstream: si ottiene un unico punto di controllo per l’ingresso dei pacchetti, cronologie immutabili e una provenienza coerente per la generazione di SBOM.

Automazione del Versioning e Gestione Economica della Retention

Il versioning semantico è più facile da mantenere con l’automazione:

GitVersion legge la cronologia di Git e le convenzioni di denominazione dei branch per calcolare le versioni in modo prevedibile (es. main produce 1.4.0, feature/* produce 1.5.0-feature.3). Configurare la modalità (Mainline o Continuous Delivery), le etichette di pre-release e le sorgenti dei tag. Iniettare la versione calcolata in csproj, package.json o nella proprietà version di Gradle prima dell’impacchettamento.
L’incremento automatico della versione può seguire la semantica dei commit o le etichette delle PR. Ad esempio, chore non incrementa la versione, feat incrementa la minor, fix la patch; breaking-change incrementa la major. Usare un passaggio della pipeline per impostare il buildNumber e passare la versione ai task di pack/publish.
Le etichette di pre-release dovrebbero riflettere l’intento del branch (es. -alpha sui branch di feature, -rc sui branch di release). Pubblicare le prerelease nella vista di prerelease e promuoverle a release dopo uno staging completato con successo.

La gestione dei costi di retention e storage richiede policy proattive:

Pulizia automatica: configurare la retention per-feed per eliminare le versioni più vecchie e non promosse dopo N giorni/versioni. Estendere i periodi per le librerie critiche con orizzonti di supporto lunghi.
Pinning: effettuare il ‘pinning’ esplicito delle versioni incorporate in prodotti a lunga vita o in snapshot di conformità per escluderle dalla cancellazione.
Ottimizzazione dello storage: preferire il caching upstream alla pubblicazione locale di duplicati di pacchetti pubblici e consolidare i feed dove possibile per ridurre l’overhead. Monitorare la crescita dello storage dei feed e adeguare periodicamente le soglie delle policy.

Specifiche delle sorgenti upstream:

NuGet: connettersi a https://api.nuget.org/v3/index.json come upstream per usare un proxy e memorizzare nella cache i pacchetti di NuGet.org.
npm: connettersi a https://registry.npmjs.com per memorizzare nella cache le dipendenze di npmjs.com dietro al proprio feed autenticato.
Maven: connettersi a Maven Central (es. https://repo.maven.apache.org/maven2) in modo che i consumer aziendali scarichino i pacchetti tramite il vostro feed con un unico URL.

### Scenario di un Problema Pratico

Adobe ha la necessità di standardizzare la governance dei pacchetti su più cloud e linguaggi, riducendo al contempo le interruzioni di servizio dovute all’instabilità dei registri pubblici e applicando le policy sulle licenze. I team pubblicano artefatti interni NuGet, npm e Maven e condividono grandi strumenti CLI cross-linguaggio.

Stabilire feed centralizzati e upstream

Azione: Creare tre feed di Azure Artifacts: “oss-upstream” (con upstream verso NuGet.org, npmjs.com, Maven Central), “shared-libs” (librerie interne) e “productA” (pacchetti a livello di applicazione). Abilitare le viste (view) local, prerelease, release su tutti i feed.
Motivazione: “oss-upstream” diventa il singolo punto di ingresso/caching; “shared-libs” e “productA” separano i confini di fiducia (trust boundary) e i flussi di lavoro di promozione.

Configurare il consumo da parte dei client tramite le viste (view)

Azione: Indirizzare i repository di nuget.config, .npmrc, settings.xml/Gradle alla vista di rilascio (release) di ciascun feed per i consumatori di runtime, e alla vista di pre-rilascio (prerelease) per le pipeline di test di integrazione.
Motivazione: Le viste garantiscono che solo i pacchetti promossi e verificati raggiungano i consumatori di produzione senza modificare le configurazioni dei client.

Implementare la pubblicazione con il versioning semantico

Azione: Aggiungere GitVersion alla CI per librerie e app. Pilotare l’iniezione della versione nei comandi dotnet pack, npm version (senza tagging Git, controllato dalla pipeline) e nei campi di versione di Gradle/Maven. Pubblicare nella vista local; promuovere a prerelease dopo il successo della CI; promuovere automaticamente a release dopo i test di staging.
Motivazione: Il versioning deterministico allineato al Git flow garantisce etichette di pre-release coerenti e promozioni pronte per l’automazione.

Proteggere i feed autenticati e la developer experience

Azione: Utilizzare i task NuGet Authenticate e npm Authenticate nelle pipeline; abilitare Azure Artifacts Credential Provider per le macchine degli sviluppatori; configurare i server in settings.xml di Maven con PAT soggetti a rotazione tramite i gruppi di variabili di Azure DevOps.
Motivazione: L’autenticazione trasparente basata su token previene la proliferazione delle credenziali (credential sprawl) e supporta il ripristino non interattivo nelle CI.

Applicare le policy su vulnerabilità e licenze

Azione: Aggiungere quality gate di SonarQube alle build; integrare Black Duck per applicare le allowlist delle licenze e bloccare le build con licenze non consentite o CVE ad alta gravità. Per npm e .NET, eseguire npm audit e dotnet list package --vulnerable; pubblicare gli SBOM come artefatti di build.
Motivazione: Scanner multipli e complementari riducono i punti ciechi; Black Duck fornisce conformità delle licenze su larga scala, mentre SonarQube e gli strumenti dell’ecosistema individuano precocemente le regressioni di sicurezza.

Controllare l’ingresso e bloccarlo quando necessario

Azione: Consentire i download upstream solo da “oss-upstream”; disabilitare nuovi ingressi upstream durante la risposta a un incidente per “congelare” la supply chain. Fare affidamento sui pacchetti in cache per mantenere le build funzionanti.
Motivazione: Un punto di controllo centralizzato (choke point) consente un contenimento rapido se un registro pubblico è compromesso o instabile.

Applicare la retention e il pinning

Azione: Conservare le ultime 5 versioni per shared-libs e productA; eliminare le versioni non promosse più vecchie di 30 giorni; “pinnare” le versioni legate a rami LTS e a baseline normative.
Motivazione: La pulizia automatizzata riduce i costi di archiviazione, mentre il pinning preserva l’auditabilità e la possibilità di rollback.

Delegare l’accesso con il principio del minimo privilegio (least-privilege)

Azione: Assegnare il ruolo di Owner al team di platform engineering; Contributor ai manutentori delle librerie che devono pubblicare/deprecare; Reader ai team di prodotto che consumano solo artefatti di rilascio.
Motivazione: Allinea le capacità alle responsabilità; gli sviluppatori possono rimuovere dalla lista (unlist)/deprecare senza avere ampi diritti amministrativi.

Pacchetti universali (Universal packages) per strumenti cross-language

Azione: Pubblicare CLI interne e moduli IaC come pacchetti universali tramite i task Universal Publish/Download; versionarli semanticamente e promuoverli tramite le viste.
Motivazione: Fornisce RBAC, retention e promozione per asset non specifici di un linguaggio con un modello di consumo coerente.

Misurare e iterare

Azione: Monitorare lo storage dei feed, i tassi di cache hit e i tempi di promozione; adeguare di conseguenza le soglie di retention, le policy di upstream e i criteri di promozione.
Motivazione: L’ottimizzazione continua mantiene l’affidabilità, l’efficienza dei costi e la conformità man mano che la scala del portfolio si evolve.

← Monitoraggio · Tutti i domini · Pianificazione Agile e gestione del lavoro →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →