Azure DevOps Server

Azure DevOps Server
Windows Azure logo.png
Entwickler (en) Microsoft
Erstveröffentlichung 2005; Vor 17 Jahren
Stabile Version
2020 Update 1 / August 10, 2021; vor 11 Monaten[1]
Betriebssystem Microsoft Windows
Typ Anwendungslebenszyklusmanagement
Lizenz Versuch
Webseite azurblau.Microsoft.com/en-us/Dienstleistungen/DevOps/Server/ Edit this on Wikidata

Azure DevOps Server (ehemals Team Foundation Server (TFS) und Visual Studio Team System (VSTS)) ist a Microsoft Produkt, das bietet Versionskontrolle (entweder mit Team Foundation Versionskontrolle (Tfvc) oder Git), Berichterstattung, Anforderungsmanagement, Projektmanagement (für beide Agile Software Entwicklung und Wasserfallteams), automatisierte Builds, testen und Release -Management Fähigkeiten. Es deckt die gesamte ab Anwendungslebenszyklusund ermöglicht DevOps Fähigkeiten.[2] Azure DevOps können als Back-End für zahlreiche verwendet werden Integrierte Entwicklungsumgebungen (Ides), ist aber auf zu maßgeschneidert auf Microsoft Visual Studio und Finsternis auf allen Plattformen.[3]

On-Premises vs. Online

Azure DevOps ist in zwei verschiedenen Formen verfügbar: On-Premises ("Server") und Online ("Services"). Die letztere Form heißt genannt Azure DevOps Services (Früher Visual Studio online, bevor es 2015 in Visual Studio Team Services umbenannt wurde). Der Cloud -Dienst wird durch die unterstützt Microsoft Azure Cloud -Plattform. Es verwendet den gleichen Code wie die lokale Version von Azure DevOps mit geringfügigen Änderungen und implementiert die neuesten Funktionen. Ein Benutzer Zeichen in Verwendung einer Microsoft-Konto Um eine Umgebung einzurichten, Projekte zu erstellen und Teammitglieder hinzuzufügen. Neue Funktionen, die in kurzen Entwicklungszyklen entwickelt wurden, werden zuerst der Cloud -Version hinzugefügt. Diese Funktionen wandern in die lokale Version als Updates in Intervallen von ungefähr drei Monaten.[4]

Die Architektur

Serverarchitektur

Azure DevOps basiert auf Multi-Tier, skalierbare Architektur. Die Primärstruktur besteht aus einer Anwendungsstufe, die für die Verarbeitung von Logik und die Wartung des Webanwendungsportals (als Team -Webzugriff oder TWA bezeichnet) verantwortlich ist. Azure DevOps wird gebaut Windows Communication Foundation Internetdienste. Diese können von jedem Kunden konsumiert werden, obwohl das Client -Objektmodell empfohlen wird. Die Datenstufe und die Anwendungsebene können auf derselben Maschine vorhanden sein.

Um die Skalierbarkeit zu unterstützen, kann die Anwendungsstufe ausgeglichen werden und die Datenstufe kann gruppiert werden. Wenn verwendet Microsoft SQL Server 2012 oder später werden Alwayson SQL Server -Failover -Cluster und Verfügbarkeitsgruppen unterstützt, wodurch die geografische Replikation von Daten ermöglicht wird.[5] Der primäre Container ist die Projektsammlung. Eine Projektsammlung ist eine Datenbank, die eine Gruppe von Teamprojekten enthält. Die Projektsammlung ist ein weiterer Skalierbarkeitsmechanismus, da jede Sammlung auf verschiedenen SQL -Servern oder SQL -Server -Instanzen platziert werden kann. "OE" -Konfigurationsdatenbank pro Azure DevOps Instanz speichert Projektsammlung Metadaten. Daten aus den Projektbanken für die Projektsammlung sind in die Warehouse -Datenbank aggregiert, die die Daten zur Vorbereitung auf das Laden in einen Analyse -Dienste -Würfel verhindern. Das Lager und der Würfel ermöglichen eine komplexe Trendberichterstattung und Datenanalyse.

