Verbindung mit einem Azure DevOps Repo

Orbit deploys from Azure Repos, the git hosting inside Azure DevOps. Connect once, pick a repository, and every push builds and goes live. This guide covers both ways to connect, selecting a…

Orbit stellt aus Azure Repos bereit, dem Git-Hosting innerhalb von Azure DevOps. Verbinden Sie sich einmal, wählen Sie ein Repository aus, und bei jedem Push wird es erstellt und live geschaltet. Dieses Handbuch behandelt beide Verbindungsmethoden, die Repositoryauswahl und die zwei Besonderheiten von Azure im Vergleich zu den anderen Anbietern.

Zwei Verbindungsmethoden und warum es zwei gibt

Azure DevOps-Organisationen können Anwendungen von Drittanbietern auf Mandantenebene blockieren, und viele Unternehmen tun dies. Falls Ihre Organisation dies tut, kann die Anmeldeschaltfläche für Sie nicht funktionieren, egal was wir tun. Daher bietet Orbit eine zweite Methode, die immer funktioniert.

Mit Microsoft anmelden. Ein Klick, nichts zum Kopieren und Einfügen. Verfügbar, wenn Ihre Organisation Anwendungen von Drittanbietern zulässt.
Persönliches Zugriffsttoken. Funktioniert für jede Organisation, auch für solche, die Anwendungen blockieren. Sie fügen einen Organisationsnamen und ein Token ein, das Sie in Azure DevOps erstellen.

Beide Methoden bieten Zugriff auf exakt dieselben Funktionen. Keine ist eine eingeschränkte Version der anderen.

Bevor Sie beginnen

Orbit sieht nur das, was Ihr Azure DevOps-Konto sieht. Sie benötigen ausreichende Berechtigungen im Repository, um ein Service Hook-Abonnement zu erstellen, denn dieses Abonnement ist der Weg, auf dem ein Push uns erreicht. Ohne diese Berechtigungen wird die Verbindung erfolgreich hergestellt, aber es wird nie etwas bereitgestellt.

Option A: Mit Microsoft anmelden

Klicken Sie in KPanel in der linken Seitenleiste auf Orbit.
Klicken Sie auf Neues Projekt.
Belassen Sie den Modus auf Git-Repo importieren.
Wählen Sie die Registerkarte Azure DevOps und klicken Sie auf Azure DevOps verbinden.

Sie werden zu Microsoft weitergeleitet, um sich anzumelden und den Zugriff zu genehmigen. Genehmigen Sie dies, und Sie werden zu KPanel zurückgeleitet, wobei Ihre Repositories geladen sind.

Falls Ihre Organisation die Anwendung blockiert, lehnt Microsoft dies ab und KPanel zeigt den Grund an. Das ist nichts, das Sie durch Wiederholung beheben können: Verwenden Sie das persönliche Zugriffsttoken unten oder bitten Sie einen Administrator, die Anwendung zuzulassen.

Option B: Persönliches Zugriffsttoken

Erstellen Sie das Token zuerst in Azure DevOps.

Öffnen Sie in Azure DevOps Benutzereinstellungen, dann Persönliche Zugriffstokens, dann Neues Token.
Wählen Sie die Organisation aus, von der Sie bereitstellen möchten.
Erteilen Sie diese drei Bereiche und nicht mehr als diese drei:
- Code (Lesen) damit Orbit Ihre Repositories auflisten und den Commit herunterladen kann, den es erstellt.
- Code (Status) damit das Erstellungsergebnis auf dem Commit und auf dem Pull Request angezeigt wird.
- Service Hooks (Lesen und Schreiben) damit Orbit Ihre Pushes abonnieren kann.
Kopieren Sie das Token. Azure zeigt es nur einmal.

Dann in KPanel:

Öffnen Sie Orbit, dann Neues Projekt, dann die Registerkarte Azure DevOps.
Geben Sie unter Mit persönlichem Zugriffsttoken verbinden Ihren Organisationsnamen ein. Das ist der Teil Ihrer Repository-Adresse unmittelbar nach dev.azure.com, also für https://dev.azure.com/contoso/web-platform/_git/storefront ist die Organisation contoso.
Fügen Sie das Token ein und klicken Sie auf Azure DevOps verbinden.

