Mehrere Anforderungen vom Entwicklercommunity

Als Reaktion auf Ihr Feedback haben wir mehrere Features priorisiert, die Sie im Entwicklercommunity angefordert haben. In Pipelines wurde unterstützung für die Zeichenfolgenteilungsfunktion im YAML-Ausdruck hinzugefügt. Darüber hinaus können Sie jetzt die Anzeige der letzten Commitnachricht für eine Pipelineausführung deaktivieren. In Übermittlungsplänen haben wir das Teamlimit von 15 auf 20 erhöht.

Weitere Informationen finden Sie in den Versionshinweisen.

Azure Boards

• Erhöhen des Teamlimits für Übermittlungspläne von 15 auf 20
• Fehler beim Melden von Arbeitselementverknüpfungs-API behoben
• Fehlerbehebungen für neue Boards-Hubs

Azure Pipelines

• Deaktivieren der Anzeige der letzten Commitnachricht für eine Pipelineausführung
• Verbrauchte Ressourcen und Vorlagenparameter in der Rest-API für Pipelinesausführungen
• Hinzufügen von Unterstützung für die Zeichenfolgenaufteilungsfunktion in YAML-Vorlagenausdrücken
• Keine Synchronisierung von Tags beim Abrufen eines Git-Repositorys
• Brownoutzeitplan für Ubuntu 18.04-Images aktualisiert

Azure Boards

Erhöhen des Teamlimits für Übermittlungspläne von 15 auf 20

Mit Übermittlungsplänen können Sie mehrere Backlogs und mehrere Teams in Ihrem organization anzeigen. Zuvor konnten Sie 15 Teambacklogs anzeigen, einschließlich einer Mischung aus Backlogs und Teams aus verschiedenen Projekten. In diesem Sprint haben wir die Höchstgrenze von 15 auf 20 erhöht.

Fehler beim Melden von Arbeitselementverknüpfungs-API behoben

Es wurde ein Fehler in der Berichtsarbeitselementlinks-Get-API behoben, um den richtigen remoteUrl-Wert für System.LinkTypes.Remote.Related Linktypen zurückzugeben. Vor diesem Fix haben wir den falschen organization Namen und eine fehlende Projekt-ID zurückgegeben.

Fehlerbehebungen für neue Boards-Hubs

In diesem Sprint haben wir mehrere Fehler für new Boards Hub behoben. Eine Liste der Fehlerbehebungen finden Sie im Blogbeitrag New Boards Hub, Sprint 209 update.

Azure Pipelines

Deaktivieren der Anzeige der letzten Commitnachricht für eine Pipelineausführung

Zuvor wurde die Pipelines-Benutzeroberfläche verwendet, um die letzte Commitmeldung beim Anzeigen der Ausführung einer Pipeline anzuzeigen.

Diese Meldung kann beispielsweise verwirrend sein, wenn sich der Code Ihrer YAML-Pipeline in einem anderen Repository befindet als in dem, das den erstellten Code enthält. Wir haben Ihr Feedback von der Entwicklercommunity um eine Möglichkeit gebeten, das Anfügen der neuesten Commitnachricht an den Titel jeder Pipelineausführung zu aktivieren/deaktivieren.

Mit diesem Update haben wir eine neue YAML-Eigenschaft namens appendCommitMessageToRunNamehinzugefügt, mit der Sie genau dies tun können. Standardmäßig ist die -Eigenschaft auf truefestgelegt. Wenn Sie es auf falsefestlegen, zeigt die Pipelineausführung nur den BuildNumberan.

Verbrauchte Ressourcen und Vorlagenparameter in der Rest-API für Pipelinesausführungen

Die REST-API für erweiterte Pipelineausführungen gibt jetzt weitere Arten von Artefakten zurück, die von einer Pipelineausführung verwendet werden, und die Parameter, die zum Auslösen dieser Ausführung verwendet werden. Wir haben die API verbessert, um die container Ressourcen und pipeline und die Vorlagenparameter zurückzugeben, die in einer Pipelineausführung verwendet werden. Sie können jetzt beispielsweise Konformitätsprüfungen schreiben, die die Repositorys, Container und andere Pipelineausführungen einer Pipeline auswerten.