Azure DevOps können sich in ein bestehendes integrieren SharePoint Bauernhof. Die SQL Server -Berichtsdienste werden für fortgeschrittenere Berichte gegen das Data Warehouse oder den Analyse Services Data Cube unterstützt. Diese Installationen können sich auf demselben System oder auf verschiedenen Systemen befinden. Build -Server, Laborverwaltungsserver, Release -Management -Server und Proxy -Server (um einen Teil der Last in der Anwendungsstufe zu reduzieren), Testmaschinen und Lasttestmaschinen können auch zur Infrastruktur hinzugefügt werden.[6] Azure DevOps integrieren sich auch mit den Teams, die eine Unternehmensprojektplanung benötigen Microsoft Project Server, was das Portfoliomanagement, das Ressourcenmanagement und die Projektverfolgung auf Unternehmensebene ermöglicht.

Erweiterbarkeit

Microsoft bietet zwei eigenständige Umverteilung Apis zum Anschließen mit Azure DevOps. Einer ist a Java SDK, der andere ist a .NET Framework SDK. Diese APIs ermöglichen die Kundenkonnektivität zu Azure DevOps. Da Azure DevOps in einer serviceorientierten Architektur geschrieben ist, kann es mit praktisch jedem Tool kommunizieren, das einen Webdienst aufruft. Ein weiterer erweiterbarer Mechanismus ist das Abonnieren von Systemwarnungen: Beispielsweise Warnungen, dass ein Arbeitselement geändert oder ein Build abgeschlossen wurde. Es gibt ungefähr 20 vorkonfigurierte Warnungen, und Teams können nach Bedarf so viele zusätzliche Warnungen konfigurieren.[7] Wenn diese Warnungen in einem erweiterbaren Szenario verwendet werden, können sie an einen Webdienst gesendet werden, um Aktionen zum Ändern oder Aktualisieren von Arbeitselementen auszulösen (z. B. die Implementierung erweiterte Geschäftsregeln oder die programmgesteuerte Generierung von Arbeitsgegenständen basierend auf einem bestimmten Szenario).

Das Data Warehouse kann auch durch die Erstellung von benutzerdefinierten Data Warehouse -Adaptern erweitert werden.[8] Mit der Einführung von TFS 2012 können benutzerdefinierte Add-Ins auch für Team Web Access erstellt werden, heißt es Webzugriffserweiterungen.

Kunden

Azure DevOps unterstützt Visual Studio 2010 und später und später, Microsoft Test Manager (MTM) 2012 und 2013. Eclipse, ältere Versionen von Visual Studio und andere Umgebungen können mit dem Microsoft Source Quell Code Control Integration Provider (MSSCCI -Provider - ausgesprochen - ausgesprochen - ausgesprochen - ausgesprochen - ausgesprochen - ausgesprochen - ausgesprochen - Miss-Key ”).[9] Diese Tools bieten vollen Zugriff auf die Funktionen in Azure DevOps.

Microsoft Excel und Microsoft Projekt werden auch unterstützt, um Arbeitselemente zu verwalten, die Massenaktualisierungen, Masseneintritt und Massenexport von Arbeitselementen ermöglichen. Microsoft Project kann verwendet werden, um Arbeiten zu planen, wenn sie an eine Methodik zur Entwicklung von Waterfall -Software entspricht. Sowohl Excel als auch Projekt unterstützen bidirektionale Datenaktualisierungen. Dies ermöglicht beispielsweise Projektmanager, einen Zeitplan in den Projekt zu setzen, diese Arbeit in Azure DevOps importieren zu lassen, in denen Entwickler die Arbeit aktualisieren, und dann kann der Zeitplan aktualisiert werden, ohne dass der Projektmanager zusätzliche Arbeiten ausführen muss.

Mit Team Foundation Server 2012, Microsoft Powerpoint wurde auch in Azure DevOps integriert, um eine schnelle Entwicklung der Storyboard zu ermöglichen, um den Anforderungen Managementprozess zu unterstützen. Die Integration bietet erweiterbare Storyboard-Formen, mit denen jede Art von Schnittstellenmessung erstellt werden kann, die dann mit den integrierten Funktionen von Powerpoint animiert werden können. Diese Storyboards können dann mit Arbeitselementen verknüpft werden.