Orbit verwendet das Token sofort, um Ihre Repositories aufzulisten. Falls es abgelehnt wird, werden Sie über die fehlenden Bereiche informiert, anstatt gefragt zu werden, Ihr Token zu überprüfen, denn ein Token, das Repositories auflisten kann, aber keinen Service Hook erstellen kann, führt zu einer sauberen Verbindung, die dann nie etwas bereitstellt.

Ihr Token wird verschlüsselt, bevor es gespeichert wird, und wird nur gegen die Organisation verwendet, die Sie benannt haben.

Ein Repository auswählen

Ihre Repositories werden als Liste angezeigt, benannt organisation / project / repository. Azure-Repositories bestehen aus drei Teilen, nicht zwei, denn zwei Projekte in einer Organisation können jeweils ein Repository mit demselben Namen enthalten.

Klicken Sie neben dem gewünschten auf Auswählen und beenden Sie dann das Projekt wie gewöhnlich: Name, Framework, Build-Einstellungen, Umgebungsvariablen.

Falls ein Repository fehlt

Überprüfen Sie die Organisation. Ein persönliches Zugriffsttoken gehört zu EINER Organisation, daher wird ein Repository in einer anderen Organisation nicht angezeigt. Verbinden Sie diese Organisation ebenfalls.
Überprüfen Sie Ihren Zugriff auf das Repository selbst in Azure DevOps.
Überprüfen Sie, ob das Repository in Azure deaktiviert ist. Orbit listet deaktivierte Repositories nicht auf, da sie nicht erstellt werden können.

Zwei Besonderheiten von Azure

Dies sind echte Unterschiede, keine Lücken, die wir noch nicht beheben mussten, und beide werden hier dargelegt, anstatt später entdeckt zu werden.

Root-Verzeichnis des Monorepos überspringt Pushes nicht

Bei den anderen Anbietern liest Orbit die Liste der Dateien, die bei jedem Push geändert wurden, und ein Monorepo-Projekt kann einen Build überspringen, wenn sich nichts unter seinem Root-Verzeichnis geändert hat. Azure sendet diese Liste nicht. Orbit erstellt daher bei jedem Push, anstatt zu raten, denn eine falsche Vermutung würde Bereitstellungen, die Sie erwarteten, stillschweigend überspringen.

Ihre Root-Verzeichnis-Einstellung bestimmt immer noch, wo der Build ausgeführt wird. Sie filtert nur zusätzlich nicht, welche Pushes einen Build verursachen.

Pull Requests von Forks werden nicht erstellt

Orbit erstellt eine Pull Request-Vorschau mit den Preview-Umgebungsvariablen Ihres Projekts. Das ist sicher für einen Pull Request aus Ihrem eigenen Repository und nicht sicher für einen aus einem Fork, der ein Vorschlag von jemandem ist, der keine Beziehung zu Ihrem Konto hat.

Bei GitHub kann Orbit eine Fork-Vorschau anbieten, denn GitHub veröffentlicht den vorgeschlagenen Commit in Ihrem eigenen Repository, sodass wir uns nie gegen die Kopie des Mitwirkenden authentifizieren müssen. Azure veröffentlicht nichts Gleichwertiges, daher lehnt Orbit Fork-Pull-Requests ab und teilt dies auf dem Commit mit, anstatt eine Vorschau zu hinterlassen, die nie erscheint.

Pull Requests aus Branches in Ihrem eigenen Repository werden normal erstellt.

Was kommt als Nächstes

Pushen Sie zu Ihrem Produktionszweig und Orbit erstellt und stellt bereit. Das Erstellungsergebnis wird auf dem Commit in Azure DevOps zurückgepostet, daher wird es auf dem Commit und auf allen Pull Requests angezeigt, zu denen der Commit gehört, und Ihre Branch-Richtlinien können es erfordern.