Connessione di un repository Azure DevOps

Orbit esegue i deploy dai repository Azure Repos, l'hosting git all'interno di Azure DevOps. Connettiti una volta, scegli un repository e ogni push crea e pubblica il progetto in diretta. Questa guida copre entrambi i modi di connettersi, la selezione di un repository e le due cose che Azure fa diversamente dagli altri provider.

Due Modi Per Connettersi E Perché Ce Ne Sono Due

Le organizzazioni Azure DevOps possono bloccare le applicazioni di terze parti a livello di tenant e molte aziende lo fanno. Se la tua lo fa, il pulsante di accesso non può funzionare per te indipendentemente da quello che facciamo, quindi Orbit offre una seconda porta che funziona sempre.

• Accedi con Microsoft. Un clic, niente da copiare e incollare. Disponibile quando la tua organizzazione consente le applicazioni di terze parti.
• Token di accesso personale. Funziona per ogni organizzazione, incluse quelle che bloccano le applicazioni. Incolla un nome di organizzazione e un token che crei in Azure DevOps.

Entrambe le porte raggiungono esattamente le stesse funzioni. Nessuna è una versione ridotta dell'altra.

Prima Di Iniziare

Opzione A: Accedi Con Microsoft

1. In KPanel, fai clic su Orbit nella barra laterale sinistra.
2. Fai clic su Nuovo progetto.
3. Lascia la modalità impostata su Importa repository Git.
4. Scegli la scheda Azure DevOps, quindi fai clic su Connetti Azure DevOps.

Vieni inviato a Microsoft per accedere e approvare l'accesso. Approvalo e verrai restituito a KPanel con i tuoi repository caricati.

Se la tua organizzazione blocca l'applicazione, Microsoft la rifiuta e KPanel mostra il motivo che ha dato. Non è qualcosa da cui puoi uscire ritentando: usa il token di accesso personale qui sotto, oppure chiedi a un amministratore di consentire l'applicazione.

Opzione B: Token Di Accesso Personale

Crea il token in Azure DevOps per primo.

1. In Azure DevOps, apri Impostazioni utente, quindi Token di accesso personale, quindi Nuovo token.
2. Scegli l'organizzazione da cui vuoi eseguire il deploy.
3. Concedi questi tre ambiti e solo questi tre:
   • Code (Read) così Orbit può elencare i tuoi repository e scaricare il commit che sta costruendo.
   • Code (Status) così il risultato della build appare sul commit e sulla pull request.
   • Service Hooks (Read and write) così Orbit può sottoscrivere i tuoi push.
4. Copia il token. Azure lo mostra una sola volta.

Poi in KPanel:

1. Apri Orbit, quindi Nuovo progetto, quindi la scheda Azure DevOps.
2. Sotto Connetti con un token di accesso personale, immetti il nome della tua organizzazione. Questa è la parte dell'indirizzo del tuo repository immediatamente dopo dev.azure.com, quindi per https://dev.azure.com/contoso/web-platform/_git/storefront l'organizzazione è contoso.
3. Incolla il token e fai clic su Connetti Azure DevOps.

Orbit utilizza il token immediatamente per elencare i tuoi repository. Se viene rifiutato, ti viene detto quali ambiti mancano piuttosto che ti venga chiesto di controllare il tuo token, perché un token che elenca i repository ma non può creare un hook di servizio è nella forma che si connette correttamente e poi non distribuisce mai nulla.

Il tuo token viene crittografato prima di essere archiviato e viene utilizzato solo nell'organizzazione che hai denominato.

Selezione Di Un Repository

I tuoi repository appaiono come un elenco, denominato organisation / project / repository. I repository Azure hanno tre parti, non due, perché due progetti in un'organizzazione possono ciascuno contenere un repository con lo stesso nome.

Fai clic su Seleziona accanto a quello che desideri, quindi termina il progetto come al solito: nome, framework, impostazioni di build, variabili di ambiente.

Se Un Repository È Mancante

• Controlla l'organizzazione. Un token di accesso personale appartiene a UN'organizzazione, quindi un repository in un'altra non apparirà. Connetti anche quell'organizzazione.
• Controlla il tuo accesso al repository stesso in Azure DevOps.
• Controlla se il repository è disabilitato in Azure. Orbit non elenca i repository disabilitati, perché non possono essere costruiti.

Due Cose Che Azure Fa Diversamente

Queste sono differenze reali, non lacune a cui non siamo arrivati, e entrambe sono indicate qui piuttosto che scoperte in seguito.

La Directory Radice Del Monorepo Non Salta I Push

Negli altri provider Orbit legge l'elenco dei file che ogni push ha modificato e un progetto monorepo può saltare una build quando niente sotto la sua Directory Radice si è mosso. Azure non invia quell'elenco. Orbit quindi esegue la build su ogni push piuttosto che indovinare, perché indovinare diversamente salterebbe silenziosamente i deploy che stavi aspettando.

L'impostazione della tua Directory Radice decide ancora dove viene eseguita la build. Semplicemente non filtra ulteriormente quali push vengono compilati.

Le Pull Request Da Fork Non Vengono Costruite

Orbit costruisce un'anteprima di pull request con le variabili di ambiente di anteprima del tuo progetto. È sicuro per una pull request dal tuo repository ed è non sicuro per una da un fork, che è una proposta da qualcuno senza relazione con il tuo account.

Su GitHub, Orbit può offrire un'anteprima di fork perché GitHub pubblica il commit proposto all'interno del tuo repository, quindi non dobbiamo mai autenticarci rispetto alla copia del collaboratore. Azure non pubblica un equivalente, quindi Orbit rifiuta le pull request da fork e lo dice sul commit piuttosto che lasciare un'anteprima che non appare mai.

Le pull request da branch all'interno del tuo repository vengono costruite normalmente.

Cosa Succede Dopo

Esegui il push al tuo ramo di produzione e Orbit costruisce e distribuisce. Il risultato della build viene ripubblicato sul commit in Azure DevOps, quindi appare sul commit e su qualsiasi pull request a cui appartiene il commit, e le tue politiche di branch possono richiederlo.

Vedi Anche

• Che cos'è Orbit?
• Distribuzione del Tuo Progetto
• Connessione di un repository GitHub