Um die wachsende geografische Dispersion von Teams zu bewältigen und die Stakeholder früher und häufiger in dem Prozess einzubeziehen, fügte Microsoft den Feedback -Client hinzu.[10] Mit diesem Tool können Benutzer eine Anwendung ausüben, mit Audio und Videos annotieren, was sie sehen, Bildschirme erfassen und dem Entwicklungsteam kontextbezogenes Feedback geben. Dies bietet ein spezifisches Feedback zu den Funktionen einer Anwendung aus der Sicht eines Benutzers, ohne Besprechungen und Demonstrationssitzungen zu verlangen. Azure DevOps bietet auch Befehlszeilen -Tools für Unix- und Windows -Umgebungen. Die Elektrowerkzeuge für TFs umfassen a Windows Shell Integration, mit der Benutzer Dateien ein- und aus überprüfen, Dateien hinzufügen und andere grundlegende Aufgaben ausführen können, indem Sie mit der rechten Maustaste auf eine Datei oder einen Ordner klicken.

Arbeitsgegenstände

Im Zentrum von Azure DevOps steht das "Arbeitselement". Ein Arbeitselement repräsentiert eine Sache - es kann Arbeit sein, die erreicht werden muss, ein Risiko zum Nachverfolgen, einen Testfall, einen Fehler oder praktisch alles andere, was sich ein Benutzer vorstellen kann. Arbeitselemente werden durch die definiert Xml Dokumente und sind hoch erweiterbar.[11] Arbeitselemente werden zu a kombiniert Prozessvorlage Das enthält diese und andere Informationen, um einen Entwicklungsrahmen bereitzustellen. Azure DevOps enthält Prozessvorlagen für die Microsoft Solutions Framework Für Agile, Scrum und CMMI. Teams können eine integrierte Vorlage oder eine der vielen Vorlagen verwenden, die für die Verwendung von Dritten zur Verfügung stehen. Prozessvorlagen können mit dem Prozessvorlageneditor, der Teil der Elektrowerkzeuge ist, angepasst werden.[12]

Arbeitselemente können mit unterschiedlichen Beziehungen miteinander verknüpft werden, um einen hierarchischen Baum mit Arbeitselementen oder eine flache Beziehung zwischen Arbeitselementen zu erstellen. Arbeitselemente können auch mit externen Artefakten wie Webseiten, Dokumenten zu einer Dateifreigabe oder Dokumenten in einem anderen Repository wie SharePoint verknüpft werden. Arbeitselemente können auch mit Quellcode, Erstellen von Ergebnissen, Testergebnissen und spezifischen Versionen von Elementen in der Quellensteuerung verknüpft werden.

Die Flexibilität im Arbeitselementsystem ermöglicht es Azure DevOps, viele Rollen vom Anforderungsmanagement bis hin zu Fehlerverfolgung, Risiko und Ausgabe von Verfolgung sowie der Aufzeichnung der Ergebnisse von Bewertungen zu spielen. Die erweiterbaren Verbindungsfunktionen stellen sicher, dass die Rückverfolgbarkeit von Anforderungen zu Quellcode zu Testfällen und -gebnissen zu Prüfungszwecken sowie zu historischem Verständnis von Veränderungen erreicht und gemeldet werden kann.

Quellcodeverwaltung

Azure DevOps unterstützt zwei verschiedene Arten von Quellcodeverwaltung - Die ursprüngliche Quellvertretungsmotor namens Team Foundation Version Control (TFVC) und mit der Veröffentlichung von TFS 2013 unterstützt sie Git Als Kernrepository für Quellenkontrollrepository.

Team Foundation Versionskontrolle

TFVC ist ein zentrales Versionskontrollsystem, mit dem Teams alle Artefakt -Art in seinem Repository speichern können.[13] TFVC unterstützt zwei verschiedene Arten von Arbeitsbereichen bei der Arbeit mit Client -Tools - Server -Arbeitsbereichen und lokalen Arbeitsbereichen.[14] Mit den Serverarbeitsbereichen können Entwickler Dateien zum Auschecken sperren und anderen Entwicklern die Bearbeitung von Dateien zur Verfügung stellen. Eine häufige Beschwerde für dieses Modell ist, dass Dateien auf dem Entwicklungsgerät als schreibgeschützt markiert sind. Außerdem müssen Entwickler "offline", wenn der Server nicht kontaktiert werden kann. Lokale Arbeitsbereiche wurden entwickelt, um diese Probleme zu vermeiden. In einem lokalen Arbeitsbereich sind Szenario-Dateien nicht schreibgeschützt und müssen nicht ausgecheckt werden, bevor sie daran arbeiten. Solange sich die Dateien auf dem lokalen Maschine des Entwicklers befinden, spielt es keine Rolle, ob der Server verbunden ist oder nicht. Konflikte werden behandelt Check-In Zeit.

