Azure DevOps

Codeverwaltung ist auch für Administratoren ein wichtiger Baustein. Git als Software und das in der Cloud gehostete GitHub oder Gitlabs sind im Bereich Open Source gut bekannt. Die Softwareentwicklung innerhalb von Firmen hat aber weitere Anforderungen und in der Microsoft -Welt ist der Team Foundation Server (TFS), vormals "Visual Studio Team System" und "Visual Source Save" eine gerne genutzte Plattform, die für Unternehmen wichtige Zusatzfunktionen enthält. Microsoft hat TFS 2013 mit einer GIT-API ausgestattet, so dass Entwickler seitdem mit ihren von GitHub bekannten Tools direkt auf TFS zugreifen können. Im Juni 2018 hat Microsoft dann auch noch GitHub gekauft.

Aber was habe ich als Admin oder Consultant davon? Dann lesen Sie bitte vorab Git für Administratoren und Consultants und kommen dann wieder zurück, denn neben GitHub oder einem eigenen GIT ist auch Azure DevOps eine interessante Option.

Beachten Sie die Checkliste Tenant Einrichtung, um die unkontrollierte Neuanlage von DevOps durch ihre Anwender zu unterbinden und bei Migrationen liefert die Seite T2T DevOps weitere Informationen.

GitHub, Git, DevOps, DevOps Server

Auf der Seite GIT und GitHub habe ich schon etwas die Unterschiede zwischen GIT als Server, den jeder auch selbst installieren kann und GitHub als Cloud-Service erklärt. Nun taucht hier noch DevOps auf und ich versuche mal eine Gegenüberstellung der vier Versionsplattformen, die mit einer Ausnahme alle auch als kostenfreie Version nutzbar sind. Dies sollte keine 100% Vergleichstabelle sein und ich denke, dass die Entwicklung schnelle voranschreitet, als ich die Seite aktualisieren kann. Ich beschränke mich auf die Punkte, anhand derer ich entschieden habe, was ich wo mache.

Plattform Git GitHub / Gitlabs Azure Devops Service Azure Devops Server 2019

Betreiber

Eigene Server

Microsoft

Microsoft Azure

Eigene Server

Standort

Zuhause, eigenes RZ, eigene Cloud

Cloud

Cloud

Zuhause, eigenes RZ, eigene Cloud

Authentifizierung

Selbst

GitHub Konto

Azure AD, Microsoft Konto, GitHub Konto

Active Directory

Struktur

Projekte

User - Repository

Organisation -  Projekte

Projekte

Pakete

 

Free
Pro
Teams
Enterprise

Basic
Stakeholder
Visual

 

Lizenz

GNU General Public License version 2.0

Free
Pro User

Pro Benutzer
Cal in Visual Studio

Miete oder Kauf

Coworker

Unlimited

Privat Repo: 3
Public Repo: nolimit

5 Basic free

Lizenzabhängig

Funktionsumfang

Basisfunktionen

Erweiterbar

Erweiterbar und wohl etwas mehr Funktionen als GitUB

Selbstbestimmt

Dass sie Sourcecode, Skripte aber vielleicht auch Dokumentationen und Webseiten nicht mehr auf einem Dateiserver ablegen sollten, dessen einzige Versionierung durch Backup und umbenannte Kopien der Dateien besteht, ist klar. Es gibt einfach ein paar Fragen, die Sie für sich beantworten müssen:

Frage Cloud On-Premises

Datenspeicherort

Mit einem Angebot in der Cloud geht es per GitHub oder Azure DevOps Services in wenigen Minuten los. Ein Konto ist schnell angelegt und sie können erste Erfahrungen sammeln. Da beide Plattformen auch "GIT" als API sprechen können Sie sogar Inhalte zwischen beiden Plattformen mit ihrem Client synchron halten. Allerdings liegt ihr Code eben "auch" in der Cloud und sie Vertrauen darauf, dass der Anbieter die Plattform sicher und verfügbar betreibt.

Ein GIT-Server ist sehr schnell auf einem PC oder sogar NAS-System installiert. Das kann für ein kleines Internes System durchaus eine Option sein.

Ein DevOps Server ist eine andere Hausnummer und sie sollten nicht nur aufgrund der Kosten schon gut wissen, war sie da tun.

Kosten

Bei SaaS-Diensten gibt es fast immer eine eingeschränkte kostenfreie Version, die für Administratoren und Consultants aber meist erst einmal ausreicht. Wenn Sie hier drüber kommen, dann sollten Sie mit ihren Skripten so viel verdienen, dass Sie auch eine SaaS Lizenz kaufen können.

