Meerdere aanvragen van de ontwikkelaarscommunity geadresseerd

In reactie op uw feedback hebben we prioriteit gegeven aan meerdere functies die u hebt aangevraagd in de ontwikkelaarscommunity. In Pijplijnen hebben we ondersteuning toegevoegd voor de splitsfunctie in YAML-uitdrukkingen. Daarnaast kunt u nu het tonen van het laatste commitbericht tijdens een pijplijnuitvoering uitschakelen. In Leveringsplannen hebben we de teamlimiet verhoogd van 15 tot 20.

Bekijk de releaseopmerkingen voor meer informatie.

Azure Boards

• Teamlimiet voor leveringsplannen verhogen van 15 tot 20
• Er is een fout opgelost in het rapporteren van werkitemkoppelingen: API ophalen
• Nieuwe Boards Hub-bugfixes

Azure-pipelines

• Schakel het weergeven van het laatste commitbericht voor een pijplijnuitvoering uit
• Verbruikte resources en sjabloonparameters in Pipelines Runs REST API
• Ondersteuning toevoegen voor de functie voor het splitsen van tekenreeksen in YAML-sjabloonexpressies
• Tags niet synchroniseren bij het ophalen van een Git-opslagplaats
• Bijgewerkt brownout-schema voor Ubuntu 18.04-afbeeldingen

Azure Boards

Teamlimiet voor leveringsplannen verhogen van 15 tot 20

Met leveringsplannen kunt u meerdere achterstanden en meerdere teams in uw organisatie bekijken. Voorheen kon u 15 teamachterstanden bekijken, waaronder een combinatie van achterstanden en teams uit verschillende projecten. In deze sprint hebben we de maximumlimiet verhoogd van 15 tot 20.

Er is een fout opgelost in het rapporteren van werkitemkoppelingen: API ophalen

Er is een fout opgelost in de Get-API voor rapportage werkitemlinks om de juiste remoteUrl-waarde voor System.LinkTypes.Remote.Related koppelingstypen te retourneren. Voor deze oplossing hebben we de verkeerde organisatienaam en een ontbrekende project-id geretourneerd.

Nieuwe Boards Hub-bugfixes

In deze sprint hebben we meerdere bugs opgelost voor New Boards Hub. U kunt een lijst met bugfixes bekijken in de blogpost New Boards Hub, Sprint 209 Update.

Azure-pipelines

Schakel het weergeven van het laatste commitbericht voor een pijplijnuitvoering uit

Voorheen werd in de gebruikersinterface van pijplijnen het laatste commitbericht weergegeven bij het tonen van een pijplijnuitvoering.

Dit bericht kan verwarrend zijn, bijvoorbeeld wanneer de code van uw YAML-pijplijn zich in een andere opslagplaats bevindt dan de opslagplaats die de code bevat die het bouwt. We hebben uw feedback van de ontwikkelaarscommunity gehoord waarin u ons vraagt om een manier om het toevoegen van het laatste commitbericht aan de titel van elke pijplijnuitvoering in of uit te schakelen.

Met deze update hebben we een nieuwe YAML-eigenschap toegevoegd met de naam appendCommitMessageToRunName, waarmee u precies dat kunt doen. De eigenschap is standaard ingesteld op true. Wanneer u deze instelt op false, wordt alleen de BuildNumber pipelinerun weergegeven.

Verbruikte resources en sjabloonparameters in de Pipelines Runs Rest API

De uitgebreide Pijplijnuitvoeringen REST API retourneert nu meer typen artefacten die worden gebruikt door een pijplijnuitvoering en de parameters die worden gebruikt om die uitvoering te activeren. We hebben de API verbeterd om de container en pipeline resources en de sjabloonparameters die worden gebruikt in een pijplijnuitvoering te retourneren. U kunt nu bijvoorbeeld nalevingscontroles schrijven die de opslagplaatsen, containers en andere pijplijnuitvoeringen evalueren die door een pijplijn worden gebruikt.

Hier volgt een voorbeeld van de hoofdtekst van het nieuwe antwoord.

"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"
}

Ondersteuning toevoegen voor de functie voor het splitsen van tekenreeksen in YAML-sjabloonexpressies

YAML-pijplijnen bieden handige manieren om codeduplicatie te verminderen, zoals het herhalen each van de waarde van een lijst of eigenschap van een object.

Soms wordt de reeks items om doorheen te itereren als een tekenreeks weergegeven. Wanneer bijvoorbeeld de lijst met omgevingen waarin moet worden geïmplementeerd, wordt gedefinieerd door de tekenreeks integration1, integration2.

Terwijl we naar uw feedback van de Ontwikkelaarscommunity hebben geluisterd, hebben we gehoord dat u een tekenreeksfunctie split in YAML-sjabloonexpressies wilt hebben.

Nu kunt u split een tekenreeks nemen en itereren over each van zijn subtekenreeksen.

variables:
  environments: integration1, integration2

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

Tags niet synchroniseren bij het ophalen van een Git-opslagplaats

De uitchecktaak maakt gebruik --tags van de optie voor het ophalen van de inhoud van een Git-opslagplaats. Dit zorgt ervoor dat de server alle tags en alle objecten ophaalt waarnaar deze tags worden verwezen. Dit verhoogt de tijd voor het uitvoeren van de taak in een pijplijn, met name als u een grote opslagplaats met een aantal tags hebt. Bovendien synchroniseert de kassataak tags zelfs wanneer u de ondiepe ophaaloptie inschakelt, waardoor het doel mogelijk wordt ondermijnd. Om de hoeveelheid gegevens die uit een Git-opslagplaats worden opgehaald of ingeladen te verminderen, hebben we nu een nieuwe optie aan de taak toegevoegd om het beheer van het synchroniseren van tags te regelen. Deze optie is zowel beschikbaar in klassieke als YAML-pijplijnen.

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

Voor alle nieuwe pijplijnen die u maakt (YAML of klassiek), worden tags nog steeds standaard gesynchroniseerd. Met deze optie wordt het gedrag van bestaande pijplijnen niet gewijzigd. Tags worden nog steeds gesynchroniseerd in deze pijplijnen, tenzij u de optie expliciet wijzigt zoals hierboven beschreven.

Bijgewerkt brownout-schema voor Ubuntu 18.04-images

Azure Pipelines schaft de Ubuntu 18.04-image (ubuntu-18.04) op onze gehoste pools af. Deze afbeelding wordt op 1 december buiten gebruik gesteld. Mogelijk ziet u langere wachtrijtijden.

Om u beter te helpen identificeren welke pijplijnen de ubuntu-18.04-image gebruiken, plannen we tijdelijke onderbrekingen. Taken mislukken tijdens een brownoutperiode.

• Waarschuwingen worden weergegeven op pipeline runs met behulp van de ubuntu-18.04-image
• Er is een script beschikbaar om u te helpen pijplijnen te vinden met verouderde afbeeldingen, waaronder ubuntu-18.04.
• We plannen korte brownouts (tijdelijke stroomverminderingen). Elke ubuntu-18.04 uitvoering mislukt tijdens de brownoutperiode. Daarom wordt het aanbevolen om uw pijplijnen vóór de brownouts te migreren.

Brownout-rooster (bijgewerkt)

• 3 oktober 12:00 UTC - 3 oktober 14:00 UTC
• 18 oktober 14:00 UTC - 18 oktober 16:00 UTC
• 15 november 18:00 UTC - 15 november 20:00 UTC
• 30 november 20:00 UTC - 30 november 22:00 UTC
• 15 december 20:00 UTC - 16 december 00:00 UTC
• 5 januari 10,00 UTC - 5 januari 14,00 UTC
• 13 januari 12.00 UTC - 13 januari 16,00 UTC
• 18 januari 14.00 UTC - 18 januari 18,00 UTC
• 24 januari 16.00 UTC - 24 januari 20,00 UTC
• 1 februari 18.00 UTC - 1 februari 22.00 UTC
• 7 februari 16.00 UTC - 7 februari 22.00 UTC
• 13 februari 14.00 UTC - 13 februari 22.00 UTC
• 21 februari 10,00 UTC - 21 februari 22,00 UTC
• 28 februari 10.00 UTC - 28 februari 22.00 UTC
• 6 maart 00,00 UTC - 7 maart 00,00 UTC
• 13 maart 00,00 UTC - 14 maart 00,00 UTC
• 21 maart 00,00 UTC - 22 maart 00,00 UTC

Volgende stappen

Ga naar Azure DevOps en kijk eens.

Feedback geven

We horen graag wat u van deze functies vindt. Gebruik het Help-menu om een probleem te melden of een suggestie op te geven.

U kunt ook advies krijgen en uw vragen beantwoorden door de community op Stack Overflow.

Bedankt

Aaron Hallberg