Um die Leistung für Remote -Kunden zu verbessern, umfasst Azure DevOps die Installationsfähigkeit Proxy -Server.[15] Proxy -Server ermöglichen es, an einem Standort näher an den Entwicklern die Quellensteuerungsinhalte zwischenzuspeichern, um lange Netzwerkreisen und die zugehörige Latenz zu vermeiden. Check-Ins werden weiterhin direkt gegen die Azure DevOps-Anwendungsstufe durchgeführt, sodass der Proxy-Server in Leseszenarien am vorteilhaftesten ist.

Im Rahmen der Quellvertretungsmotor unterstützt Azure DevOps eine Reihe von Funktionen, mit denen Entwickler den Code sicherstellen können, der konfigurierbare Regeln befolgt. Diese Regel Engine wird als Check-in-Richtlinie bezeichnet. Es gibt mehrere Richtlinien für die Box heraus, wie z. Diese Richtlinien sind erweiterbar und können verwendet werden, um alle Aspekte des überprüfenden Codes, der Kommentare und der damit verbundenen Arbeitselemente zu untersuchen. Azure DevOps unterstützt auch eine Codeanalysefunktion, die bei unabhängig voneinander verwendetem als bezeichnet wird als Fxcop. Die Einbeziehung in Azure DevOps bedeutet, dass die Analyse gegen den Code ausgeführt wird, der in den Server und bei automatisierten Builds überprüft wird.

Die Azure Repos -Erweiterung für Visual Studio -Code Unterstützt TFVC.[16]

Git

Mit der Veröffentlichung von TFS 2013 fügte Microsoft den nativen Support für hinzu Git. Dies ist keine microsoft -spezifische Implementierung, sondern eine Standardimplementierung basierend auf dem libgit2[17] Bibliothek. Dies ist die gleiche Bibliothek, die die Populär macht GitHub und der Code ist bei GitHub frei verfügbar. Da Microsoft den Ansatz der Verwendung einer Standardbibliothek gewählt hat, kann jeder Git -Client nun nativ mit Azure DevOps verwendet werden (mit anderen Worten können Entwickler ihre bevorzugten Tools verwenden und niemals die Standard -Azure DevOps -Clients installieren). Dies ermöglicht Tools auf jeder Plattform und jeder IDE, die Git unterstützen, um eine Verbindung zu Azure DevOps herzustellen. Zum Beispiel beides Xcode und Android Studio Unterstützen Sie Git-Plug-Ins. Wenn Entwickler nicht den Microsoft Team Explorer Everywhere Plug-In für Microsoft verwenden möchten FinsternisSie können wählen, ob sie Egit verwenden möchten[18] Um mit Azure DevOps eine Verbindung herzustellen.

Die Verwendung von Git schließt nicht den Vorteil der Verwendung von Azure DevOps -Arbeitselement oder Build -System aus. Wenn Sie den Code mit Git überprüfen, verbinden Sie die Arbeitselement-ID im Check-in-Kommentar den Check-in mit dem angegebenen Arbeitselement. Ebenso wird Team Build auch GIT -Projekte aufbauen.

Einer der Hauptgründe für die Verwendung von Azure DevOps als Git -Repository ist, dass es von SQL Server unterstützt wird und den gleichen Schutz wie Team Foundation Version Control (TFVC) erhalten. Dies gibt den Entwicklern einige Möglichkeiten bei der Auswahl der Art von Projekt- und Arbeitsstil, die für sie am besten geeignet ist.

Berichterstattung

Die Berichterstattung ist seit ihrer ersten Veröffentlichung im Jahr 2005 ein Kernkomponente von Azure DevOps. Die Berichtsinfrastruktur besteht aus einem Data Warehouse[19] (TFS_WAREHOUSE), eine relationale Datenbank und ein SQL Server Analysis Services Data Cube.[20] Beide Quellen stehen für die Berichterstattung über SQL Server -Berichtsdienste zur Verfügung, wenn diese Option installiert ist. Da es sich um Standarddatenbank- und Würfelstrukturen handelt, kann jedes Tool auf diese Datenquellen von ihnen berichten. Dies umfasst Tools wie Cognos, Tableau, Excel und andere Berichterstattungsinstrumente. Bei jedem Out -Out -Box -Prozessvorlage sind eine Reihe von Berichten für Berichtsdienste enthalten, die Build -Informationen, Testergebnisse und Fortschritte, Projektmanagement, Agile -Berichte (Backlog -Übersicht, Release -Burndown, Sprint Burdown und Geschwindigkeit), Fehler und Ausgabedaten abdecken. Neue Berichte können mit dem Report Builder für SSRs erstellt werden, und alle vorhandenen Berichte können geändert werden.