Der Eigenbetrieb bedeutet erst einmal die Bereitstellung der Plattform (Hardware), die Installation der Software (Kostenfrei oder Kauf) und nach der Konfiguration der Betrieb.

Funktionen

Die Basis-Versionen erlauben die Code-Versionierung und das Tracken von Features und Bugs. Zusatzfunktion wie z.B. automatische Build-Prozesse bis zu Tests und die Bereitstellung von signierten Ergebnissen sind je nach Plattform möglich aber aufpreispflichtig.

Allerdings gibt es auch zwischen GitHub und DevOps Unterschiede in der Funktionalität. Sie werden einen "normalen Admin/Consultant" aber meist nicht betreffen.

Auch On-Premises können Sie das Backend natürlich erweitern. Aber auch hier sind Sie es, die die Hardware und Software bereitstellen (CAPEX) und betreiben müssen.

Sichtbarkeit

Hier ist GitHub im Vorteil, da Sie die Aktivitäten ihres Profils auch öffentliche machen können. Einige Firmen bewerten bei Neueinstellungen durchaus das Engagement von Entwicklern auf GitHub. Bei Azure DevOps ist das nicht sichtbar

Alles was Sie tun, sieht niemand

Es gibt sicher noch weitere Fragen und Gegenüberstellungen. Ich möchte das Thema hier aber nicht weiter stressen und ein paar Beispiele bringen.

DevOps Stichpunkte

Mittlerweile habe ich einige Devops bei Kunden in Betrieb und unterstütze diese. Ich habe mir folgenden Spickzettel entwickelt:

Von unten nach oben haben Sie:

Komponente Beschreibung

Repository (Repo)

Dateien liegen in Ordnern, die in einem Repository liegen. Diese Dateien werden versioniert, so dass Sie immer wieder zu einer früheren Version zurückgehen können. Wer Sharepoint kennt, würde dies eine Dokument-Library bezeichnen. Eine individuelle Berechtigung der Personen pro Ordner oder gar Datei ist nicht vorgesehen. Wenn jemand etwas "kaputt" macht, können Sie dies über die Versionierung erkennen und beim Zusammenführen (Merge) der Änderungen erkennen und ablehnen oder eine frühere Version wieder reaktivieren. Es geht ja um Zusammenarbeit.

Projekt

Das Projekt enthält neben dem Repro mit den Dateien, Push/Pull-Requests, Branches etc. auch Bereiche zur Verwaltung (Backlogs, Sprints, etc.), Automatisierung (Pipelines). Auf der Ebene eines Projekts können Sie Personen und Gruppen Berechtigungen vergeben. Vergleichen Sie dies einfach mit der der frühen Dateifreigabe auf einem Windows Server, auf der Sie Berechtigungen für den Einstieg in das dahinterliegende Dateisystem vergeben können.

Organisation

Ein oder mehrere Projekte sind immer unter genau einer Organisation angeordnet. Die Organisation ist ein Container, über den organisationsweite Einstellungen und insbesondere die Verbindung zu genau einem AzureAD zur Authentifizierung der Anwender hergestellt wird.

  • Meist hat eine Firma genau eine DevOps Organisation, die auch immer mit genau einem AzureAD verbunden ist.
  • Eine Organisation pflegt zwar Benutzer und Gruppen aber die Benutzer sind immer mit einem AzureAD-Konto verknüpft. In der Benutzerdatenbank der DevOps-Organization steht quasi nur der "Displayname", die "Mailadresse" und Gruppen samt Mitgliedern aber hat selbst keine Kennworte DevOps bezieht die Autorisierung aus dem AzureAD.
  • Eine DevOps-Organization kann immer nur mit genau einem AzureAD verbunden werden.
  • Alle DevOps Organisationen sind mit einer eindeutige URL unter "https://dev.azure.com/<orgname>" erreichbar. Der Namen kann bei der Neuanlage einer Organisation frei gewählt und später sogar geändert werden. Es gibt meines Wissens keinen Weg den Admin einer fremden DevOps Organisation zu erhalten.
  • Wer kann anlegen?
    Standardmäßig kann jeder AzureAD Benutzer sich eine eigene Organisation anlegen, wenn Sie dies nicht unterbinden (Siehe Checkliste Tenant Einrichtung und Restrict organization creation via Azure AD tenant policy https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/azure-ad-tenant-policy-restrict-org-creation?view=azure-devops.)
  • Gäste
    In der DevOps Organization können auch Gäste aus dem verbundenen AzureAD referenziert werden. Der Schlüssel ist auch hier der echte UPN des Gastkonto, d.h. user@domain.tld und nicht user_domain.tld#EXT#@<tenantname>.onmicrosoft.com, was bei einer Umstellung der Verknüpfung relevant ist.
  • User Matching
    DevOps nutz die Mailadresse in DevOps, um den User anhand seines UPN im AzureAD zu finden. Wird der UPN geändert, dann muss in DevOps der Benutzer neu verknüpft werden, wodurch sich dann in DevOps der Benutzereintrag ändert.
  • Kostenfrei oder Azure Subscription
    Jede DevOps-Organization startet mit einer kostenfreien 5-User Version. Wenn Sie kostenpflichtige Funktionen nutzen wollen, muss die Organisation mit einer Azure Subscription verbunden werden.
  • Admin-Übersicht
    Eine Übersicht der mit ihrem AzureAD verbundenen DevOps Organizations erhalten sie als Administrator am Besten, wenn Sie eine eigene DevOps Organisation besitzen. Hier können Sie eine CSV-Datei aller verbundenen DevOps-Organzations auf https://dev.azure.com/<Orgname>/_settings/organizationAad herunterladen.
  • Umzug
    Wenn Firmen verkauft, aufgeteilt oder zusammengeführt werden, müssen auch Daten aus DevOps umgezogen werden. Bei einer Tenant zu Tenant-Migration ist das mit einer DevOps Organisation relativ einfach. Siehe dazu T2T DevOps. Dateien in Repositories können ebenfalls recht einfach per GIT durch einen Clone übertragen werden.
  • Benutzerinformation
    Als Anwender kann ich über die URL . https://go.microsoft.com/fwlink/?LinkId=309329 oder https://aex.dev.azure.com/me einfach sehen, in welchen DevOps Organizations ich berechtigt bin.

Die List wird ggfls. erweitert.

Mit DevOps loslegen

Starten Sie ihren Browser und gehen Sie zu https://dev.azure.com. Schon das Eingangsbild verwirrt, weil hier sowohl der kostenfreie Start mit Devops aber direkt daneben auch der Einstieg in GitHub verlinkt ist. erst klein drunter steht, dass Sie sich auch mit einem bestehenden Konto anmelden können:

An der Stelle fehlt auch eine Information, wann sie welchen Weg gehen sollte. Vielleicht erwartet Microsoft, dass die Besucher sich schon informiert haben und die richtige Wahl treffen. Auf der anderen Seite erwarte ich dann aber nicht, dass jemand hier landet, wenn er zu GitHub wollte. Wir wollen aber mit Azure DevOps starten und klicken auf "Start Free" und landen auf der Anmeldeseite:

Das Fenster kommt uns aus der Office 365 Welt. Bekannt vor und sie können sich hier mit einem Office 365/AzureAD Konto aber auch mit einem Microsoft Konto (vormals LiveID, Passport) anmelden könne. Und sie können auch noch ihr GitHub-Konto verwenden.

Achtung: Wenn ihr Konto noch keine "Organisation" hat, dann wird automatisch eine Organisation angelegt. Die können Sie natürlich wieder löschen. Aber wer mit mehreren Konten experimentiert, findet sehr schnell mehrere Mails im Postfach:

Bitte entsprechend drauf achten und ggfls. Aufräumen. Ich habe noch nicht erlebt, dass Microsoft eine Organisation aufgrund Inaktivität wieder löscht.

Organization und Projekt

Kaum angemeldet hat DevOps ihnen schon eine "Organisation" angelegt und fordert Sie auf, ein neues Projekt anzulegen.

Unter Advanced können Sie Versionskontrolle zwischen dem verteilten Git und dem zentralistischen TFVS umstellen. GIT ist Default und TFVS ist nur für besondere Fälle vorzuziehen. Es gibt extra ein Migrationswerkzeug von TFVS zu Git aber wohl nicht in die Gegenrichtung.

Achtung:
Sie können mehrere Organisationen anlegen und jeden Namen als URL wählen, der nicht belegt ist. Es gibt meines Wissens keine einfache Möglichkeit zu ermitteln, wer der "Owner" einer Organisation ist. Eine Organisation kann umbenannt werden. Dennoch ist es nervig, wenn z.B. ein anderer Anwender der Firma schon mal was "begonnen" hat, niemand davon weiß und nun der Name "belegt" ist.

In dem Zuge sollte ich ein paar Begrifflichkeiten erläutern, die ich auch erst mir erarbeiten musste.

  • Organisation (in DevOps)
    Eine Organisation ist einfach ein Einheit, in der mehrere Projekte zusammenfasst werden können und die unter einer eindeutigen URL erreichbar ist. Sie hat erst einmal nichts mit einer "Exchange Organisation" oder einer "Firmenorganisation" zu tun. In einer Firma kenn es problemlos mehrere DevOps Organisationen geben und selbst sie als Einzelperson können mehrere Organisationen anlegen. Eine Organisation ist auch nicht an ihren Office 365 Tenant gebunden sondern eine eigenständige Einheilt mit einem Besitzer
    Sie können eine Organisation umbenennen und auch den "Besitz" an jemand anderes "übergeben". Alle Daten einer Organisation liegen in einer Azure Region und die Daten können auch zwischen Regionen "verschoben" werden.
    Interessant sind daher eigene Organisationen für Projekte, die sie vielleicht einmal an eine andere Firma oder Kunden nach Abschluss der Entwicklung "übergeben" wollen oder Sie etwas neues Entwickeln, was als eigene Firma "ausgegründet" werden soll. Sie sparen sich dann eine aufwändige Migration der Daten.
    Zur Authentifizierung kann eine Organisation mit einem AzureAD Tenant verbunden werden, so dass Sie die Benutzer als auch Gast-Benutzer aus diesem Tenant dann Berechtigungen
  • Projekte und Ordner geben Struktur (Organisation / Projekt / Verzeichnis(se) / Datei(en)
    Ein Projekt ist der Oberbegriff für eine Software für eine bestimmte Aufgabe. In einem Projekt gibt es aber noch mehrere Repositories mit Ordnern geben. Die Struktur kann also schon recht tief sein und sie müssen sich z.B. überlegen, ob Sie nun für jedes Skript ein eigenes Repository anlegen wollen oder mehrere Skripte unter einem Oberbegriff zusammenfassen. So könnte folgendes funktionieren:
    • Organisation MSXFAQ
      Das ist die Basis für alle Projekte. Auf der Organisation füge ich auch Benutzer hinzu und verknüpfte die Anmeldung mit einem AzureAD-Tenant. Diese Zuordnung kann geändert werden und die Organisation kann auch umbenannt werden. Der Name https://dev.azure.com/%organization% ist weltweit einmalig.
    • Projekt: End2End Skript
      Ich habe nicht für jeden Skript ein eigenes Projekt aber auch nicht alle Skripte in einem Sammelprojekt untergebracht. Auf dieser Ebene werden später auch Branches etc. angelegt. Auf der Ebene "Projekt" kann ich noch Berechtigungen vergeben.
    • Ordner für end2end-http, end2end-icmp, end2end-cpu  u.a.
      Jedes Skript hat seinen Ordner. Ordner dienen zur Strukturierung im Projekt.
  • Teams und Groups
    Innerhalb eines Projekts können Sie verschiedenen Personen in "Teams" und Gruppen zusammenfassen, z.B. zur Vergabe von Berechtigungen und Zuständigkeiten. Auch wenn die Namen zum Verwechseln ähnlich sind, haben diese nicht mit "Microsoft Teams" oder "Office Groups" zu tun und auch nicht mit Active Directory Gruppen.

Im Projekt

Letztlich haben wir dann ein Projekt in einer Organisation, in der es aber noch nichts gibt. Links sind die verschiedenen Bereiche mit Boards, Pipelines und Testplänen. Interessant ist aber zuerst einmal der Punkt "Repos", kurz für Repository. Hier landen gleich die Dateien.

Aber mal einfach per "XCOPY" können Sie hier natürlich nichts anlegen. Ich starte hier in der Regel auch nicht mit einem Template sonder meist habe ich ja auf meinem Computer schon mit der Entwicklung angefangen und ersten Code angelegt oder lege eben ein lokales Projektverzeichnis an. Das brauche ich später für Programmierung und Tests sowieso. Diese Verzeichnis aktiviere ich erst einmal für GIT.

C:\\code\test>git init

Dazu muss ich natürlich den Git-Client installiert haben und im entsprechenden Verzeichnis stehen. Im nächsten Schritt führe ich dann die Befehle aus, die mit DevOps schon vorgibt.

git remote add origin https://msxfaq@dev.azure.com/msxfaq/Test/_git/Test
git push -u origin --all

Wenn Sie dann im Browser ein Update machen, dann sind dort auch alle Dateien zu sehen. Sie können die Dateien und Änderungen auch einsehen aber klassisch programmiert wird natürlich auf ihrem PC, um dann die Änderungen wie gewohnt lokal per Commit einzuchecken und durch Pull/Push mit dem zentralen Repository abzugleichen.

Bugs, Tasks und mehr

Über die Weboberfläche können Sie aber Elemente anlegen, verwalten, und einsehen, die nicht direkt etwas mit Source-Code zu tun haben.

Bei GIT gibt es primär einen "Issue Tracker". Da ist Azure DevOps weiter aber sie können die Devops Boards mit GitHub verbinden.

Allerdings sollten Sie vielleicht nicht auch die Repositories damit verwalten. Technisch wäre es sogar möglich über einen Client z.B. ein DevOps Repo mit einem GitHub Repository abzugleichen.

Data Region ändern

Eine Besonderheit möchte ich ihnen nicht vorenthalten. Schon viele Jahre vorher habe ich mit Visual Studio auch ein Konto bei DevOps und mit eine Organisation angelegt. Als ich dann Anfang 2020 zurück gekommen bin, habe ich gesehen, dass diese Instanz in den USA liegt. Das können Sie auf den Einstellungen der Organisation prüfen.

Sie können hier die Region auch ändern.

Dies geht aber nicht einfach über ein DropDown Feld sondern ganz modern über einen Assistenzen, der quasi im Chat-Inverview die Einstellungen abfragt und überwacht

https://azuredevopsvirtualagent.azurewebsites.net/

Hier der Ablauf meines Umzugs von "East US2" nach "West Europe":

Hier nicht abgebildet ist die ist die Auswahl, in welchem Zeitfenster die Migration erfolgt, da in der Zeit die Anwender keinen Zugriff darauf haben.

Diese Meldung habe ich dann nach Abschluss der Umstellung erhalten.

Azure Admins

Einen Punkt haben wir nun noch nicht beleuchtet. DevOps ist immer an ein AzureAD gekoppelt und natürlich möchte ein AzureAD-Administrator schon wissen, welche DevOps-Organisationen sich der Identitäten aus seine AzureAD bedienen. Er möchte auch steuern, wer überhaupt eine Verbindung zum AzureAD herstellen kann. Dazu gibt es eine Rolle im AzureAD, die normalerweise leer ist

Erst wenn ein Admin auch Mitglied dieser Gruppe ist, kann er seinerseits in eine DevOps-Organisation gehen und dort eine wichtige globale Einstellung steuern:

Leider kann man als AzureAd-Admin diese Einstellung nicht im AzureAD-Porta machen:

Zusammenfassung

Mit Azure DevOps hat eine zweite und aus meiner Sicht sogar noch leistungsfähigere Plattform für Softwareentwicklung am Start. Warum und wie lange Microsoft auf Dauer beide Plattformen nebeneinander betreiben kann, weiß ich nicht. Vielleicht sehr lange, da GitHub schon immer sehr viele "Open Source"-Projekte gehostet hat während die Team Foundation Server bislang für interne oder kommerzielle Entwicklungen genutzt wurden.

Mit Azure DevOps aus der Cloud können Firmen, die sich keinen On-Premises-Server mehr leisten wollen, nun Online weiter arbeiten. Diese Klientel wird vermutlich bei GitHub etwas Sorge haben, dass es professionell genug ist. Die Angst ist unbegründet aber da es beide Plattformen ja als "Free-Version" gibt, haben Sie als Administrator oder Consultant nun die Wahl, ob sie mit einem GitHub-Account auf GitHub arbeiten oder mit ihrem Microsoft oder auch AzureAD-Konto auf Azure DevOps.

Firmen werden wohl eher zu Azure DevOps tendieren, denn durch die Kopplung der Anmeldung an einen Office 365 Tenant und die Steuerung von anderen Personen über "Guest Access" fühlt sich das alles erst einmal sicherer an als ein öffentliches GitHub Repository, welches von jedem anderen GitHub-Anwender kopiert werden kann. Hier prallen dann wohl eher auch unterschiedliche Denk- und Arbeitsweisen aufeinander. Ich kann mir aber auch vorstellen, dass auf lange Sicht die beiden Produkte immer weiter verbunden und am Ende unter einem Namen zusammengeführt werden.

Ich nutze beide Plattformen. Meine MSXFAQ-Skripte verwalte ich per GIT und lege diese noch auf GitHub ab während Skripte im Umfeld von Net at Work in DevOps liegen. Was für sie die richtige Plattform ist, bleibt ihnen überlassen. Sie könne sogar beide Plattformen gleichzeitig nutzen, da beide GIT verstehen und Sie damit eine Verknüpfung herstellen können.

Weitere Links