Condividi tramite

Protezione dei segreti GitHub e Sicurezza del codice GitHub disponibili come prodotti autonomi in Azure DevOps

È ora possibile ottenere GitHub Secret Protection e GitHub Code Security come prodotti autonomi in Azure DevOps. La protezione dei segreti fornisce l'accesso alle esperienze di analisi dei segreti, protezione push e panoramica della sicurezza. Sicurezza del codice consente di accedere a tutte le esperienze di analisi delle dipendenze, analisi del codice e panoramica della sicurezza.

Nel contesto di Piani di test, stiamo introducendo una nuova struttura di directory per aiutarti a restare organizzato e risparmiare tempo. È ora possibile gestire i piani di test in modo più efficiente, avendo maggiore controllo sull'area di lavoro e riducendo le attività ripetitive.

Dai un'occhiata alle note di rilascio per i dettagli.

Sicurezza avanzata di GitHub per Azure DevOps

Generale

Azure Pipelines

Piani di test di Azure

Sicurezza avanzata di GitHub per Azure DevOps

GitHub Advanced Security è ora disponibile come Protezione dei segreti GitHub e Sicurezza del codice per Azure DevOps

GitHub Secret Protection e GitHub Code Security possono ora essere acquistati come prodotti autonomi in Azure DevOps per i nuovi clienti.

La protezione dei segreti fornisce l'accesso alle esperienze di analisi dei segreti, protezione push e panoramica della sicurezza. Sicurezza del codice consente di accedere a tutte le esperienze di analisi delle dipendenze, analisi del codice e panoramica della sicurezza.

Tutti i clienti di Advanced Security esistenti possono continuare a usare l'esperienza del prodotto in bundle senza interruzioni. Se si è un cliente corrente di Advanced Security e si è interessati a passare ai prodotti autonomi, contattare il supporto di Azure DevOps tramite il portale di Azure. È possibile inviare un ticket di supporto per il servizio GitHub Advanced Security for Azure DevOps e selezionare Billing migration from bundled to standalone products come tipo di problema.

Per altre informazioni su questi prodotti, vedere il blog di sviluppo.

Generale

Limitare i criteri dell'organizzazione di creazione del token di accesso personale (PAT) ora in anteprima pubblica

È stato introdotto un nuovo criterio a livello di organizzazione in Azure DevOps: limita la creazione del token di accesso personale (PAT), ora disponibile in anteprima pubblica. Questa funzionalità richiesta da tempo consente agli amministratori della Collection di progetto di controllare chi può creare o rigenerare i token di accesso personali (PAT), contribuendo a ridurre la proliferazione dei token e migliorare la sicurezza. Se abilitata, solo gli utenti di una lista consentita possono generare token di accesso personale, con supporto facoltativo per gli ambiti di ambito dei pacchetti. Il criterio blocca anche l'utilizzo globale del pat a meno che non sia consentito in modo esplicito. Altre informazioni su questo criterio e sulle procedure consigliate per implementare questa modifica nel post di blog.