Spezialisiertere Berichterstattung ist für Lastentestergebnisse verfügbar. Diese Daten sind direkt in Visual Studio verfügbar und können für eine detaillierte Analyse in Excel exportiert werden.

TFS 2013 führte eine neue Funktion namens "Leichtgewichtsberichterstattung" ein, die die Möglichkeit bietet, Echtzeitberichte basierend auf Abfrageergebnissen zu erstellen, die nicht auf dem Lager oder Würfel beruhen. TFS 2012 (und Fortsetzung von 2013) bietet Echtzeit-Burndown-, Geschwindigkeits- und CFD-Diagramme direkt innerhalb des Team-Webzugriffs.

Team Build

Team Build (vor TFS 2015) ist eine Build -Serveranwendung, die auf dem Team Foundation Server enthalten ist. Zwei Komponenten bilden das Team Build - MSBUILD und Windows Workflow Foundation. MSBuild ist eine deklarative XML -Sprache ähnlich wie Apache Ant. WF wurde zum Build -Prozess hinzugefügt, beginnend mit TFS 2010; Zuvor war nur MSBuild verfügbar. Die Build -Fähigkeiten haben sich mit jeder nachfolgenden Freisetzung von Azure DevOps weiterentwickelt. In TFS 2010 und 2012 die WF -Vorlagen (Erweiterbare Anwendungs ​​-Markup -Sprache) Dateien wurden in der Quellensteuerung gespeichert und konnten direkt von der Quellsteuerung bearbeitet und versioniert werden. In TFS 2013 wurden diese Dateien entfernt, um Unordnung zu beseitigen und den Build -Prozess zu optimieren. Die WF -Vorlagen können bei Bedarf weiterhin heruntergeladen, bearbeitet und in der Quellensteuerung gespeichert werden, und TFS 2013 brechen nicht vorhandene TFS 2010- oder 2012 -Build -Prozessvorlagen. Mit der Unterstützung von Git In TFS 2013 wurde Team Build erweitert, um automatisierte Aufbau von GIT -Projekten sowie TFVC -Projekte zu ermöglichen.

Windows Workflow steuert den Gesamtfluss des Build-Prozesses, und Azure DevOps umfasst viele vorgefertigte Workflow-Aktivitäten zum Verwalten gemeinsamer Aufgaben, die während eines Builds ausgeführt werden.[21] MSBUILD ist die Markup -Sprache, die in den Dateien. Das Build -System ist erweitert, wobei Benutzer in der Lage sind, ihre eigenen Workflow -Aktivitäten zu erstellen, die Fähigkeit, MSBuild in den Prozess zu injizieren und externe Prozesse auszuführen. Der Workflow -Charakter des Builds ermöglicht unbegrenzte Flexibilität, kann jedoch einige Arbeit erfordern, um diese Flexibilität zu erreichen. Geteilt[22] Open Source -Projekte wurden begonnen, um Community -unterstützte Aktivitäten aufzubauen, um die Fähigkeiten des Teambaus zu verbessern.

Der Build -Prozess kann für verschiedene Arten von Builds konfiguriert werden, einschließlich geplanter Builds, kontinuierliche Integration, Gated Check-in und Rolling Builds. In einem Gated Check-In-Build wird Code abgelegt, den ein Entwickler einprüft, ein "neuestes" im Servercode ausführt und einen Build ausführt. Wenn der Build erfolgreich ist, wird der Code im Namen des Entwicklers überprüft, der den Code eingereicht hat. Wenn der Build fehlschlägt, wird der Entwickler benachrichtigt und kann den Code beheben, bevor er einen anderen Check-in ausprobiert.

Builds haben Retention -Richtlinien mit ihnen, damit sie sich nicht ansammeln, wenn sie nicht benötigt werden (oder Builds können angewiesen werden, keine gespeicherte Ausgabe zu produzieren) oder die Build -Ausgabe für immer gespart werden kann. Neu bei TFS 2013 ist die Möglichkeit, die Build -Ergebnisse in die Quellvertretung einzuchecken. Dies war eine notwendige Verbesserung, um automatisierte Builds in den Azure DevOps -Diensten zu unterstützen, bei denen es keinen Rückgangsort gibt, um die Builds zu platzieren. In der On-Premises-Versions-Build-Ausgabe kann so konfiguriert werden, dass sie an einem beliebigen Standort für freigegebene Ordner landen.

