Esercizio della collaborazione di Azure Repos con le richieste pull
I problemi di codice che vengono rilevati prima sono sia più facili che più economici da risolvere. I team di sviluppo si sforzano quindi di anticipare i controlli di qualità del codice il prima possibile nel processo di sviluppo.
Come suggerisce il nome, le politiche di ramo offrono un set di criteri predefiniti che possono essere applicati ai rami sul server.
Eventuali modifiche di cui viene eseguito il push nei rami del server devono seguire questi criteri prima che le modifiche possano essere accettate.
I criteri sono un ottimo modo per applicare gli standard di qualità del codice e gestione delle modifiche del team. In questa ricetta si apprenderà come configurare le politiche di ramo nel ramo principale.
Preparandosi
Le politiche preconfigurate dei rami includono diverse regole, come la convalida della compilazione e l'adozione di una strategia di unione. Ci concentreremo solo sui criteri dei rami necessari per configurare un flusso di lavoro di revisione del codice in questa ricetta.
Come eseguire questa operazione
Aprire la visualizzazione dei rami per il repository Git di myWebApp nel portale del team Parts Unlimited. Selezionare il ramo principale e scegliere Criteri del ramo dal menu di scelta rapida.
Nella visualizzazione dei criteri, presenta i criteri predefiniti. Impostare il numero minimo di revisori su 1:
L'opzione Consenti ai richiedenti di approvare le proprie modifiche consente al mittente di approvare automaticamente le modifiche.
Anche se questo potrebbe essere accettabile per i team maturi, in generale, deve essere evitato.
Usare i criteri di revisione con i criteri di risoluzione dei commenti. Consente di imporre che i commenti di revisione del codice vengano risolti prima che le modifiche vengano accettate. Il richiedente può accettare il feedback dal commento e creare un nuovo elemento di lavoro e risolvere le modifiche. Garantisce almeno che i commenti di revisione del codice non andranno persi con l'accettazione del codice nel ramo principale:
Un requisito instiga una modifica del codice nel progetto del team. Se l'elemento di lavoro che ha attivato il lavoro non è collegato alla modifica, diventa difficile capire nel tempo il motivo per cui è stata effettuata. È particolarmente utile quando si esamina la cronologia delle modifiche. Configurare il criterio Verifica elementi di lavoro collegati per bloccare le modifiche prive di un elemento di lavoro collegato.
Selezionare l'opzione per includere automaticamente i revisori quando viene generata automaticamente una richiesta pull. È possibile eseguire il mapping dei revisori aggiunti in base all'area del codice da modificare:
Come funziona
Grazie ai criteri del ramo applicati, la filiale principale è ora completamente protetta.
L'unico modo per eseguire il push delle modifiche nel ramo principale consiste innanzitutto nell'apportare le modifiche in un altro ramo e quindi generare una richiesta pull per attivare il flusso di lavoro di accettazione delle modifiche.
Scegli di creare un nuovo ramo da una delle user story esistenti nella sezione 'elemento di lavoro'.
Creando un nuovo ramo da un elemento di lavoro, tale elemento di lavoro viene automaticamente collegato al ramo.
Facoltativamente, è possibile includere più elementi di lavoro con un ramo come parte del flusso di lavoro di creazione:
Aggiungi un prefisso al nome quando crei il ramo per creare una cartella in cui inserirlo.
Nell'esempio precedente, il ramo verrà incluso nella cartella . È un ottimo modo per organizzare i rami in ambienti occupati.
Con il ramo appena creato selezionato nel portale Web, modificare il file HomeController.cs per includere il frammento di codice seguente ed eseguire il commit delle modifiche nel ramo.
Nell'immagine seguente si noterà che è possibile eseguire direttamente il commit delle modifiche dopo aver modificato il file facendo clic sul pulsante commit.
Il controllo percorso del file nel portale del team supporta la ricerca.
Inizia a digitare il percorso del file per visualizzare tutti i file nel tuo repository Git all'interno di quella directory, iniziando con queste lettere che compaiono nell'elenco a discesa dei risultati di ricerca del percorso del file.
L'editor di codice nel portale Web include diverse nuove funzionalità in Azure DevOps Server, ad esempio il supporto per la corrispondenza tra parentesi quadre e l'attivazione/disattivazione degli spazi vuoti.
È possibile caricare il riquadro comandi premendolo. Tra le altre nuove opzioni, è ora possibile attivare o disattivare il file usando una mini-mappa file, comprimere ed espandere e altre operazioni standard.
Per eseguire il push di queste modifiche dal nuovo ramo al ramo principale, creare una richiesta pull dalla sezione delle richieste pull.
Selezionare il nuovo ramo come origine e il ramo principale come ramo di destinazione.
Il nuovo modulo di richiesta pull supporta markdown, quindi è possibile aggiungere la descrizione usando la sintassi markdown.
La finestra di descrizione supporta anche @ menzioni e # per collegare gli elementi di lavoro:
Viene creata la richiesta pull; la pagina di panoramica riepiloga le modifiche e lo stato dei criteri.
La scheda File mostra un elenco di modifiche e la differenza tra le versioni precedenti e le versioni correnti.
Tutti gli aggiornamenti inseriti nei file di codice verranno visualizzati nella scheda Aggiornamenti e nella scheda Commit viene visualizzato un elenco di tutti i commit:
Aprire la scheda File: questa visualizzazione supporta i commenti di codice a livello di riga, a livello di file e in generale.
I commenti supportano sia @ per menzioni che # per collegare elementi di lavoro e il testo supporta la sintassi markdown:
I commenti di codice vengono salvati in modo permanente nel flusso di lavoro della pull request; i commenti di codice supportano iterazioni multiple di revisione e funzionano bene con le risposte nidificate.
I criteri di revisore consentono un flusso di lavoro di revisione del codice come parte dell'accettazione della modifica.
È un ottimo modo per consentire al team di collaborare a qualsiasi modifica del codice inserita nel ramo principale.
Una volta che il numero richiesto di revisori approva la pull request, questa può essere completata.
È anche possibile contrassegnare il pull request per il completamento automatico dopo la revisione. Completa automaticamente le richieste pull dopo che tutti i criteri sono stati compilati correttamente.
C'è di più
Sei mai stato in uno stato in cui un ramo è stato eliminato accidentalmente? Non può essere facile capire cosa è successo.
Azure DevOps Server supporta ora la ricerca di rami eliminati. Aiuta a capire chi l'ha eliminata e quando. L'interfaccia consente anche di ricreare il ramo.
I rami eliminati vengono visualizzati solo se li si cerca in base al nome esatto per tagliare il rumore dai risultati della ricerca.
Per cercare un ramo eliminato, immettere il nome completo del ramo nella casella di ricerca del ramo. Restituirà tutti i rami esistenti che corrispondono a tale testo.
Verrà visualizzata anche un'opzione per cercare una corrispondenza esatta nell'elenco dei rami eliminati.
Se viene trovata una corrispondenza, potrai vedere chi l'ha eliminata e quando. È anche possibile ripristinare il ramo. Il ripristino del ramo lo ricreerà al commit a cui era collegato per ultimo.
Tuttavia, non ripristinerà criteri e autorizzazioni.