GitHub und Azure DevOps: das Beste aus beiden Welten

Seit Microsoft GitHub übernommen hat, haben wir uns gefragt, wie sich dies langfristig auf das Azure DevOps-Angebot auswirken wird. Wir haben gesehen, dass viele Mitarbeiter aus dem Azure DevOps-Team zu GitHub gewechselt sind, wenn wir uns ihre Updates auf LinkedIn oder anderen sozialen Netzwerken ansehen, so dass es nur logisch ist, sich über die Zukunft Gedanken zu machen. Wir wissen, dass mehrere sehr groß Teams innerhalb von Microsoft nutzen Azure DevOps, zusammen mit einigen wirklich großen Kunden. Das bedeutet, dass Azure DevOps noch lange Zeit bestehen bleiben wird und weiterhin regelmäßige Updates für seine Funktionen erhalten wird. Azure DevOps hat ein sehr starkes Angebot, von "alles in einer Suite", die mit Tools von Drittanbietern kombiniert werden kann, bis hin zu einem guten Hosting-Modell (Datensouveränität ist für uns Europäer eine große Sache) und einem ausgezeichneten Azure-Support mit sogar integrierter Abrechnung auf dem Marktplatz.

GitHub hingegen ist die größte Entwickler-Community der Welt, mit einigen 56 Millionen plus Entwickler darauf. Wenn Sie Entwickler für Ihr Unternehmen gewinnen möchten, ist es ein hervorragendes Verkaufsargument, wenn Sie dies mit den Tools tun, die sie bereits kennen und lieben. GitHub ist von Entwicklern für Entwickler gemacht. Dadurch erhalten sie auch viele Informationen aus Open-Source-Communities über ihre Aktivitäten, die verwendeten Sprachen und sogar eine Vielzahl von Informationen, die sie aus dem auf der Plattform gespeicherten Open-Source-Code ziehen können. Sie hosten jetzt sogar Sicherheitshinweise und aktivieren Sie das Scannen nach Schwachstellenmustern in Ihrer Codebasis mit CodeQL.

Das Beste aus beiden Welten erforschen

In diesem Beitrag möchte ich Ihnen die Stärken beider Angebote vorstellen und erklären, welche Teile ich von jedem von ihnen verwenden würde und warum. Meiner Meinung nach haben beide Produkte einige einzigartige Funktionen, die das jeweils andere (noch) nicht hat, so dass es nur logisch ist, das richtige Tool für die richtige Aufgabe zu verwenden. Glücklicherweise ist die Integration zwischen den beiden Produkten sehr gut, so dass eine Kombination eine gute Option ist.

Ich habe die Dinge in die folgenden Abschnitte eingeteilt:

• Kontrolle der Quelle
• Arbeit verfolgen
• Pipelines
• Artefakte
• Sicherheitsmerkmale

Kontrolle der Quelle

In der Basis ist die Quellcodekontrolle auf beiden Plattformen sehr ähnlich: Azure DevOps hat immer noch TFVC-Unterstützung, aber ich empfehle wirklich nicht, das zu verwenden: Git ist heutzutage der Standard und das aus guten Gründen (die ich in diesem Beitrag übergehen werde). Beide Plattformen verfügen über Branch-Tracking, Pull-Requests, ein System zum Schutz von Zweigen und eine gute CLI, mit der Sie arbeiten können, so dass die Entscheidung, was Sie hier verwenden, auf die zusätzlichen Funktionen zu den Grundlagen hinausläuft. Hier hat GitHub meiner Meinung nach die besseren Optionen, weil es diese Funktionen bietet:

• GPG-Commit-Signierung
• Zweigschutzregeln mit GPG-Commit-Signierung
• Standardmäßige Sicherheitsfunktionen wie das Scannen von Codes

GPG Commit-Signierung