Hier sehen Sie ein Beispiel für den neuen Antworttext.

"resources":
{
    "repositories":
    {
        "self":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        },
        "MyFirstProject":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        }
    },
    "pipelines":
    {
        "SourcePipelineResource":
        {
            "pipeline":
            {
                "url": "https://dev.azure.com/fabrikam/20317ad0-ae49-4588-ae92-6263028b4d83/_apis/pipelines/51?revision=3",
                "id": 51,
                "revision": 3,
                "name": "SourcePipeline",
                "folder": "\\source"
            },
            "version": "20220801.1"
        }
    },
    "containers":
    {
        "windowscontainer":
        {
            "container":
            {
                "environment":
                {
                    "Test": "test"
                },
                "mapDockerSocket": false,
                "image": "mcr.microsoft.com/windows/servercore:ltsc2019",
                "options": "-e 'another_test=tst'",
                "volumes":
                [
                    "C:\\Users\\fabrikamuser\\mount-fabrikam:c:\\mount-fabrikam"
                ],
                "ports":
                [
                    "8080:80",
                    "6379"
                ]
            }
        }
    }
},
"templateParameters":
{
    "includeTemplateSteps": "True"
}

Hinzufügen von Unterstützung für die Zeichenfolgenaufteilungsfunktion in YAML-Vorlagenausdrücken

YAML-Pipelines bieten praktische Möglichkeiten, codeduplizieren zu können, z. B. das Durchlaufen each des Werts einer Liste oder Eigenschaft eines Objekts.

Manchmal wird der Satz von Elementen, durch die durchlaufen werden soll, als Zeichenfolge dargestellt. Beispielsweise, wenn die Liste der Umgebungen, in die bereitgestellt werden soll, durch die Zeichenfolge integration1, integration2definiert wird.

Als wir Ihr Feedback vom Entwicklercommunity gehört haben, haben wir gehört, dass Sie eine Zeichenfolgenfunktion split in YAML-Vorlagenausdrücken wünschen.

Nun können split Sie eine Zeichenfolge durchlaufen und ihre Teilzeichenfolgen durchlaufen each .

variables:
  environments: integration1, integration2

jobs:
  - job: Deploy
    steps:
    - ${{ each env in split(variables.environments, ', ') }}:
      - script: ./deploy.sh -e ${{ env }}
      - script: ./runTest.sh -e ${{ env }}

Keine Synchronisierung von Tags beim Abrufen eines Git-Repositorys

Der Auschecktask verwendet --tags die Option zum Abrufen des Inhalts eines Git-Repositorys. Dies bewirkt, dass der Server alle Tags und alle Objekte abruft, auf die von diesen Tags verwiesen wird. Dies erhöht die Zeit zum Ausführen der Aufgabe in einer Pipeline – insbesondere, wenn Sie über ein großes Repository mit einer Reihe von Tags verfügen. Darüber hinaus synchronisiert der Auschecktask Tags, auch wenn Sie die Option für den flachen Abruf aktivieren, wodurch ihr Zweck möglicherweise verfehlt wird. Um die Menge der aus einem Git-Repository abgerufenen oder abgerufenen Daten zu reduzieren, haben wir der Aufgabe jetzt eine neue Option hinzugefügt, um das Verhalten von Synchronisierungstags zu steuern. Diese Option ist sowohl in klassischen als auch in YAML-Pipelines verfügbar.

YAML

Dieses Verhalten kann entweder über die YAML-Datei oder über die Benutzeroberfläche gesteuert werden.

Um die Synchronisierung der Tags über die YAML-Datei zu deaktivieren, fügen Sie dem Auscheckschritt hinzu fetchTags: false . Wenn die fetchTags Option nicht angegeben wird, entspricht sie dem, wenn fetchTags: true sie verwendet wird.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchTags: boolean # whether to sync the tags
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: boolean | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Wenn Sie das Verhalten vorhandener YAML-Pipelines ändern möchten, ist es möglicherweise bequemer, diese Option auf der Benutzeroberfläche festzulegen, anstatt die YAML-Datei zu aktualisieren. Um zur Benutzeroberfläche zu navigieren, öffnen Sie den YAML-Editor für die Pipeline, wählen Sie Trigger, dann Verarbeiten und dann den Schritt Auschecken aus.

Wenn Sie diese Einstellung sowohl in der YAML-Datei als auch auf der Benutzeroberfläche angeben, hat der in der YAML-Datei angegebene Wert Vorrang.

Klassisch

Um die Synchronisierung der Tags zu deaktivieren, deaktivieren Sie das Kontrollkästchen Tags synchronisieren im Schritt Quellen abrufen.

Für alle neuen Pipelines, die Sie erstellen (YAML oder Classic), werden Tags weiterhin standardmäßig synchronisiert. Diese Option ändert nicht das Verhalten vorhandener Pipelines. Tags werden in diesen Pipelines weiterhin synchronisiert, es sei denn, Sie ändern die Option explizit wie oben beschrieben.

Brownoutzeitplan für Ubuntu 18.04-Images aktualisiert

Azure Pipelines veraltet das Ubuntu 18.04-Image (ubuntu-18.04) in unseren gehosteten Pools. Dieses Bild wird am 1. Dezember eingestellt. Möglicherweise werden längere Warteschlangenzeiten angezeigt.

Damit Sie besser identifizieren können, welche Pipelines das Ubuntu-18.04-Image verwenden, planen wir Brownouts. Aufträge schlagen während eines Brownout-Zeitraums fehl.

• Warnmeldungen werden bei Pipelineausführungen mit dem Ubuntu-18.04-Image angezeigt.
• Ein Skript ist verfügbar, um Pipelines mithilfe veralteter Images zu finden, einschließlich ubuntu-18.04
• Wir planen kurze "Brownouts". Alle Ubuntu-18.04-Ausführungen schlagen während des Brownout-Zeitraums fehl. Daher wird empfohlen, Ihre Pipelines vor den Brownouts zu migrieren.

Brownoutzeitplan (aktualisiert)

• 3. Oktober, 12:00 Uhr UTC - 3. Oktober, 14:00 Uhr UTC
• 18. Oktober, 14:00 Uhr UTC - 18. Oktober, 16:00 Uhr UTC
• 15. November, 18:00 Uhr UTC - 15. November, 20:00 Uhr UTC
• 30. November, 20:00 UHR UTC - 30. November, 22:00 Uhr UTC
• 15. Dezember, 20:00 UHR UTC - 16. Dezember 00:00 UHR UTC
• 5. Januar, 10.00 UHR UTC - 5. Januar 14.00 Uhr UTC
• 13. Januar, 12.00 UHR UTC - 13. Januar 16.00 Uhr UTC
• 18. Januar, 14.00 UHR UTC - 18. Januar 18.00 Uhr UTC
• 24. Januar, 16.00 UTC - 24. Januar 20.00 UTC
• 1. Februar, 18.00 UHR UTC - 1. Februar 22.00 UHR UTC
• 7. Februar, 16.00 UTC - 7. Februar 22.00 UHR UTC
• 13. Februar, 14.00 UTC - 13. Februar 22.00 UTC
• 21. Februar, 10.00 UTC - 21. Februar 22.00 UTC
• 28. Februar, 10.00 UTC - 28. Februar 22.00 UTC
• 6. März, 00.00 UHR UTC - 7. März 00.00 Uhr UTC
• 13. März, 00.00 UHR UTC - 14. März 00.00 UHR UTC
• 21. März, 00.00 UTC - 22. März 00.00 UHR UTC

Nächste Schritte

Hinweis

Diese Features werden in den nächsten zwei bis drei Wochen eingeführt.

Wechseln Sie zu Azure DevOps, und sehen Sie sich an.

Navigieren Sie zu Azure DevOps.

Senden von Feedback

Wir würden uns freuen zu hören, was Sie über diese Features denken. Verwenden Sie das Hilfemenü, 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,

Aaron Hallberg