Condividi tramite


Conformità della pipeline e convalide di sicurezza - Aggiornamento sprint 141

Nell'aggiornamento sprint 141 di Azure DevOps Services è ora possibile includere le convalide di conformità e sicurezza in Azure Pipelines. In Azure Repos è possibile modificare il ramo di destinazione delle richieste pull.

Per altre informazioni, vedere l'elenco delle funzionalità riportato di seguito.

Funzionalità

Generale:

Azure Pipelines:

Azure Repos:

Amministrazione:

Passaggi successivi

Annotazioni

Queste funzionalità verranno implementate nelle prossime due o tre settimane.

Leggere le nuove funzionalità seguenti e passare ad Azure DevOps Services per provare manualmente.

General

A giugno di quest'anno è stata implementata la prima iterazione del nuovo modello di navigazione. Abbiamo trascorso l'estate migliorando l'esperienza in base al feedback fornito da molti di voi. Grazie. Il prossimo passo sarà passare dal nuovo modello come anteprima per diventare la navigazione del prodotto. Leggere il post di blog che descrive le modifiche recenti insieme alla pianificazione per portare il nuovo modello a tutte le organizzazioni.

Comprendiamo l'importanza della ricerca e stiamo riportando la casella di ricerca espansa nell'intestazione del prodotto. È anche possibile richiamare la casella di ricerca facendo clic su "/" in qualsiasi pagina del servizio in Azure DevOps. Questa funzionalità è stata assegnata in ordine di priorità in base a un suggerimento vocale dell'utente.

Ecco la casella di ricerca predefinita:

Casella di ricerca predefinita

Dopo aver digitato "/", verrà visualizzata la casella di ricerca espansa:

Casella di ricerca espansa

Azure Pipelines

Convalide di conformità e sicurezza relative ai criteri di Azure in Azure Pipelines

Vogliamo garantire stabilità e sicurezza del software all'inizio del processo di sviluppo, mettendo insieme lo sviluppo, la sicurezza e le operazioni. A tale scopo, è stato aggiunto il supporto per Criteri di Azure.

Azure Policy aiuta a gestire e prevenire i problemi informatici con definizioni di policy che applicano regole ed effetti per le risorse. Quando si usano i criteri di Azure, le risorse rimangono conformi agli standard aziendali e agli accordi sul livello del servizio.

Per rispettare le linee guida per la conformità e la sicurezza nell'ambito del processo di rilascio, è stata migliorata l'esperienza di distribuzione del gruppo di risorse di Azure. In questo caso, l'attività di distribuzione del gruppo di risorse di Azure ha esito negativo con errori correlati ai criteri pertinenti in caso di violazioni durante la distribuzione dei modelli di Resource Manager.

Criteri di Azure

Sono stati inoltre aggiunti modello di definizione del rilascio dei criteri di Azure. In questo modo gli utenti potranno creare criteri di Azure e assegnare questi criteri a risorse, sottoscrizioni o gruppi di gestione dalla definizione di versione stessa.

modello di Criteri di Azure

Recapito continuo semplificato per le VM di Azure

In questa versione è stata aggiunta una nuova procedura guidata per semplificare il processo di configurazione del recapito continuo alle macchine virtuali di Azure. Dopo aver specificato un'organizzazione di Azure DevOps e un gruppo di distribuzione per registrare la macchina virtuale, verrà creata automaticamente una pipeline di versione con un passaggio di script di esempio. Se è necessario effettuare il provisioning di risorse di Azure aggiuntive, eseguire script, aggiornare l'applicazione o eseguire test di convalida aggiuntivi, è possibile personalizzare facilmente questa pipeline di versione.

CI su macchine virtuali di Azure

L'attività Xcode supporta il nuovo Xcode 10 appena rilasciato

In coincidenza con la versione di Apple di Xcode 10, è ora possibile impostare i progetti per compilare o essere testati in modo specifico con Xcode 10. La pipeline può anche eseguire processi in parallelo con una matrice di versioni di Xcode. È possibile usare il pool di agenti macOS ospitato da Microsoft per eseguire queste compilazioni. Vedere le indicazioni per l'uso di Xcode in Azure Pipelines.