Die Commit-Signierung ist eine zusätzliche Sicherheitsebene über die grundlegende Authentifizierung hinaus. Ohne Commit-Signierung ist es ziemlich einfach, einige Codeänderungen für Sie vorzunehmen, sie lokal in das Repository zu übertragen und sie dann upstream zu pushen. Ich habe dies schon oft automatisiert und weiß daher, wie einfach es ist, dies zu tun. Es ist ganz einfach, die Software auf Ihrem Rechner auszuführen, die Repos zu scannen und bösartiges Material zu Ihren Projekten hinzuzufügen, ohne dass Sie überhaupt merken, dass dies direkt vor Ihrer Nase geschieht. Was noch schlimmer ist: Ich könnte das sogar auf meinem eigenen Rechner ausführen und Codeänderungen mit Ihr E-Mail-Adresse und Benutzernamen zugewiesen. Die Konfiguration in Git ist nur eine Metadatei, die nirgendwo in der Kette überprüft wird: GitHub prüft nur, ob der Benutzer, der die Änderungen einreicht, Schreibrechte für das Repository hat und lässt die Änderungen dann zu. Dies ist natürlich der Standard für alle Versionskontrollsysteme, die Git verwenden.

Mit commit signieren, müssen Sie den Commit mit Ihrem privaten Schlüssel signieren, den nur Sie haben sollten. Standardmäßig kann dieser Schlüssel nur in Verbindung mit einer Passphrase verwendet werden (Sie können ihn auch ohne Passphrase erstellen, aber das würde seinen Zweck verfehlen). Das Hinzufügen der Passphrase bedeutet, dass Sie die Passphrase eingeben müssen, wenn Sie die Übertragung signieren. Es gibt keine Möglichkeit, die Passphrase automatisch für Sie auszufüllen (soweit ich weiß). Das bedeutet auch, dass Sie die Commits nicht automatisch signieren können, was bedeutet, dass jemand Ihre Signierung nicht in Ihrem Namen fälschen kann.

Die Serverseite (in diesem Fall GitHub) speichert den öffentlichen Teil Ihres GPG-Schlüssels, der zur Verifizierung der signierten Commits verwendet wird: Diese stammen von Benutzern mit GPG-Signaturen UND diese Signaturen wurden mit dem zugehörigen öffentlichen Schlüssel verifiziert. Auf diese Weise können Sie das Repository oder bestimmte Zweige des Repositorys sperren und nur verifizierte Commits zulassen. .

Arbeit verfolgen

Die Nachverfolgung von Arbeiten war in Azure DevOps schon immer großartig und ich denke, es ist immer noch das bessere Angebot. GitHub bietet mehrere Optionen, um einige der gleichen Einstellungen zu ermöglichen, mit einer großartigen Integration in die Versionskontrolle mit Fragen und Pull-Anfragen. Sie können sogar Unteraufgaben zu einer Ausgabe hinzufügen mit Aufgabenlisten, obwohl mir die Epic-Einrichtung mit Unteraufgaben besser gefällt. Azure Boards.

Verfügbar in beiden Angeboten

Schauen wir uns an, was in beiden Angeboten enthalten ist:

• Rich-Text-Einrichtung (mit Markdown), die in den meisten Feldern Emoji, Gifs und sogar Videos einschließt.
• Einfaches Erstellen neuer Objekte (auch mit CLI und APIs)
• @Erwähnen Sie andere Benutzer, Themen oder Pull-Requests im Text eines Workitems/Themas
• Besprechung der zu erledigenden Arbeit
• Benachrichtigungssystem für Artikel, die Sie erwähnen
• Beschriftung und Suche auf ihnen

Hinweis: Was GitHub nicht hat, ist die ganze formale Einrichtung mit Genehmigungen, das Hinzufügen von zusätzlichen Feldern, das Hinzufügen von Story Points (und deren Zusammenfassung). Einiges davon kann repliziert werden, wenn Sie möchten. Ich persönlich mag dieses ganze zusätzliche Zeug nicht. Es ist eine unnötige Prozesszeremonie in dem Bemühen, das Gefühl zu haben, die Kontrolle über den agilen Prozess zu haben, während es nur zusätzliche Hürden bringt, durch die man springen muss, ohne den richtigen Mehrwert zu schaffen. Das könnte ein anderer Blogbeitrag sein.

Projekte von GitHub im Vergleich zu Azure Boards

