© Liashko/Shutterstock.com
Azure DevOps und GitHub - eine gute Kombination für Entwickler

Wie füreinander gemacht?


Open-Source-basierte Softwareentwicklung ist mittlerweile aus dem Entwickleralltag kaum noch wegzudenken, sei es als Konsument oder als Produzent von Open-Source-basierten Projekten. Der Platzhirsch unter den Plattformen für diese Projekte ist mit Abstand GitHub. GitHub ist mittlerweile so etwas wie das Synonym für Open Source und Git. Die Bedeutung und Reichweite der Plattform hat auch Microsoft erkannt und GitHub übernommen. GitHub wird dabei ähnlich wie LinkedIn und Minecraft als eigenständige Tochter weitergeführt.

Gerade im Entwicklerkontext sieht man hier aber einen gewissen Konflikt, stand doch Microsofts hauseigene DevOps-/ALM-Plattform Azure stets im Wettbewerb mit den anderen Plattformen wie GitHub oder GitLab. Nicht nur der Kauf von GitHub war ein klares Bekenntnis in Richtung Open-Source-Kultur, sondern auch die aktive Unterstützung von Open-Source-Projekten durch Azure-DevOps-basierte Services (auch jenseits von Azure DevOps bzw. GitHub). Der aktuelle Artikel sieht seine Schwerpunkte bei den Fragestellungen „Wie kann man gut Open Source auf GitHub machen?“, „Was gibt es dabei zu beachten?“ und „Wie kann man sinnvoll GitHub-basierte Open-Source-Entwicklungen mit einzelnen Azure DevOps Services aufwerten?“.

GitHub und Azure DevOps

Bevor es in etwaige Details geht, gilt es, zunächst Begrifflichkeiten, grobe Gemeinsamkeiten und auch Unterschiede aus der Vogelperspektive zu klären.

Wie zuvor angemerkt, wird GitHub gern als Synonym für Git als das dezentrale Versionskontrollsystem für Open-Source-Projekte verwendet. Festzuhalten gilt, dass GitHub selbst nicht der Erfinder bzw. Ursprung von Git ist. Seine Ursprünge hat Git in der Linux-Kernelentwicklung, und der Erfinder ist Linus Torvalds. Git selbst kann problemlos auch ohne GitHub oder andere Plattformen genutzt werden. Es ist seit seinem ersten Auftreten als dezentrales Versionskontrollsystem konzipiert worden. Jedes Git Repository (Container für die Artefakte) auf einem Rechner enthält stets die komplette Historie, und Entwickler veröffentlichen ihren Code und andere Dateien in dieses lokale Repository. Anschließend kann der Entwickler seine Änderungen mit anderen Git Repositories abgleichen (Git-Kommandos: Pull, Push, Fetch). Der Austausch dieser Informationen benötigt dabei nicht zwingend eine zentrale Plattform, d. h. ein Abgleich kann über diverse Kommunikationskanäle wie z. B. über einen eigenen Webserver, Windows Fileshare oder auch eine Linux-SSH-Verbindung erfolgen. Das Problem im Internet ist dabei, dass diese Arten von Austausch nicht immer sonderlich komfortabel sind.

An dieser Stelle ist GitHub eingesprungen und hat über die Zeit den De-facto-Austauschpunkt für Git Repositories im Internet geschaffen. Es speichert dort komplette Git Repositories auf die gleiche Art und Weise wie lokal und stellt sie über verschiedene Protokolle (HTTP, SSH) wieder zur Verfügung. Der Entwickler spart sich also den 24/7-Betrieb eines Servers. Zusätzlich hat GitHub neben dem reinen Hosting von Repositories seine Plattform noch um Werkzeuge zur Zusammenarbeit ergänzt. Beispiele hierfür sind Git-Repository-Suche, Codesuche, ein einfach nutzbarer Issue Tracker, Wiki, Analysewerkzeuge oder auch Unterstützung von isolierter Entwicklung mittels Forks. Forks ermöglichen die Anfertigung einer komplett isolierten Repository-Kopie. Der Nutzer von Quell- und auch Klon-Repositories wird dabei von GitHub durch diverse Funktionen unterstützt, Codeänderungen in den isolierten Repositories zu identifizieren und effizient und kontrolliert auszutauschen. Schaut man sich den Funktionsumfang von GitHub genauer an, dann fällt auf, dass GitHub sich auf Kernfunktionalitäten konzentriert. Alles was nicht zum Kernbereich gehört, kann über offene Schnittstellen von Externen nachgerüstet werden. Durch diese Offenheit hat sich ein starkes Ökosystem an freien und kommerziellen Part-nerlösungen etabliert (GitHub Marketplace [1], Abb. 1). Hier ist es wie bei anderen Marketplace-Systemen auch: Man hat die Qual der Wahl, eine passende Lösung für sein Problem zu finden. Das ist aber auch ganz charmant, da wir ja als Entwickler/-innen nicht ein bereits gelöstes Problem noch einmal lösen wollen.

orschel_bader_github_azure_1.tif_fmt1.jpgAbb. 1: GitHub Marketplace