Limita la creazione del token di accesso personale (Screenshot di

Rimozione delle app OAuth di Azure DevOps scadute

Quando ci prepariamo per la fine della vita per le app OAuth di Azure DevOps nel 2026, inizieremo a rimuovere regolarmente app con segreti scaduti più di sei mesi fa (180 giorni fa). I proprietari di queste app inattive verranno informati e, se è necessaria una registrazione dell'app da adesso fino alla fine della vita di Azure DevOps OAuth nel 2026, viene chiesto di aggiornare il segreto dell'app prima del 9 giugno, quando iniziamo a eliminare le app. Per altre informazioni, vedere il post di blog.

Nuovi ambiti di Microsoft Entra OAuth

Azure DevOps ha introdotto due nuovi ambiti di Microsoft Entra OAuth, vso.pats e vso.pats_manage per migliorare la sicurezza e il controllo sulle API di gestione del ciclo di vita del token di accesso personale (PAT). Questi ambiti sono ora necessari per i flussi delegati che coinvolgono la creazione e la gestione del PAT, sostituendo l'amplio ambito di user_impersonation precedente. Questa modifica consente ai proprietari di app di ridurre le autorizzazioni necessarie all'app per accedere alle API PAT. Riduci gli ambiti delle tue app ai minimi indispensabili per oggi!

Richiedere la disponibilità dell'URL di accesso

Gli amministratori di Azure DevOps possono disabilitare i criteri di accesso alle richieste e fornire un URL per gli utenti per richiedere l'accesso a un'organizzazione o a un progetto. Questo URL, disponibile in precedenza solo per i nuovi utenti, viene ora visualizzato anche agli utenti esistenti nella pagina 404. Per mantenere la riservatezza, l'URL di accesso alla richiesta viene visualizzato indipendentemente dall'esistenza del progetto.

Azure Pipelines

Pool DevOps gestiti - Deprecazione delle immagini

A causa della deprecazione dell'immagine ospitata di Windows Server 2019 e della deprecazione di Ubuntu 20.04, i pool DevOps gestiti deprecano l'immagine "Azure Pipelines – Windows Server 2019" e le immagini Ubuntu 20.04. Altre informazioni sulle deprecazioni sono disponibili qui. Per informazioni sul ciclo di vita delle immagini offerte dai pool DevOps gestiti, vedere qui.

Pagina dei nuovi trigger

Le pipeline di YAML offrono diverse opzioni potenti per definire quando la tua pipeline dovrebbe essere eseguita. Non è sempre facile ragionare se la pipeline è configurata per l'esecuzione in risposta a un evento, ad esempio una pipeline di feeder completata.

Questo sprint ha introdotto una pagina Trigger che offre una panoramica dei trigger definiti nella pipeline.

Screenshot dei trigger di pipeline.

Si supponga di avere la pipeline YAML seguente definita nel main ramo di un repository. Si consideri anche un feature ramo con lo stesso codice della pipeline YAML.

trigger:
- main

schedules:
  - cron: 0 0 * * *
    always: true
    displayName: Nightly build
    branches:
      include:
        - main

resources:
  pipelines:
    - pipeline: FabrikamFiber
      source: FabrikamFiber
      trigger: true

Quando si passa alla pagina Trigger , viene visualizzato quanto segue

Screenshot dei trigger di integrazione continua.

Si noti che il ramo predefinito della pipeline, main, è pre-selezionato.

Viene visualizzato un trigger di integrazione continua per questo ramo ed è definito nel file YAML.

Quando si passa ai trigger di pianificazione, vengono visualizzati i trigger definiti ed è possibile visualizzarne i dettagli.

Screenshot dei trigger di programmazione delle pipeline.

Quando si passa alla sezione Trigger di risorsa , vengono visualizzati i trigger di risorsa definiti e i relativi dettagli.

Screenshot della sezione relativa ai trigger delle risorse di Pipelines.

È possibile cambiare rami, da main a feature, per vedere quali trigger sono stati definiti per il feature ramo.

Screenshot dei trigger dell'integrazione continua di Pipelines.

Screenshot dei trigger pianificati delle pipeline.

Screenshot degli attivatori delle risorse in continuo di Pipelines.

Nella scheda Trigger di risorsa , quando non nel ramo predefinito, viene visualizzato un avviso che indica che i trigger definiti per questo ramo vengono ignorati.

Quando le definizioni dei trigger non sono state elaborate correttamente dal sistema, viene visualizzato un avviso e indicazioni su come risolvere il problema.

Screenshot dei trigger di pianificazione delle pipeline con avvisi e indicazioni su come risolvere i trigger non vengono elaborati.

Tipo di parametro StringList

Una delle principali funzionalità delle pipeline YAML richieste nella community degli sviluppatori consiste nel definire i parametri che contengono un elenco di elementi.

A partire da questo sprint, è stato aggiunto un nuovo tipo di parametro, denominato StringList, che fornisce questa funzionalità.

Supponiamo di voler consentire a coloro che accodano le esecuzioni della pipeline di scegliere le regioni in cui vogliono distribuire un payload. A questo scopo, è possibile eseguire questa operazione come illustrato nell'esempio seguente.

parameters:
- name: regions
  type: stringList
  displayName: Regions
  values:
    - WUS
    - CUS
    - EUS
  default: 
    - WUS
    - CUS
    - EUS 

stages:
- ${{ each stage in parameters.regions}}:
  - stage: ${{stage}}
    displayName: Deploy to ${{stage}}
    jobs:
    - job:
      steps:
      - script: ./deploy ${{stage}}

Quando si accoda questa pipeline, è possibile scegliere più aree in cui eseguire la distribuzione, come illustrato nello screenshot seguente.

Screenshot della selezione multipla dell'area di esecuzione della pipeline.

Annotazioni

Il stringList tipo di dati non è disponibile nei modelli. Usare invece il object tipo di dati nei modelli.

Vedi il codice YAML completo di un'esecuzione della pipeline

Le pipeline YAML sono componibili. È possibile estendere un modello per assicurarsi che le pipeline eseguano gli strumenti di analisi statici necessari e includano modelli per eseguire fasi o processi o attività comuni.

Il debug di tali pipeline non è stato semplice, perché non è stato possibile visualizzare il codice YAML completo in esecuzione.

Si supponga di avere la pipeline seguente:

parameters:
- name: PoolName
  type: string
  default: Azure Pipelines
- name: VmImage
  type: string
  default: ubuntu latest

extends:
  template: security-enforcing-template.yml
  parameters:
    jobs:
    - template: job.monitoring.yml
    - template: job.build.yml
      parameters:
        PoolName: ${{parameters.PoolName}}
        VmImage: ${{parameters.VmImage}}

Sono disponibili tre modelli usati qui. Ogni modello può usare espressioni condizionali basate su valori di parametri e variabili per determinare i processi effettivi o i passaggi da eseguire.

Inoltre, quando si esaminano le esecuzioni di pipeline precedenti, non si sa se il codice della pipeline è lo stesso ora di quando è stata eseguita l'esecuzione.

In questo sprint si aggiunge una nuova funzionalità che consente di visualizzare facilmente il codice YAML completo di un'esecuzione della pipeline.

Screenshot del riepilogo della pipeline con l'opzione 'vedi YAML completo'.

Piani di test di Azure

Introduzione alla nuova directory dei piani di test

Resta organizzato e risparmia tempo con la nuova Directory dei Piani di Test. Sono stati introdotti diversi miglioramenti che consentono di gestire i piani di test in modo più efficiente, offrendo maggiore controllo sull'area di lavoro e riducendo le attività ripetitive.

Gif nella directory Test Plans.

Ecco le novità:

  • Progettazione dell'interfaccia utente più pulita: esplorare i piani di test con facilità usando un'interfaccia moderna che migliora la leggibilità e riduce il disordine, consentendo di concentrarsi sulle attività senza distrazioni.

  • Ordinamento delle colonne: trovare le informazioni necessarie più velocemente ordinando le colonne in base a nome, stato o altri attributi chiave. Questa funzionalità consente di organizzare e classificare rapidamente in ordine di priorità i piani di test per una migliore produttività.

  • Filtro team nella scheda Tutti: Concentrarsi sulle questioni importanti filtrando i piani di test in base al team, assicurandosi di visualizzare solo i piani pertinenti allineati al lavoro e agli obiettivi.

  • Filtri permanenti: consente di risparmiare tempo con filtri permanenti che ricordano le impostazioni. Quando si torna alla pagina, i filtri applicati in precedenza rimarranno intatti, fornendo una visualizzazione organizzata senza dover riapplicare i filtri ogni volta.

Questi aggiornamenti sono progettati per semplificare il flusso di lavoro, ridurre le attività ripetitive e semplificare il monitoraggio e la gestione dei piani di test. Provaci e inviaci un messaggio di posta elettronica cosa pensi!

Cronologia dei risultati del test case avanzato

Tenere facilmente traccia dei dettagli dell'esecuzione dei test chiave con nuovi miglioramenti alla pagina dei risultati del test case. Nella pagina vengono visualizzate informazioni critiche, ad esempio ID esecuzione, ID pipeline, proprietario, percorso iterazione e percorso area, fornendo una visualizzazione completa di ogni esecuzione del test a colpo d'occhio.

È stato aggiunto lo scorrimento orizzontale per valori più lunghi e colonne personalizzabili, consentendo di personalizzare il layout e mantenere le preferenze salvate a livello di utente. Per velocizzare lo spostamento, gli ID di esecuzione e le righe sono selezionabili, consentendo di accedere rapidamente alla visualizzazione Esecuzione test per ottenere informazioni più approfondite. Questi aggiornamenti mirano a migliorare la visibilità, risparmiare tempo e semplificare il flusso di lavoro, semplificando il monitoraggio e la gestione delle esecuzioni dei test in modo efficiente. Prova e facci sapere tramite email se hai dei commenti o suggerimenti. Ci piacerebbe sentire da te!

Visualizzare lo stato del test case nella scheda Esegui

È ora possibile aggiungere la colonna "Stato test case" alla scheda Esegui per visualizzare rapidamente lo stato di ogni test case. Indipendentemente dal fatto che sia approvato, in corso o qualsiasi altro stato, questo aggiornamento offre visibilità più chiara sulla conformità dei test senza cambiare le schede del browser o eseguire query complesse.

La colonna è facoltativa e può essere abilitata tramite la selezione colonne. Si allinea anche con il filtro Stato esistente, consentendo di filtrare e visualizzare gli stati del test case affiancati, tutti in un'unica posizione.

Questo miglioramento consente ai tester di iniziare l'esecuzione con test case realmente pronti o approvati, riducendo il rischio di esecuzione di elementi incompleti o bozza e rendendo più efficienti le esecuzioni dei test fin dall'inizio.

Ripresa predefinita per il test case sospeso

Riprendi rapidamente i casi di test sospesi con un clic. Abbiamo reso "Riprendi" l'azione predefinita per i casi di test sospesi, consentendoti di continuare esattamente da dove hai interrotto senza navigazione aggiuntiva. Questo aggiornamento rende più veloce e più semplice continuare il lavoro senza interruzioni.

Per proteggere ulteriormente lo stato di avanzamento, viene visualizzata una richiesta di conferma per evitare sovrascrizioni accidentali dello stato di avanzamento del test sospeso. Questa protezione garantisce che il lavoro parzialmente salvato rimanga intatto, assicurandoti la tranquillità durante la gestione delle esecuzioni dei test. Provaci e inviaci un messaggio di posta elettronica cosa pensi!

Passaggi successivi

Annotazioni

Queste funzionalità verranno implementate nelle prossime due o tre settimane. Passare ad Azure DevOps e dare un'occhiata.

Passare ad Azure DevOps

Come fornire commenti e suggerimenti

Ci piacerebbe sentire ciò che pensi a queste funzionalità. Usa il menu di aiuto per segnalare un problema o fornire un suggerimento.

Inviare un suggerimento

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

  • Last updated on