GitHub hat erstellt Projekttafeln in dem Bemühen, uns mehr Kontrolle über die Probleme zu geben als nur die Liste selbst. Es fügt im Grunde eine Kanban-Einrichtung hinzu, um die verschiedenen Stadien der Probleme zu verfolgen. Standardmäßig sind dies nur 'Zu tun', 'In Bearbeitung' und 'Erledigt'. Dies funktioniert hervorragend in einem OSS Projekt, bei dem Sie nicht in regelmäßigen Sprints arbeiten (wer weiß schon, wann Sie die Zeit und Energie haben, um an den Dingen zu arbeiten). Wenn Sie in einer Organisation arbeiten, die Sprints hat, brauchen Sie etwas, um diese zu definieren. Das ist auf GitHub derzeit nicht möglich: Was sie dafür geschaffen haben, ist Meilensteine.

Indem Sie ein Problem zu einem Meilenstein hinzufügen, können Sie seinen Zustand über einen längeren Zeitraum verfolgen und sehen, wie viel Arbeit noch vor dem Erreichen des Meilensteins liegt. Die allgemeine Idee stammt wiederum aus der OSS, wo dies hervorragend funktioniert: Sie erstellen Issues für Dinge, die Sie finden oder Funktionen, die Sie hinzufügen möchten, markieren sie als Teil eines Meilensteins und arbeiten gemeinsam auf dieses Ziel hin.

Sie können sie auch für Sprints verwenden, wobei ein Meilenstein als Sprint angesehen werden kann und (offene) Probleme zu einem Meilenstein hinzugefügt werden. Auf diese Weise können sie im Laufe der Zeit nachverfolgt und für die Planung verwendet werden. Das Einzige, was mir an dieser Vorgehensweise nicht gefällt, ist die Namensgebung: ein Meilenstein ist kein Sprint: was wir als Meilenstein ansehen, kann leicht mehrere Sprints in Anspruch nehmen.

Auf der anderen Seite: Mir gefällt die Idee der Sprints immer weniger: Wir Menschen sind nicht dafür gemacht, ständig zu sprinten: Wir erleben die Zeit wie eine Tretmühle, in der wir laufen, bis wir nicht mehr können. Meiner Meinung nach sollten wir auf einen Meilenstein hinarbeiten, mit kurzen Iterationen, Updates in die Produktion liefern, sobald sie fertig sind, und dann die neuen Funktionen für den Benutzer aktivieren, wenn wir das Gefühl haben, dass es 'gut genug' funktioniert.

Fazit: Wir sollten mit Milestones arbeiten können, wenn wir einen einfacheren Prozess haben, Dinge wie Story Points weglassen und anders darüber nachdenken, wie wir als Team arbeiten.

Azure Pipelines vs. GitHub-Aktionen

Automatisierung für Continuous Integration (CI) und Continuous Delivery (CD) ist auf beiden Plattformen verfügbar. Azure DevOps hat den Vorteil, dass es bereits seit Jahren verfügbar ist, während GitHub Actions erst Anfang 2021 für GitHub Enterprise verfügbar ist. GitHub Actions holt schnell auf, aber es ist immer noch im Aufholprozess.

Azure DevOps verfügt über ein robustes und leistungsfähiges Setup für CI/CD: Sie können die klassischen Pipelines oder Yaml-Pipelines (bevorzugt) verwenden und nach Ihren eigenen Vorlieben mischen und anpassen. Sie können eine CI-Pipeline für die schnelle Validierung eines Zweigs und eine umfangreichere Pipeline für die Erstellung des Artefakts, das Sie bereitstellen möchten, verwenden. Es gibt eine Vielzahl von Erweiterungen, die auf der Marktplatz, damit Sie das Rad nicht neu erfinden müssen. Ich habe gerade meinen Twitter-Bot überprüft @AzDoMarketNews und es sind derzeit 1630 Erweiterungen verfügbar, und es kommen immer noch ab und zu neue hinzu.

Foto von Danil Shostak auf Unsplash

Große Dinge, die derzeit auf GitHub Actions fehlen, sind:

• Vorlagen
• Sicherheitsscans bei GitHub-Aktionen
• Bessere CI/CD Geschichte

Fehlt in GitHub-Aktionen: Schablonen