Diese offenen Schnittstellen sind gerade im Kontext von Azure DevOps bzw. dessen Teil-Services extrem wichtig. Auch wenn GitHub jetzt ein Microsoft-Tochterunternehmen ist, muss und soll das Azure-DevOps-Team nur die offiziellen GitHub-Schnittstellen nutzen. Microsoft bekommt hier also keine Vorzugsbehandlung in Form von eigenen inoffiziellen Schnittstellen, sondern ist aus Erweiterungssicht nur ein weiterer Partner. Das bedeutet aus GitHub-Nutzersichtweise, dass man einzelne Azure DevOps Services nutzen kann, aber nicht muss. GitHub bzw. Azure DevOps wird den Nutzer weder zu der einen noch zu der anderen Plattform noch den einen oder anderen Services drängen, sondern der Nutzer wählt je nach Problemstellung die passende Lösung.

Azure DevOps war vorher bekannt als Team Foun-dation Server (TFS) bzw. die Cloud-Variante unter dem Namen Visual Studio Team Services (VSTS), und verfolgt im Gegensatz zu GitHub den Ansatz, den kompletten Applikationslebenszyklus von der Anforderung bis zur Auslieferung zu unterstützen. Historisch bedingt ist das Produkt mit dem Ansatz „Best of Suite“ (alles aus einer Hand) gestartet. Mit der Umbenennung zu Azure DevOps kann auch von „Best of Breed“ (Beste Lösung in einer Nische) gesprochen werden, d. h. der Nutzer kann selektiv einzelne, für ihn sinnvolle Module benutzen und nicht so sinnvolle Module durch Fremdlösungen ersetzen bzw. ergänzen. Azure DevOps selbst besteht aus den Teil-Services Azure Boards, Azure Pipelines, Azure Artifacts, Azure Test Plans und Azure Repos. Einen Überblick zu den Anwendungsbereichen zeigt Abbildung 2.

orschel_bader_github_azure_2.tif_fmt1.jpgAbb. 2: Überblick über die Services in Azure DevOps

Im Zusammenspiel mit GitHub sind die folgendern Services am interessantesten: Azure Pipelines, Azure Boards und Azure Artifacts. Azure Pipelines ist mit Abstand der wichtigste Service, da Microsoft die Build- und Release-Engine für Open-Source-Projekte kostenlos zur Verfügung stellt. Die gehostete Lösung funktioniert sowohl auf Windows, Linux als auch Mac. Kostenlos gibt es zehn parallele Build- und Release-Jobs [2]. Aus diesem Grund wird dies auch einen inhaltlichen Schwerpunkt dieses Artikels bilden.

Arbeiten auf GitHub

Wer zuvor noch nichts mit Open-Source-Entwicklung zu tun hatte und für den GitHub auch neu ist, der wird sich erst einmal die Frage stellen, wie die Entwicklung dort eigentlich abläuft. Die wichtigste Voraussetzung, die ein Entwickler mitbringen muss, ist ein sicherer Umgang mit Git. Dabei ist es egal, ob er gerne auf der Kommandozeile arbeitet oder eine der vielen Git-Anwendungen, z. B. TortoiseGit mit einer Oberfläche verwendet. Auch GitHub unterstützt hier Neueinsteiger, um schnell starten zu können, sei es durch den eigenen Desktopclient oder durch Anzeigen der Befehle, die für jeden einzelnen Schritt in der Entwicklung ausgeführt werden müssen. Doch bevor gestartet wird, stellt sich die Frage: Möchte ich mein eigenes Projekt bereitstellen oder lieber bei einem schon bestehenden Projekt mitwirken?

Wer sein eigenes Projekt als Open Source auf GitHub entwickeln möchte, kann bequem ein eigenes Repository erstellen und seinen lokalen Code hochladen (git push). Durch die dezentrale Art und Weise von Git ist es sehr einfach, seinen Code inklusive Historie zu teilen. Einmal in GitHub angekommen, haben jetzt andere die Möglichkeit, am Projekt mitzuwirken. Doch wer möchte wirklich, dass fremde Leute, die man unter Umständen gar nicht kennt, einfach ohne weitere Kontrolle Code ändern können? Im einfachsten Fall benötigen Externe zunächst eine Schreibberechtigung auf das Repository. Um Reviews und eine parallel risikofreie Arbeit zu unterstützen, werden Änderungen typischerweise nicht direkt im Master-Branch, sondern in Feature-Branches vorbereitet. Wenn sie abgeschlossen sind, werden sie durch Mergen in den Master-Branch übernommen (git merge).

Um diesen Prozess einfacher zu gestalten, bietet GitHub die Möglichkeit, dass Code über einen sogenannten Pull Request in einen Branch bzw. ein Repository fließen kann. Bei einem Pull Request stellt ein Entwickler eine Anfrage an einen anderen Branch oder ein anderes Repository, seine Änderungen in einen bestimmten Branch zu übernehmen. Je früher dabei der Pull Request gestellt wird, desto besser, denn so können frühzeitig schon andere Entwickler Feedback geben. Nimmt man zum Beispiel den Linux-Kernel und dessen Entwicklungsprozess [3] als Vorlage, kommen neue Änderungen ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang