Vorstellung: Azure DevOps
Der einzige Dienst, der Visual Studio Team Services (VSTS) war, wird nun zu unserem neuen Satz von Azure DevOps Services. In unserer Gesamten Dokumentation, Websites und produktinternen Dokumentation werden Sie neue Symbole und Namen für Azure DevOps sowie alle unsere Dienste in Azure DevOps bemerken.
- Azure Pipelines zum kontinuierlichen Erstellen, Testen und Bereitstellen für jede Plattform und Cloud.
- Azure Boards für leistungsstarke Arbeitsverwaltung.
- Azure Artifacts für Maven-, npm- und NuGet-Paketfeeds .
- Azure Repos für unbegrenzte, in der Cloud gehostete private Git-Repositorys.
- Azure Testpläne für geplante und explorative Tests.
Mit dem Start von Azure Pipelines haben wir eine neue App auf dem GitHub Marketplace eingeführt, eine Reihe von Erfahrungen aktualisiert, die Ihnen bei den ersten Schritten helfen, und bietet unbegrenzte CI/CD-Minuten und 10 parallele Aufträge für Open Source-Projekte.
Weitere Informationen finden Sie in der Nachstehenden Liste der Features .
Features
Azure Pipelines:
- Hinzufügen von Azure-Pipelines aus dem GitHub Marketplace
- Erstellen von Open Source-Projekten mit Azure Pipelines kostenlos
- Konfigurieren von Builds mithilfe von YAML
- Erstellen von YAML-Buildpipelines mithilfe des neuen Assistenten
- Verwalten von Buildpipelines mithilfe der neuen Builds-Seite
- Erstellen von GitHub-Pullanforderungsbuilds
- Neue Buildstatus-Signal-URL
- Nutzen Sie noch mehr Tools auf von Microsoft gehosteten Linux-Agents
- Nachverfolgen von GitHub-Commits und zugehörigen Problemen in Versionen
- Verwalten von Build- und Bereitstellungsabschluss-E-Mails besser mit verbesserter Formatierung
- Folgen der neuen einheitlichen Terminologie von Azure Pipelines
Marketplace:
Verwaltung:
- Wechseln vorhandener Organisationen zur Verwendung der url für den neuen Domänennamen
- Hinzufügen von Stakeholder-Benutzern zum Sparen von Lizenzkosten für Azure Pipelines
Nächste Schritte
Hinweis
Diese Features werden in den nächsten Tagen bereitgestellt.
Lesen Sie die folgenden neuen Features, und fahren Sie mit Azure DevOps Services fort, um sie selbst auszuprobieren.
Azure Pipelines
Hinzufügen von Azure-Pipelines aus dem GitHub Marketplace
Eine neue Azure Pipelines-App im GitHub Marketplace erweitert die Integration mit GitHub-Repositorys und optimiert parallele Auftragskäufe.
Bisher können Sie die kontinuierliche Integration mit GitHub-Repositorys über die OAuth-Authentifizierung aktivieren. Mit OAuth verwendet Azure Pipelines die GitHub-Identität einer Person, um Code abzurufen und den Buildstatus auf GitHub zu aktualisieren. Da sich die Mitglieder Ihres Teams jedoch im Laufe der Zeit ändern können, kann es weniger wünschenswert sein, die GitHub-Identität und -Berechtigungen einer Person zu verwenden. Durch die Installation der Azure Pipelines-App können Sie stattdessen die App zum Ausführen von Aktionen autorisieren.
Wenn Sie die App verwenden, werden buildergebnisse auch im neuen Check-Feature von GitHub mit einer detaillierten Ansicht der Build-, Test- und Codeabdeckungsergebnisse zur Verfügung gestellt.
Um zu beginnen, installieren Sie die App aus dem GitHub Marketplace in Ihrem GitHub-Konto oder Ihrer Organisation. Sie können auch zusätzliche parallele Aufträge mit einem vorhandenen GitHub-Zahlungskonto anstelle eines separaten Azure-Kontos erwerben. Die Preise sind in beiden Richtungen identisch.
Erstellen von Open Source-Projekten mit Azure Pipelines kostenlos
Azure Pipelines bietet in der Cloud gehostete Pipelines für Linux, macOS und Windows mit unbegrenzten Minuten und 10 kostenlosen parallelen Aufträgen für Open Source.
Weitere Informationen finden Sie in der Dokumentation zu öffentlichen Build-Repositorys und parallelen Aufträgen .
Konfigurieren von Builds mithilfe von YAML
Wichtig
Um diese Funktion verwenden zu können, müssen Sie das Vorschaufeature "YAML-Pipelines erstellen" in Ihrer Organisation aktiviert haben.
YaML-basierte Buildpipelines sind jetzt allgemein verfügbar. Automatisieren Sie Ihre fortlaufende Integrationspipeline mithilfe einer YAML-Datei, die zusammen mit dem Rest Ihres Codes in das Repository eingecheckt wurde. Es ist einfach, mit einem Einzelauftragsbuild zu beginnen. Wenn Ihre Anforderungen wachsen, können Sie einfach mithilfe mehrerer Aufträge , externer Vorlagen und Matrixausführung skalieren.
Erstellen von YAML-Buildpipelines mithilfe des neuen Assistenten
Wichtig
Um diese Funktion verwenden zu können, müssen Sie das Vorschaufeature für die Neue YAML-Pipelineerstellung in Ihrem Profil oder Ihrer Organisation aktiviert haben.
Ein neuer Assistent vereinfacht diesen Prozess der Erstellung von YAML-basierten Buildpipelines mit GitHub und Azure Repos. Nachdem Sie ein Repository zum Erstellen ausgewählt haben, wird automatisch eine Pipeline erstellt, wenn sie eine YAML-Datei enthält. Andernfalls analysiert Azure Pipelines Ihr Repository und empfiehlt eine YAML-basierte Vorlage zum Erstellen Ihres Projekts. Klicken Sie einfach auf Speichern und ausführen , um eine Pullanforderung für das vorgeschlagene YAML zu erstellen und den ersten Build auszuführen. Fortlaufende Integration und Pullanforderungstrigger werden automatisch aktiviert.
Verwalten von Buildpipelines mithilfe der neuen Builds-Seite
Wichtig
Um diese Funktion verwenden zu können, müssen Sie das Feature "Hubvorschau für neue Builds" in Ihrem Profil oder Ihrer Organisation aktiviert haben.
Wir führen mehrere Verbesserungen durch und führen eine neue Version der Builds-Seite aus. Diese neue Version kombiniert das Verzeichnis aller Buildpipelinen und die Liste der aktuellen Builds, sodass Sie schnell in den Builds Ihres Projekts navigieren können, um deren Status anzuzeigen. Außerdem enthält sie eine Vorschau der Testanalysen für die ausgewählte Pipeline.
Erstellen von GitHub-Pullanforderungsbuilds
Wenn Sie eine Pull-Anforderung an Ihr GitHub-Repository übermitteln, kann der Pull-Anforderungsbuild aufgrund eines zeitweiligen Fehlers fehlschlagen, z. B. aufgrund eines nicht verfügbaren Paketregistrierungs oder eines flackernden Tests. In diesen Fällen möchten Sie den Build ein weiteres Mal ausführen. Dies erfordert derzeit, dass Sie ein weiteres künstliches Update an die Pull-Anforderung übertragen. Jetzt können Sie auf der neuen Builds-Seite einfach den fehlgeschlagenen Build auswählen und einen anderen erstellen.
Diese Geste zum Neuerstellen steht nur für Pull-Anforderungsbuilds zur Verfügung, mit der begonnen werden kann. Wir sind dabei, ein ähnliches Feature für alle fehlgeschlagenen Builds verfügbar zu machen.
Neue Buildstatus-Signal-URL
Build badges embedded into the homepage of a repository are a common way to show the health of the repository. Wir haben neue URLs hinzugefügt, mit denen Sie Build-Badges erstellen können. Mit den neuen URLs können Benutzer einen Verzweigungsstatus veröffentlichen und Benutzer zum neuesten Build der ausgewählten Verzweigung bringen. Sie können die Markdown-URL für die neue Statussignal-URL abrufen, indem Sie auf der Seite "Builds" die Menüaktion "Statussignal" auswählen. Aus Gründen der Abwärtskompatibilität berücksichtigen wir weiterhin die älteren Build-Badge-URLs.
Nutzen Sie noch mehr Tools auf von Microsoft gehosteten Linux-Agents
In diesem Update wurden mehrere Build-, Test- und Bereitstellungstools den von Microsoft gehosteten Linux-Agents hinzugefügt, wodurch die Notwendigkeit entfernt wird, sie während eines Builds oder einer Veröffentlichung selbst zu installieren.
- Erlang/OTP
- Firefox
- Haskell
- Heroku CLI
- ImageMagick
- Mercurial
- Microsoft SQL Server-Clienttools
- MySQL Server
- PhantomJS
- Bestäuben
- PyPy2 und PyPy3
- Infoleiste
- rsync
- ShellCheck
- Sphinx
- Terraform
- Xvfb
Nachverfolgen von GitHub-Commits und zugehörigen Problemen in Versionen
Die Kenntnis der Änderungen, die mit einer Version bereitgestellt werden, ist wichtig, um Verbesserungen an der App nachzuverfolgen. Jetzt können Sie die Liste der in GitHub-Repositorys vorgenommenen Commits und die zugehörigen GitHub-Probleme abrufen, die mit einer Version bereitgestellt werden.
Verwalten von Build- und Bereitstellungsabschluss-E-Mails besser mit verbesserter Formatierung
Build- und Bereitstellungsabschluss-E-Mails wurden aktualisiert, um nach E-Mail-Regeln besser zu filtern. Jetzt enthält die Betreffzeile relevantere Informationen auf einen Blick, der Textkörper enthält weitere Details, und ihre Formatierung wurde mit der neuesten Marke aktualisiert.
Elemente des neuen Formats sind:
[Build result] [pipeline name] - [repository:branch] - [project name] - [commit]
[Deployment result] [pipeline name] > [release name] : [stage name]
Hier sind einige Beispiele:
[Build succeeded] IdentityService.CI - MyRepo:master - MyProject - d3b90b80
[Deployment succeeded] New release pipeline > NotificationSpecialRelease-1 : Stage 1
Folgen der neuen einheitlichen Terminologie von Azure Pipelines
In allen Builds und Versionen wurden unterschiedliche Begriffe historisch für ähnliche Konzepte verwendet. In anderen Fällen waren Die Bedeutungen von Begriffen vage. Geben Sie beispielsweise den Unterschied zwischen einem Agentpool und einer Agentwarteschlange an.
Terminologie wurde in Azure Pipelines vereinheitlicht, um ihre Konzepte zu verdeutlichen. Nun werden die folgenden einheitlichen Begriffe angezeigt:
Vorheriger Begriff | Einheitlicher Ausdruck | Bedeutung |
---|---|---|
Gehosteter Agent | Von Microsoft gehosteter Agent | Ein Build-/Release-Agent, der auf von Microsoft verwalteten cloudgehosteten Infrastruktur ausgeführt wird. |
Privater Agent | Selbstgehosteter Agent | Ein Build-/Release-Agent, der auf einem computer ausgeführt wird, der von Ihnen bereitgestellt und verwaltet wird. |
Agentpool | Agentpool | Eine Gruppe von Agentcomputern auf Organisationsebene, die Builds oder Versionen ausführen können. |
Agent-Warteschlange | Agentpool | Eine Gruppe von Agentcomputern auf Projektebene, die Builds oder Versionen ausführen können. Sie ist mit einem Agentpool auf Organisationsebene verknüpft. |
Builddefinition | Buildpipeline | Eine End-to-End-Gruppe von Buildschritten für eine Anwendung. |
Entwickeln | Entwickeln | Eine Instanz einer Buildpipeline, die ausgeführt wird oder ausgeführt wird. |
Phase | Job | Eine Reihe von Aufgaben, die sequenziell oder parallel auf einem Agent ausgeführt werden. Eine Build- oder Releasepipeline kann einen Auftrag oder ein Diagramm mehrerer Aufträge enthalten. |
Releasedefinition | Releasepipeline | Eine End-to-End-Gruppe von Veröffentlichungsschritten für eine Anwendung, die über verschiedene Stufen hinweg bereitgestellt werden soll. |
Freigabe | Freigabe | Eine Instanz einer Releasepipeline, die ausgeführt wird oder ausgeführt wird. |
Environment | Phase | Eine logische und unabhängige Entität, die angibt, wo Sie eine aus einer Releasepipeline generierte Version bereitstellen möchten. |
Gleichzeitiger Auftrag/Pipeline | Paralleler Auftrag | Ein paralleler Auftrag bietet Ihnen die Möglichkeit, einen einzelnen Build- oder Releaseauftrag gleichzeitig in Ihrer Organisation auszuführen. Mit mehr parallelen Aufträgen können Sie gleichzeitig weitere Build- und Releaseaufträge ausführen. |
Dienstendpunkt | Dienstverbindung | Eine Gruppe von Einstellungen, z. B. Anmeldeinformationen, die zum Herstellen einer Verbindung mit externen Diensten verwendet werden, um Aufgaben in einem Build oder release auszuführen. |
Weitere Informationen finden Sie in der Dokumentation zu Konzepten .
Marketplace
Nutzen der neuesten Erweiterungskategorien
Als Erweiterungsmitwirkender werden Sie feststellen, dass Erweiterungskategorien an die umbenannten Azure DevOps Services im Marketplace angepasst wurden. Obwohl die vorherigen Kategorien automatisch den neuen zugeordnet wurden, empfehlen wir, zu den neuen Kategorien zu wechseln, indem Sie das Manifest Ihrer Erweiterung aktualisieren. Weitere Informationen finden Sie in der Manifestdokumentation .
Verwaltung
Wechseln vorhandener Organisationen zur Verwendung der url für den neuen Domänennamen
Obwohl wir als URL für neue Organisationen in den neuen dev.azure.com
Domänennamen verschoben haben, können Sie wie gewohnt weiterhin auf Ihre Organisation zugreifen visualstudio.com
. Wenn Sie Ihre URL so ändern möchten, dass sie darauf basiert dev.azure.com
, kann ein Organisationsadministrator (Project Collection Administrator) dies von der Seite mit den Organisationseinstellungen ändern. Obwohl die Übernahme des neuen Domänennamens nicht jede Anforderung umleitet, ändert sich jede Anforderung an die Stamm-URL der Organisation und Links von vielen E-Mail- und webbasierten Links.
Wir werden den Umstieg auf die neue URL schrittweise basierend auf Kundenfeedback vornehmen. Sie beginnt als Opt-In, und später werden wir sie als Standard für Organisationen festlegen. Wir müssen noch eine Zeitachse festlegen, um Organisationen bewusst von der visualstudio.com
Domäne wegzubewegen.
Wichtig
Um sicherzustellen, dass Ihre Organisation mit vorhandenen Firewall- oder IP-Einschränkungen funktioniert, stellen Sie sicher, dass die entsprechenden Domänennamen und IP-Adressen zulässig sind. Weitere Informationen finden Sie in diesem Abschnitt zur Agent-F&A.
Hinzufügen von Stakeholder-Benutzern zum Sparen von Lizenzkosten für Azure Pipelines
Wichtig
Um diese Funktion zu verwenden, müssen Sie über den kostenlosen Zugriff auf Pipelines für projektbeteiligte Vorschaufeatures in Ihrer Organisation verfügen.
Gute Nachrichten! Wenn Sie nur den Azure Pipelines-Dienst verwenden, müssen Sie nicht mehr über Standardlizenzen für Benutzer bezahlen. Alle Features von Azure Pipelines stehen allen Benutzern kostenlos zur Verfügung. Wenn Sie Ihrem Projekt weitere Benutzer hinzufügen, können sie kostenlos als Projektbeteiligte bleiben, und sie können Pipelines erstellen, anzeigen, aktualisieren und genehmigen, sofern sie über die entsprechenden Berechtigungen verfügen. Hier sind einige zusätzliche Hinweise zu dieser Lizenzierungsänderung:
- Sie zahlen nur für zusätzliche parallele Aufträge in Azure Pipelines. Benutzer sind unbegrenzt.
- Der gesamte Zugriff auf Azure Pipelines-Features wird weiterhin durch ein Sicherheits- und Berechtigungsmodell gesteuert.
- Wenn Sie andere Azure DevOps Services verwenden, müssen Sie nach den kostenlosen Grenzwerten weiterhin eine Lizenz pro Benutzer für diese Dienste bezahlen.
- In vorhandenen Organisationen erhalten Projektbeteiligte nicht standardmäßig den kostenlosen Vorteil von Azure-Pipelines. Ihr Organisationsadministrator (Project Collection Administrator) muss dieses Vorschaufeature explizit aktivieren. Wenn Sie dieses Vorschaufeature aktivieren, ändert sich das Verhalten der Projektbeteiligten. Derzeit können sie Keine Builds oder Versionen verwalten. Sobald das Vorschaufeature aktiviert ist, gibt es jedoch keinen Unterschied zwischen grundlegenden Benutzern und Projektbeteiligten in Azure-Pipelines. Aus diesem Grund bleibt die Wahl, den Projektbeteiligten die Möglichkeit zu geben, als kostenlose Azure Pipelines-Benutzer behandelt zu werden, ihrem Administrator überlassen.
Weitere Informationen finden Sie in der Dokumentation zur Bereitstellung von Projektbeteiligten zum Bearbeiten von Build- und Releasepipelines .
Senden von Feedback
Wir würden uns freuen zu hören, was Sie zu diesen Features halten. Verwenden Sie das Feedbackmenü, um ein Problem zu melden oder einen Vorschlag bereitzustellen.
Sie können auch Ratschläge und Ihre Fragen von der Community in Stack Overflow beantworten lassen.
Vielen Dank,
Jeremy Epling