Die Möglichkeit, eine Vorlage zu verwenden, um Schritte zu gruppieren, damit Sie sie nicht überall wiederholen müssen. Denken Sie z.B. an eine gemeinsame Vorlage für eine NPM-Pipeline: oft wollen Sie dort die gleichen Schritte ausführen, wie z.B. das Scannen von Abhängigkeiten, Linting, Erstellen und Ausführen von Tests. GitHub hat ein Setup für zusammengesetzte Aktionen, aber Sie können keine anderen Aktionen darin aufnehmen, nur Shell-Skripte. Das Gleiche gilt für die Definition einer "Stufe" in einer Bereitstellungspipeline: Ich möchte mein Artefakt in der Entwicklungs-/Testphase auf genau dieselbe Weise bereitstellen wie in der Produktionsphase, mit nur einigen Parameteränderungen, die auf die richtige Cloud-Umgebung abzielen: Derzeit müssen Sie die gleichen Schritte in beiden Phasen der Bereitstellung wiederholen. Wenn Sie zwischendurch einen Schritt hinzufügen, müssen Sie ihn an mehreren Stellen durchführen, oder Sie riskieren, dass Sie zwischen den Umgebungen abdriften. Azure DevOps hat hier die bessere Geschichte, denn es unterstützt Vorlagen in Ihren yaml-Pipelines. Dies hilft Ihnen dabei, doppelten Code aus Ihrer Pipeline zu entfernen.

Fehlt in GitHub Actions: Sicherheitsscans bei GitHub-Aktionen

Derzeit gibt es keine wirkliche Möglichkeit, den von Ihnen verwendeten Aktionen zu vertrauen, es sei denn, Sie vertrauen ihrem Herausgeber. In Azure DevOps gab es einen Prozess, um eine Aktion auf dem Marktplatz zu veröffentlichen, der zumindest einige Schutzscans bevor die Erweiterung verfügbar war. Außerdem mussten Sie ein Publisher-Konto anlegen, und nur wenn Sie die richtige Berechtigungen können Sie die Erweiterung in Ihrem Mandanten installieren, wo sie für alle Mitarbeiter des Unternehmens verfügbar ist.

Bei GitHub-Aktionen ist die Geschichte viel einfacher, was sie auch weniger sicher macht. Der Aufwand, um zu überprüfen, was die Erweiterung tut, und sie auf dem neuesten Stand zu halten (die Verwendung der neuesten Version ist gegen die beste Training) kann Ihrem Team Zeit rauben. Jeder mit Schreibzugriff auf das Repository können neue Aktionen in die Workflows aufnehmen (das, was Ihre Aktionen ausführt). Jeder mit einem öffentlichen GitHub-Repository können eine action.yml-Datei in ihrem Repository erstellen und Sie können sie in Ihrem Workflow verwenden. Ohne jegliche Überprüfung durch GitHub. Daher ist es sehr wichtig, dass Sie Ihre Organisation abschließen und sich überlegen, welche Aktionen Sie zulassen möchten. Es ist wichtig, dass Sie eine Prozess um GitHub Actions, damit die DevOps-Ingenieure sie trotzdem ausführen können, aber auf die sicherste Art und Weise.

Hinweis: Ich suche immer noch nach einer Möglichkeit, einen CodeQL-Scan für das Aktions-Repository zu nutzen, der alle eingehenden Änderungen als Prüfung des Problems enthält. Ich habe gesehen, dass GitHub einen solchen Scan für alle Aktionen in seinem System durchführen kann und dann Pull Requests zur Behebung der gefundenen Probleme einsendet. Ich würde das wirklich gerne als zusätzlichen Sicherheitsscan durchführen.

Fehlt in GitHub Actions: Bessere CI/CD Geschichte

Mit GitHub Actions haben Sie zwei Optionen für CI/CD:

1. Erstellen Sie eine yaml-Datei, die beide CI/CD-Dateien enthält
2. Erstellen einer yaml-Datei für CI und einer separaten Datei für CD Beide Optionen haben das gleiche Problem: insbesondere der CD-Teil: Ich möchte die gleichen Schritte für die Bereitstellung in allen meinen Umgebungen verwenden. Vielleicht füge ich in einer bestimmten Testumgebung noch etwas hinzu oder habe die Möglichkeit, einen separaten Lasttest durchzuführen, aber hauptsächlich möchte ich dieselbe Bereitstellung verwenden. Derzeit ist dies nicht ohne Weiteres möglich. Sie haben die Möglichkeit, einen zusätzlichen Workflow für eine neue Umgebung hinzuzufügen, und Sie können eine bestehende Umgebung klonen, aber das war es dann auch schon. Ich hätte gerne etwas wie Azure DevOps Vorlagen oder was GitLab hat. In GitLab können Sie include eine separate yml-Datei als Vorlage, oder verwenden Sie Anker komplette Skripte zu referenzieren und eine bessere Möglichkeit zu haben, sie zwischen mehreren Phasen wiederzuverwenden.

Artefakte

In Bezug auf die Artefakte bin ich etwas gespalten: Azure DevOps hat eine großartige Geschichte um Artefakte: die Unterstützung für verschiedene Feeds und sogar verschiedene Ansichten über einen Feed, bei dem Sie ein Paket in einen Beta-Feed hochladen und dann in die Produktion überführen können, ist wirklich großartig. So etwas gibt es bei GitHub nicht.

Dieselbe Geschichte um Universelle Pakete: Sie können jede Datei darin speichern und sogar ein Build-Skript darin veröffentlichen, um es später außerhalb von Azure DevOps wiederzuverwenden. GitHub verfügt nicht über so etwas. Es gibt das Konzept der Veröffentlichungen aber das lädt die Version immer entweder als Zip-Datei oder als exe- oder msi-Datei herunter. Manchmal müssen Sie die Dateien selbst herunterladen, ohne eine zusätzliche Verpackung. Es gibt einen Punkt auf der Roadmap zu unterstützen, aber es ist noch nicht so weit.

Docker Bilder

Was GitHub derzeit auszeichnet, ist die Möglichkeit, Ihre Docker-Images in GitHub Pakete. Das funktioniert sofort (Anmerkung: Ich habe dies nur für die Veröffentlichung von öffentlichen Container-Images verwendet, ich bin nicht sicher, ob Sie das einfach genug sperren können): Wenn jemand ein Image aus diesem Feed zieht, wird es einfach funktionieren. Der Automatisierungsablauf für das Veröffentlichen von Bildern ist ebenfalls einfach: Sie können es von einem Workflow aus tun, wie ich es tue hier wo ich meine Bilder in die ghcr.io/rajbos/local-dependency-updates. Es verwendet dafür die GitHub Container Registry, mit meinem GitHub-Benutzertag als Herausgeber des Bildes.

Sicherheitsmerkmale

Dies ist derzeit die beste Funktion für GitHub: Ich empfehle Ihnen wirklich, diese Funktion auszuprobieren und Ihren Code so schnell wie möglich nach GitHub zu übertragen. Sie können weiterhin Azure Boards und Azure Pipelines verwenden, wenn Sie das möchten: die Integration zwischen den Produkten ist wunderbar und einfach works™️. Sie können Ihren Code und Ihre Tags auf beiden Plattformen verwenden: Durch die Integration weiß das Programm, wo es zu suchen hat, und stellt die richtigen Links in der Benutzeroberfläche dar, so dass Ihre Benutzer nahtlos dorthin wechseln können, wo sie arbeiten müssen.

Einige Teile der Sicherheitsfunktionen von GitHub können in Azure DevOps nachgebildet werden, aber nur mit viel Aufwand. GitHub hat sie im Produkt selbst verfügbar. Einige davon sind kostenlos für öffentliche Repos und nicht für private Repos. Weitere Informationen dazu finden Sie auf der Seite Preisseite. Wenn Sie den GitHub Enterprise Server verwenden, sind einige dieser Funktionen über GitHub Erweiterte Sicherheit.

Dependabot