Xcode 10

Miglioramenti alle prestazioni durante l'accodamento di una build

Quando si usa un agente ospitato, si ottiene una nuova macchina virtuale per ogni processo. In questo modo è disponibile un livello aggiuntivo di sicurezza e controllo. Non c'è mai bisogno di preoccuparsi che una build precedente lasci in giro degli output o compia azioni dannose per la macchina. Tuttavia, in precedenza le attività di avvio iniziale comportavano ritardi tra il momento in cui si cliccava su Accoda un build e quando la pipeline era effettivamente in esecuzione. Abbiamo esaminato e risolto molti di questi ritardi e stiamo ora osservando un miglioramento di 5 volte nel tempo dalla coda all'inizio attraverso i pool ospitati. È ora possibile avviare le compilazioni più rapidamente, il che significa che è possibile iterare più velocemente.

Creare una connessione del servizio di Azure con un principale del servizio che esegue l'autenticazione con un certificato

È ora possibile definire una connessione al servizio di Azure in Azure Pipelines o Team Foundation Server (TFS) con un'entità servizio e un certificato per l'autenticazione. Con la connessione al servizio di Azure, che ora supporta il principal di servizio che si autentica con un certificato, è possibile eseguire la distribuzione in Azure Stack configurato con AD FS. Per creare un'entità servizio con l'autenticazione del certificato, vedere l'articolo su come creare un'entità servizio che esegue l'autenticazione con un certificato.

Connettersi con l'entità servizio

Visualizzare le analisi di test in Pipelines

Monitorare la qualità dei test nel tempo e migliorare le risorse per i test è fondamentale per mantenere una pipeline efficace. La funzionalità di analisi dei test offre visibilità quasi in tempo reale sui dati di test per le compilazioni e le pipeline di versione. Consente di migliorare l'efficienza della pipeline identificando problemi di qualità ripetitivi e ad alto impatto.

È possibile raggruppare i risultati dei test in base a vari elementi, identificare i test chiave per il ramo o i file di test oppure eseguire il drill-down in un test specifico per visualizzare le tendenze e comprendere i problemi di qualità, ad esempio flakiness.

Visualizzare l'analisi dei test per le compilazioni e il rilascio, anteprima di seguito:

Analisi dei test

Per altre informazioni, vedere la documentazione.

Azure Repos

Cambiare il ramo di destinazione di una richiesta pull

Per la maggior parte dei team, quasi tutte le richieste pull hanno come destinazione lo stesso ramo, ad esempio master o develop. Tuttavia, nel caso in cui sia necessario impostare come destinazione un ramo diverso, potrebbe essere facile dimenticare di modificare il ramo di destinazione dal ramo predefinito. Con la nuova funzionalità per modificare il ramo di destinazione di una richiesta pull attiva, questa è ora una semplice azione. È sufficiente fare clic sull'icona a forma di matita accanto al nome del ramo di destinazione nell'intestazione della richiesta pull.

Modificare il ramo di destinazione

Oltre a correggere solo gli errori, la funzionalità per modificare i rami di destinazione semplifica anche la ridefinizione di una richiesta pull quando il ramo di destinazione è stato unito o eliminato. Si consideri uno scenario in cui si dispone di una richiesta pull destinata a un ramo di funzionalità che contiene alcune funzionalità da cui dipendono le modifiche. Si vogliono esaminare le modifiche dipendenti in isolamento da altre modifiche nel ramo delle funzionalità, quindi inizialmente si ha come destinazione features/new-feature. I revisori possono quindi visualizzare solo le modifiche e lasciare i commenti appropriati.