Der Bauprozess in Azure DevOps ist auch Teil des Rückverfolgbarkeitsmechanismus in diesem Team Build vereint viele der Artefakte, die in Azure Devops erstellt und gespeichert werden. Unter der Annahme, dass Entwickler den Quellcode mit Arbeitselementen beim Check -in assoziieren, kann Team Build die Änderungen in jedem Build melden - sowohl Änderungen des Quellcode -Codes als auch für Arbeitselemente sowie Testergebnisse (dies schließt ein Unit -Tests Ergebnisse sowie automatisierte Funktionstests (Codedui)). Als Fehler und Pbis Die Arbeitselemente, die diese Artefakte verfolgen, werden automatisch aktualisiert, um anzuzeigen, in welchem ​​Build sie erfolgreich integriert wurden. In Kombination mit den Testwerkzeugen erhalten Tester eine integrierte Ansicht darüber, welcher Code in jedem Build geändert wurde, aber auch welche Fehler. Pbis und andere Arbeiten änderten sich von Build zu Build.

Zunächst hat Microsoft in TFS 2015 und mit Visual Studio Team Services (VSTS) die Architektur neu erfunden, damit die Build-Engine auf einer plattformartigen, freundlichen Node.JS-Anwendung basiert. Derzeit werden Windows-, Mac- und Linux -Build -Agenten unterstützt. Azure DevOps bietet elastische Build -Funktionen über das Aufbau von Hosting in Microsoft Azure.[23]

Release management

Mitte 2013 kaufte Microsoft ein Produkt namens Inrelease von Incycle Software.[24] InRelease wurde vollständig in die Team Foundation Server 2013 eingebaut. Diese Funktion ergänzte die automatisierten Build- und Testprozesse, indem er ein echtes Ermöglichung erlaubte kontinuierliche Bereitstellung Lösung. Die Tools wurden "Release Management" für TFS 2013 umbenannt Windows Workflow Foundation) Driven Freisetzung für Entwicklungs-, Test- und Produktionsumgebungen und bietet Dashboards für die Überwachung des Fortschritts eines oder mehrerer Veröffentlichungen.

Microsoft hat das Release-Management für Visual Studio-Teamdienste wieder aufgebaut und eine lokale Version von TFS mit den neuen Änderungen im Update von 2015 2. Die neue Version des Release-Managements nutzt den Webbrowser als Kunde und stützt sich auf dieselbe Agent-Architektur wie Team Foundation Build . Release Management ermöglicht DevOps Fähigkeiten für Azure DevOps.

Geschichte

Diese erste Version des Team Foundation Server wurde am 17. März 2006 veröffentlicht.[25]

Produktname Bilden Erscheinungsjahr Versionsnummer [26][27]
Team Foundation Server 2005 Auf dem Gelände 2006 8
Team Foundation Server 2008 Auf dem Gelände 2008 9
Team Foundation Server 2010[28] Auf dem Gelände 2010 10
Team Foundation Service Preview Wolke 2012
Team Foundation Server 2012 Auf dem Gelände 2012 11
Visual Studio online[29] Wolke 2013
Team Foundation Server 2013 Auf dem Gelände 2013 12
Team Foundation Server 2015 Auf dem Gelände 2015 14
Visual Studio Team Services Wolke 2015
Team Foundation Server 2017 Auf dem Gelände 2017 15
Team Foundation Server 2018 Auf dem Gelände 2017 16
Azure DevOps Services[30] Wolke 2018
Azure DevOps Server 2019[31] Auf dem Gelände 2019 17
Azure DevOps Server 2020 Auf dem Gelände 2020 18

Siehe auch

