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 |
Basic |
|
Lizenz |
GNU General Public License version 2.0 |
Free |
Pro Benutzer |
Miete oder Kauf |
Coworker |
Unlimited |
Privat Repo: 3 |
5 Basic free |
Lizenzabhängig |
Funktionsumfang |
Basisfunktionen |
Erweiterbar |
Erweiterbar und wohl etwas mehr Funktionen als GitUB |
Selbstbestimmt |
- GitHub: Compare features
https://GitHub.com/pricing#feature-comparison - GitLab: SaaS offering hosted by Gitab
https://about.gitlab.com/pricing/ - Pricing for Azure DevOps
https://azure.microsoft.com/en-us/pricing/details/devops/azure-devops-services/ -
Start using Azure DevOps
https://docs.microsoft.com/en-us/azure/devops/user-guide/?view=azure-devops
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.
|
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.
- Portalseiten um Verwalten der eigenen
Identität
https://dev.azure.com/msxfaq/_usersSettings/
https://aex.dev.azure.com/me
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.
- Choosing the right version control for
your project
https://docs.microsoft.com/en-us/azure/devops/repos/tfvc/comparison-git-tfvc?view=azure-devops - Choose a process
https://docs.microsoft.com/en-us/azure/devops/boards/work-items/guidance/choose-process?view=azure-devops&tabs=basic-process - Migrate toward external git repository
https://GitHub.com/git-tfs/git-tfs/blob/master/doc/usecases/migrate_tfs_to_git.md
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.
- Organisation
MSXFAQ
- 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.
- Azure Boards & GitHub
https://docs.microsoft.com/en-us/azure/devops/boards/GitHub/?view=azure-devops
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.
- Find or change your organization location
https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/change-organization-location?view=azure-devops
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:
- Hinzufügen von Administratoren auf
Serverebene zu Azure DevOps Server
https://learn.microsoft.com/de-de/azure/devops/server/admin/add-administrator - Einschränken der Organisationserstellung
über die Azure AD-Mandantenrichtlinie
https://learn.microsoft.com/de-de/azure/devops/organizations/accounts/azure-ad-tenant-policy-restrict-org-creation - Verbinden Ihrer Organisation mit Azure
Active Directory
https://learn.microsoft.com/de-de/azure/devops/organizations/accounts/connect-organization-to-azure-ad?view=azure-devops - Add or
remove a team administrator
https://learn.microsoft.com/en-us/azure/devops/organizations/settings/add-team-administrator
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
- Git für Administratoren und Consultants
- GIT und GitHub
- Checkliste Tenant Einrichtung
- T2T Azure Subscription
-
Start using Azure DevOps
https://docs.microsoft.com/en-us/azure/devops/user-guide/?view=azure-devops -
Tools and clients that connect to Azure
DevOps
https://docs.microsoft.com/en-us/azure/devops/user-guide/tools?view=azure-devops - Azure DevOps Server
https://en.wikipedia.org/wiki/Azure_DevOps_Server -
Microsoft to acquire GitHub for $7.5
billion
https://news.microsoft.com/2018/06/04/microsoft-to-acquire-GitHub-for-7-5-billion/