Zunächst einmal ist Dependabot. Dies ist ein Tool, das Ihren Code und die von Ihnen verwendeten Abhängigkeiten von Drittanbietern überprüfen kann. Es bietet Unterstützung für eine Vielzahl von Paketmanagern und kann sogar die Action-Versionen aktualisieren, die Sie in Ihren Arbeitsabläufen verwenden! Sie können das Programm so einrichten, dass es in regelmäßigen Abständen Ihr Repository für Sie durchsucht. Wenn es Aktualisierungen findet, sammelt es die Versionshinweise und erstellt einen neuen Pull Request für jedes Paket. Wenn es bereits einen offenen Pull Request für das Paket gibt, wird dieser PR mit der neuesten Version aktualisiert oder der alte geschlossen und ein neuer PR erstellt. Dies ist ein sehr einfacher Weg, um Ihre Abhängigkeiten auf dem neuesten Stand zu halten (und glauben Sie mir, das ist es: Ich habe mein eigenes Setup erstellt hier). Wenn Sie gute Prüfungen in Ihren Pipelines haben, können Sie sogar die Auto-Merge auf Ihr Repository und schließen den PR automatisch, wenn alle Prüfungen bestanden sind. Auf diese Weise sind Sie immer auf dem neuesten Stand mit den neuesten Versionen Ihrer Abhängigkeiten und ersparen sich dadurch eine Menge Update- und Sicherheitskopfschmerzen.

Sicherheitsüberprüfung

Wenn Sie Dependabot aktiviert haben, können Sie auch die Scannen auf Sicherheitslücken. Mit dieser Funktion behält Dependabot den Überblick über Ihre Abhängigkeiten und die von Ihnen verwendeten Versionen. Wenn eine neue Sicherheitslücke gefunden und auf ihrer eigenen Website veröffentlicht wird wird Dependabot Sie auf die Sicherheitslücke aufmerksam machen und einen Pull Request für das Repository mit dem Problem erstellen. Es wird Ihnen sogar mitteilen, ob es mehrere Repositories mit der gleichen Sicherheitslücke gibt.

Heimliches Scannen

Eine weitere großartige Funktion, die GitHub im März 2021 (GA) eingeführt hat, ist Geheimes Scannen. Sie haben eine lange Liste von Partnern, für die sie Geheimnisse (z.B. Passwörter oder Zugangscodes) in Ihrem Repository finden können und diese Geheimnisse sogar automatisch widerrufen. Wie genial ist das denn?! Sie müssen sich immer noch der Geheimnisse bewusst sein und könnten einen Prozess in Ihre Pipelines einbauen, um sie zu erkennen. Diese Funktion automatisiert dies und hilft Ihnen bei dem größten Problem beim Übertragen Ihrer Geheimnisse in Ihr Repository: Sie sollten als durchgesickert betrachtet werden: Sie können mit Git BFG um die Geheimnisse aus Ihrem Repository zu löschen, aber es könnte sein, dass jemand noch irgendwo eine alte Kopie des Repositorys hat und die alten Geheimnisse noch verfügbar sind. Es wird als viel besser angesehen, diese Geheimnisse sofort zu widerrufen und neue zu erstellen.

Code scannen mit CodeQL

Code-Scanning mit CodeQL ist ebenfalls eine neue Ergänzung des GitHub-Angebots. Es unterstützt derzeit nur ein paar Sprachen (siehe unten). Es kann sehr mächtige Dinge tun, z.B. Benutzereingaben finden, die nicht bereinigt sind, bevor Sie sie in Ihrem Code verwenden, selbst wenn sie nur drei Schichten tief in Ihrer Codebasis verwendet werden!

• C/C++
• C#
• Gehen Sie
• Java
• JavaScript/TypeScript
• Python

Es gibt eine Vielzahl von CodeQL-Abfragen in der öffentliches Depot die Sie auf Ihren Code anwenden können. Es gibt sogar ein Programm, das Ihren Code auf Spuren von Solorigate und andere Hintertüren. Sie richten es ein, indem Sie eine CodeQL Analyse Arbeitsablauf in Ihrem Repository.

Wenn Sie es in Ihren Arbeitsabläufen ausführen, werden Sie benachrichtigt, wenn es Probleme in Ihrem Repository findet. Diese Benachrichtigungen werden als zusätzliche Prüfungen hinzugefügt und sind zu finden unter Anmerkungen auch auf eingehende Pull Requests.

Alles in allem eine sehr kraftvolle Sache!