Verweise

  1. ^ "Azure DevOps Server 2020". Microsoft Docs. Abgerufen 2021-08-10.
  2. ^ "Anwendungslebenszyklusmanagement mit Visual Studio und Team Foundation Server". Msdn. Microsoft. 2013. Abgerufen 2013-10-15.
  3. ^ "Überall adoptieren Team -Explorer". Msdn. Microsoft. Abgerufen 26. Mai 2017.
  4. ^ "Neue Release 'Cadence' beginnt mit Visual Studio 2012 Update 2". 1105 Medien. 2013. Abgerufen 2013-10-15.
  5. ^ "Verfügbarkeitsverbesserungen (Datenbank -Engine)". Microsoft. 2012. Abgerufen 2013-10-17.
  6. ^ "Team Foundation Server Architecture". Microsoft. 2012. Abgerufen 2013-10-17.
  7. ^ "Setzen Sie Warnungen, werden Sie benachrichtigt, wenn Änderungen auftreten". Microsoft. 2013. Abgerufen 2013-10-17.
  8. ^ "So erstellen Sie einen Adapter". Microsoft. 2008. Abgerufen 2013-10-17.
  9. ^ "Microsoft Visual Studio Team Foundation Server 2012 MSSCCI -Anbieter". Microsoft. 2012. Abgerufen 2013-10-17.
  10. ^ "Feedback anfordern und überprüfen". Microsoft. 2012. Abgerufen 2013-10-17.
  11. ^ "Wie man TFS 2010 -Arbeitselemente und Workflows anpassen". Ted Gustaf. 2010. Abgerufen 2013-10-17.
  12. ^ "Microsoft Visual Studio Team Foundation Server 2013 Elektrowerkzeuge". Microsoft. 2013. Abgerufen 2013-10-17.
  13. ^ "Team Foundation Version Control (TFVC)". Azure DevOps. Microsoft Docs. Abgerufen 2019-09-23.
  14. ^ "Server -Arbeitsbereiche gegenüber lokalen Arbeitsbereichen". Phil Kelley. 2013. Abgerufen 2013-10-17.
  15. ^ "Wie man: den Team Foundation -Proxy installieren und eine Remote -Site einrichten". Microsoft. 2013. Abgerufen 2013-10-17.
  16. ^ "Support" Team Foundation Version Control (TFVC) ". Azure Repos -Erweiterung für Visual Studio Code. GitHub. Abgerufen 2019-09-23.
  17. ^ "Github libgit2/libgit2". Github. 2013. Abgerufen 2013-10-31.
  18. ^ "Egit". Finsternis. 2013. Abgerufen 2013-10-31.
  19. ^ "Komponenten des TFS Data Warehouse". Microsoft. 2013. Abgerufen 2013-10-17.
  20. ^ "Perspektiven und Messgruppen, die im Analysedienste Cube für Teamsystem bereitgestellt werden". Microsoft. 2013. Abgerufen 2013-10-17.
  21. ^ "Team Foundation Build -Aktivitäten". Microsoft. 2013. Abgerufen 2013-10-17.
  22. ^ "Community -TFs bauen Erweiterungen". Codeplex. 2013. Abgerufen 2013-10-17.
  23. ^ "Microsoft Azure - Portal". Microsoft. 2016. Abgerufen 2016-05-17.
  24. ^ "Microsoft erwirbt Inrelease und fügt Visual Studio, Team Foundation Server, kontinuierliche Bereitstellung hinzu.". Das nächste Web. 2013. Abgerufen 2013-11-15.
  25. ^ Taft, Darryl K. (16. März 2006). "Microsoft kündigt die Veröffentlichung des Team Foundation Servers an". Entwicklung. Eweek. Ziff Davis. Abgerufen 2019-10-13.
  26. ^ Kexugit. "Welche Version des Team Foundation Server habe ich?". docs.microsoft.com. Abgerufen 2020-08-26.
  27. ^ "Azure DevOps verfügen über Zeitachse". docs.microsoft.com. Abgerufen 2021-02-15.
  28. ^ "Microsoft enthüllt die nächste Version von Visual Studio und .NET Framework". Unternehmens Nachrichten. Microsoft. 29. September 2008. Abgerufen 2019-10-13.
  29. ^ Bright, Peter (12. November 2013). "Microsoft nimmt die Entwicklung mit Visual Studio online in die Cloud.". Informationstechnologie. ARS Technica. Conde nast. Abgerufen 2019-10-13.
  30. ^ Cool, Jamie (10. September 2018). "Einführung von Azure DevOps". Blog. Microsoft Azure. Microsoft. Abgerufen 2019-10-13.
  31. ^ Mackie, Kurt (5. März 2019). "Jetzt verfügbar: Azure DevOps Server 2019". Blog. Microsoft Azure. Microsoft. Abgerufen 2019-10-13.

Externe Links