Vereinfachen der Anpassung durch Migrieren von Projekten zum Vererbungsprozessmodell – VSTS Sprint 139 Update
Im Sprint 139 Update of Visual Studio Team Services (VSTS) können Sie jetzt gehostete XML-Projekte zum Vererbungsprozessmodell migrieren, um die Anpassung zu vereinfachen. Außerdem können Ihre Releases jetzt durch einen PR ausgelöst werden , um Sie bei der Durchführung zusätzlicher Tests vor einer Zusammenführung zu unterstützen.
Weitere Informationen finden Sie weiter unten in der Liste Features .
Nächste Schritte
Lesen Sie unten mehr über die neuen Features, und wechseln Sie zu VSTS, um sie selbst auszuprobieren.
Features
Wiki:
Arbeit:
- Vereinfachen der Anpassung durch Migrieren von Projekten zum Vererbungsprozessmodell
- Chatten Sie über die neuesten status mithilfe der verbesserten Microsoft Teams-Integration
Code:
Build und Release:
- Ausführen zusätzlicher Tests mithilfe eines Pull Request-Releasetriggers
- Bereitstellen von Go-Apps in Azure Kubernetes Service (AKS) mithilfe von Azure DevOps-Projekten
Wiki
Erstellen eines Inhaltsverzeichnisses für Wiki-Seiten
Manchmal können Wiki-Seiten lang werden, wobei Inhalte in mehreren Überschriften organisiert sind. Jetzt können Sie jeder Seite, die mindestens eine Überschrift enthält, mithilfe der [[_TOC_]]
Syntax ein Inhaltsverzeichnis hinzufügen. Weitere Informationen zur Verwendung von Markdown in VSTS finden Sie in der Markdown-Dokumentation . Dieses Feature wurde basierend auf einem Vorschlag von UserVoice priorisiert.
Work
Vereinfachen der Anpassung durch Migrieren von Projekten zum Vererbungsprozessmodell
Die Migration eines gehosteten XML-Prozessmodells zu einem geerbten Prozess bietet den Komfort, Ihr Arbeitsnachverfolgungssystem über die Benutzeroberfläche anzupassen. Wenn Sie das Hosted XML-Prozessmodell in einem Ihrer Projekte verwenden, können Sie diese jetzt migrieren. Das Ändern des Prozessmodells für ein Projekt kann in zwei Schritten erfolgen. Klonen Sie zunächst den gehosteten XML-Prozess in das Vererbungsmodell. Dadurch werden Ihre Anpassungen, z. B. Arbeitselementtypen, Felder und Zustände, einem neu erstellten geerbten Prozess hinzugefügt.
Nachdem Sie den Prozess überprüft haben, können Sie projekte ändern, um den neu erstellten Prozess zu verwenden.
Weitere Informationen finden Sie in der Dokumentation Klonen eines gehosteten XML-Prozesses zur Vererbung .
Chatten Sie über die neuesten status mithilfe der verbesserten Microsoft Teams-Integration
In der neuesten Verbesserung unserer Microsoft Teams-Integration sehen Sie jetzt schnell die status einer Aktivität mit klaren Symbolen und Farben und beginnen mit dem Chatten, um die Dinge in Bewegung zu halten. Wenn ein Pull Request auf den Autor wartet, wird er gelb und mit einem Timersymbol angezeigt. Wenn ein Build erfolgreich war, wird er grün und mit einem Häkchensymbol angezeigt.
Code
Standardisieren von Pull Request-Beschreibungen mithilfe von Vorlagen
Das Schreiben guter Pull Request-Beschreibungen ist eine hervorragende Möglichkeit, um Reviewern zu vermitteln, was sie beim Code Review erwarten können. Sie sind auch eine hervorragende Möglichkeit, dinge nachzuverfolgen, die für jede Änderung durchgeführt werden sollten, z. B. Testen, Hinzufügen von Komponententests und Aktualisieren der Dokumentation (niemand vergisst jemals, die Dokumentation zu aktualisieren). Viele von Ihnen haben angefordert, dass wir Pull Request-Vorlagen hinzufügen, um Teams das Schreiben großartiger Beschreibungen zu erleichtern, und wir haben dieses Feature jetzt hinzugefügt.
Zusätzlich zur Unterstützung einer standardmäßigen PR-Beschreibungsvorlage können Teams mehrere Vorlagen hinzufügen, die Ihnen in einem Menü auf der Seite PR erstellen angezeigt werden. Klicken Sie einfach auf die Schaltfläche Vorlage hinzufügen , um aus einer beliebigen Vorlage im Repository auszuwählen, um sie an die PR-Beschreibung anzufügen.
Branchspezifische Vorlagen werden auch unterstützt, wenn Sie eine andere Vorlage für einen PR auf einen bestimmten Branch oder Branchordner anwenden möchten. Wenn Sie beispielsweise eine Vorlage speziell für alle Branches verwenden möchten, die mit "hotfix/" beginnen, können Sie eine Vorlage hinzufügen, die für alle PRs verwendet wird.
Weitere Informationen zum Erstellen und Verwenden von Vorlagen finden Sie in der Dokumentation zu Pull Request-Vorlagen .
Build und Release
Ausführen zusätzlicher Tests mithilfe eines Pull Request-Releasetriggers
Sie können einen Build basierend auf einem Pull Request (PR) auslösen und dieses schnelle Feedback vor einer Zusammenführung erhalten. Jetzt können Sie auch einen PR-Trigger für ein Release konfigurieren. Die status des Release wird zurück in das Coderepository gepostet und kann direkt auf der PR-Seite angezeigt werden. Dies ist hilfreich, wenn Sie zusätzliche funktionale oder manuelle Tests als Teil Ihres PR-Workflows durchführen möchten.
Bereitstellen von Go-Apps in Azure Kubernetes Service (AKS) mithilfe von Azure DevOps-Projekten
DevOps Projects erleichtert den Einstieg in Azure. Es hilft Ihnen, eine Anwendung im Azure-Dienst Ihrer Wahl in wenigen Schritten zu starten. DevOps Projects bietet alles, was Sie zum Entwickeln, Bereitstellen und Überwachen Ihrer App benötigen.
Wir haben jetzt Unterstützung für Azure Kubernetes Service (AKS) für Go Language in DevOps-Projekten hinzugefügt. Weitere Informationen finden Sie in der Tutorialdokumentation für AKS .
Die an GitHub gemeldete Build-status ist prägnanter.
Wenn VSTS die status eines Builds auf GitHub veröffentlicht, wird der status Text in der zugeordneten Commit-, Branch- und Pull Request-Überprüfung angezeigt. Bisher war dem Namen jeder Buildpipeline im Text vorangestellt VSTS:
. Wir haben dieses Vorwort aus dem status Text entfernt, sodass der Name der Buildpipeline mit einem Blick leichter zu erkennen ist und keine Verwirrung darüber VSTS:
verursacht, dass er im offiziellen Namen einer Buildpipeline enthalten ist. Leider wirkt sich diese Änderung auf GitHub-Branchschutzregeln aus, bei denen GitHub weiterhin erwartet, dass Pipelinenamen mit VSTS:
beginnen. Dies kann dazu führen, dass GitHub-Pull Requests blockiert werden, bis die Repositoryeinstellungen aktualisiert werden. Um dies zu beheben, aktualisieren Sie nach mindestens einmal ausgeführtem Build die Branchschutzregeln Ihres Repositorys unter Repositoryeinstellungen > Branch-Branchschutzregeln > .
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 zu machen.
Sie können auch Rat und Ihre Fragen von der Community auf Stack Overflow beantworten lassen.
Vielen Dank,
Gopinath Chigakkagari