A questo punto, considerate cosa accadrebbe se il ramo delle funzionalità avesse anche una richiesta di pull attiva ed fosse stato unito in master prima delle vostre modifiche? In passato, avresti dovuto rinunciare alle tue modifiche e creare una nuova richiesta di pull in master, oppure unire la tua richiesta di pull in features/new-feature, e poi creare un'altra richiesta di pull da features/new-feature a master. Con questa nuova azione per aggiornare il ramo di destinazione, puoi semplicemente cambiare il ramo di destinazione del pull request da features/new-feature a master, mantenendo tutto il contesto e i commenti. La modifica del ramo di destinazione crea anche una nuova revisione della pull request, che consente di rivedere facilmente le differenze precedenti prima della modifica del ramo di destinazione.

Aggiornamento del ramo di destinazione

Proteggere i repository Git con impostazioni per la compatibilità multipiattaforma

Poiché Git è una tecnologia multipiattaforma, è possibile che i file o le directory trovino il loro modo in un file system in cui potrebbero non essere compatibili in una piattaforma specifica. Per informazioni dettagliate su queste incompatibilità, vedere la documentazione.

Per aiutare i team a proteggere il repository e i relativi sviluppatori, sono state aggiunte nuove impostazioni del repository per bloccare i push contenenti commit con file/directory incompatibili con una o più piattaforme del sistema operativo. Altre informazioni su queste impostazioni.

Administration

Supportare gli utenti di AAD negli account MSA

Azure DevOps supporta ora gli utenti di AzureAD (AAD) che accedono alle organizzazioni supportate da un Microsoft Account (MSA). Per gli amministratori, ciò significa che se l'organizzazione di Azure DevOps usa MSA per gli utenti corporativi, è ora possibile far accedere i nuovi dipendenti usando le credenziali di Azure Active Directory anziché creare una nuova identità MSA esclusivamente per l'uso con Azure DevOps.

Crediamo ancora che l'esperienza migliore sia per gli utenti aziendali per connettere Azure DevOps ad AAD, ma abbiamo appreso all'inizio di quest'anno che gli amministratori hanno bisogno di più tempo per effettuare tale conversione. Consentendo agli utenti di AAD di accedere alle organizzazioni supportate da MSA, i nuovi utenti potranno accedere ad Azure DevOps dopo che Azure DevOps ha impedito la creazione di nuovi utenti msa con nomi di dominio personalizzati supportati da AzureAD alla fine del mese.

Per le organizzazioni che usano già identità AAD con Azure DevOps, questa funzionalità non si applica. Per le organizzazioni che attualmente usano le identità MSA, tenere presente che tutti gli utenti esistenti possono continuare ad accedere con le identità MSA come fanno oggi. Questo vale solo per gli utenti aggiunti in futuro (che potenzialmente non possono creare un account del servizio gestito con il proprio indirizzo di posta elettronica aziendale).

Ecco uno scenario di esempio in cui questa esperienza può essere utile: Dorothy è il proprietario dell'organizzazione di Azure DevOps per la sua azienda, Fabrikam. Lei e il suo team di 10 membri del team accedono tutti ad Azure DevOps con identità MSA che usano il proprio indirizzo di posta elettronica aziendale, ad esempio Dorothy@fabrikam.com. Sam è un nuovo membro del team che si è unito all'azienda oggi. Dorothy lo invita ad Azure DevOps usando il suo messaggio di posta elettronica, sam@fabrikam.com. Quando fa clic sul collegamento join ora nel messaggio di posta elettronica, può accedere ad Azure DevOps con la stessa identità AAD a cui è stato assegnato per accedere alla posta elettronica con Microsoft 365. In questo modo Sam può collaborare con i suoi 11 colleghi e dare a Dorothy la libertà di connettere l'organizzazione Di Azure DevOps ad AAD quando è pronta.

Per altre informazioni, vedere il post di blog .

Come fornire commenti e suggerimenti

Ci piacerebbe sentire ciò che pensi a queste funzionalità. Usare il menu commenti e suggerimenti per segnalare un problema o fornire un suggerimento.

Inviare un suggerimento

È anche possibile ottenere consigli e risposte alle domande della community su Stack Overflow.

Grazie,

Gopinath Chigakkagari (Twitter)