Delen via

YAML-verbeteringen in Azure Pipelines - Sprint 142 Update

  • Artikel

In de Sprint 142-update van Azure DevOps zijn er verschillende verbeteringen aangebracht in YAML, zoals het toevoegen van aangepaste tellers aan uw builds, het opgeven van vertakkingen die moeten worden gebouwd voor pull-aanvragen en het inline gebruiken van sjablonen. We hebben ook de nieuwe navigatie voor alle gebruikers ingeschakeld, een donker thema geïntroduceerd en de ervaringen voor koppelen en bijlagen in Azure Boards verbeterd.

Bekijk de onderstaande lijst met functies voor meer informatie.

Functies

Algemeen:

Azure Boards:

Azure-opslagplaatsen:

Azure Pipelines:

Azure-testplannen:

Azure Artifacts:

Wiki:

Beheer:

Algemeen

Nieuwe navigatie is ingeschakeld voor alle gebruikers

We hebben onze nieuwe navigatie ingeschakeld voor alle gebruikers. Dit is een belangrijke mijlpaal in de implementatie van ons nieuwe productontwerp. Hoewel we met deze release iedereen naar het nieuwe navigatiemodel verplaatsen, kunnen gebruikers zich nog steeds afmelden en de oude navigatie gebruiken tot 16 januari 2019. U kunt zich afmelden door Preview-functies te selecteren in het menu onder uw avatar in de rechterbovenhoek van elke pagina.

Zie het blogbericht Navigatie-update voor meer informatie.

Donker thema

Een van onze langlopende functieverzoeken is het aanbieden van een donker thema. We zijn blij om u te laten weten dat dit nu beschikbaar is als onderdeel van de nieuwe navigatie. U kunt een donker thema inschakelen door Thema te selecteren in het menu onder uw avatar in de rechterbovenhoek van elke pagina.

Donker thema

Azure Boards

Referentiemateriaal ordenen met uitgebreidere bijlagen voor werkitems

Door bestanden toe te voegen aan werkitems kunnen u en uw team referentiemateriaal centraliseren, zodat ze altijd dichtbij zijn wanneer u ze nodig hebt. Het is nu eenvoudiger om een nieuwe bijlage toe te voegen door het bestand naar een willekeurige plaats in het werkitemformulier te slepen en neer te zetten. U kunt de bijlagen blijven weergeven als een lijst of overschakelen naar een rasterweergave om een miniatuurvoorbeeld weer te geven. Dubbelklik op het bestand om een voorbeeld te openen en door deze te bladeren om snel de informatie te vinden die u nodig hebt.

Werkitembijlagen

Afhankelijkheden beheren door werkitems in uw organisaties te koppelen

Door gerelateerd of afhankelijk werk te koppelen, krijgt u een bredere context in het werk dat u bijhoudt en kunt u afhankelijkheden beheren met andere teams. Met koppelingen voor werken op afstand kunt u nu werk in organisaties binnen uw bedrijf bijhouden. Kopieer de URL van een bestaand werkitem, ga naar een ander werkitem en maak een koppeling met behulp van een van de drie nieuwe koppelingstypen: Verbruikt van, Produceert voor en Extern gerelateerd. Zie de documentatie voor het koppelen van werkitems voor meer informatie over traceerbaarheid in Azure Boards.

Notitie

Machtigingen worden gerespecteerd in beide Azure DevOps-organisaties, die beide moeten worden ondersteund door dezelfde Azure AD tenant.

Externe koppeling

Wanneer u begint met het beheren van verschillende afhankelijkheden, gebruikt u het nieuwe veld Aantal externe koppelingen in Query's om de werkitems weer te geven die externe afhankelijkheden in uw project hebben, of kunt u overwegen de extensie Dependency Tracker te installeren. Deze extensie, die door de Windows-groep bij Microsoft is gemaakt om te voldoen aan hun schaalbehoeften, bouwt voort op externe koppelingen om een uitgebreide hiërarchie en grafische weergave van uw afhankelijkheden weer te geven.

Voorheen kon een werkitem niet worden geopend vanaf de pagina met zoekresultaten als het voorbeeldvenster voor werkitems was uitgeschakeld. Dit zou het moeilijk maken om uw zoekresultaten te bekijken. U kunt nu op de titel van het werkitem klikken om de werkitems in een modaal venster te openen. Deze functie heeft prioriteit gekregen vanuit UserVoice.

Azure-opslagplaatsen

Extensieauteurs kunnen een query uitvoeren op context over de huidige opslagplaats

Een van de uitdagingen voor een auteur van een versiebeheerextensie is het ophalen van de context van de opslagplaats die wordt weergegeven voor de gebruiker, zoals de naam, id en URL. Om u hierbij te helpen, hebben we de VersionControlRepositoryService toegevoegd als een extensie toegankelijke service. Hiermee kan een extensieauteur een query uitvoeren op informatie over de huidige context van de Git-opslagplaats in de webgebruikersinterface. Het heeft momenteel één methode, getCurrentGitRepository().

  • Als een Git-opslagplaats is geselecteerd, wordt een GitRepository-object geretourneerd met basisgegevens over de opslagplaats (naam, id en URL)
  • Als een TFVC-opslagplaats is geselecteerd of als de service wordt geopend buiten de Pagina's met Azure-opslagplaatsen, wordt null geretourneerd.

Hier volgt een voorbeeldextensie die gebruikmaakt van deze service.

Azure Pipelines

Aangepaste buildtellers toevoegen aan uw builds

Buildtellers bieden een manier om builds op unieke wijze te nummeren en labelen. Voorheen kon u hiervoor de speciale variabele $(rev:r) gebruiken. U kunt nu uw eigen tellervariabelen definiëren in uw builddefinitie die automatisch worden verhoogd telkens wanneer u een build uitvoert. U doet dit op het tabblad Variabelen van een definitie. Deze nieuwe functie biedt u meer mogelijkheden op de volgende manieren:

  • U kunt een aangepaste teller definiëren en de seed-waarde instellen. U kunt bijvoorbeeld uw teller starten op 100. $(rev:r) begint altijd bij 0.
  • U kunt uw eigen aangepaste logica gebruiken om een teller opnieuw in te stellen. $(rev:r) is gekoppeld aan het genereren van buildnummers en wordt automatisch opnieuw ingesteld wanneer het buildnummer een nieuw voorvoegsel bevat.
  • U kunt meerdere tellers per definitie definiëren.
  • U kunt een query uitvoeren op de waarde van een teller buiten een build. U kunt bijvoorbeeld het aantal builds tellen dat is uitgevoerd sinds de laatste reset met behulp van een teller.

Zie de documentatie over door de gebruiker gedefinieerde variabelen voor meer informatie over buildtellers.

YAML gebruiken om vertakkingen op te geven die moeten worden gebouwd voor pull-aanvragen

YAML-pijplijnen kunnen opgeven welke vertakkingen moeten worden gebouwd voor PULL's (pull-aanvragen). U kunt vertakkingen kiezen die u wilt opnemen en uitsluiten. Deze mogelijkheid was eerder beschikbaar in de webgebruikersinterface. Door het te verplaatsen naar het YAML-bestand, wordt het onderdeel van de werkstroom config-as-code.

Een voorbeeld van het gebruik van pr-triggers kan er als volgt uitzien:

pr:
  branches:
    include:
    - features/*
    exclude:
    - features/experimental/*
  paths:
    include:
    - **/*.cs

steps:
- script: echo My PR build!

YAML-sjabloonexpressies inline gebruiken

YAML-sjablonen zijn een krachtige manier om onderdelen van pijplijnen opnieuw te gebruiken. Met sjabloonexpressies kunt u niet alleen algemene code instellen, maar ook waarden wijzigen en bepalen welke YAML is opgenomen. Tot nu toe moest een sjabloonexpressie de volledige waarde in een YAML-expressie innemen. Dit voorbeeld werkt omdat de expressie de volledige waarde van de oplossingseigenschap is.

- task: msbuild@1
  inputs:
    solution: ${{ parameters.solution }}

We hebben nu de beperking versoepeld en inlinesjablonen toegestaan, zoals u in het onderstaande voorbeeld ziet.

- script: echo The solution file is ${{ parameters.solution }}

Het oplossen van problemen verbeteren met het initialisatielogboek van de pijplijn

Wanneer een pijplijn wordt uitgevoerd, moet Azure Pipelines ervoor zorgen dat de pijplijndefinitie juist is, bepalen welke taken moeten worden gepland, agents aanvragen om de taken uit te voeren en meer. Tot nu toe was dit proces volledig ondoorzichtig, dus toen er iets misging, was het bijna onmogelijk voor een klant om het probleem op te lossen. We introduceren een nieuw soort logboek, het initialisatielogboek van de pijplijn, waarmee deze details zichtbaar worden. U kunt het initialisatielogboek van de pijplijn openen door de optie Alle logboeken downloaden te kiezen voor een voltooide build.

Standaardretentie voor YAML-pijplijnen

We werken aan een manier voor gebruikers om bewaarbeleid voor YAML-pijplijnen te configureren. Totdat deze nieuwe functie beschikbaar is, hebben we de standaardretentie voor alle YAML-builds verhoogd naar 30 dagen, omdat veel gebruikers hun builds langer willen bewaren dan onze vorige standaardretentie van tien dagen. Het tabblad Retentie in de editor voor YAML-pijplijnen is verwijderd totdat het nieuwe model is geïnstalleerd.

Bouwen op 32-bits Linux-/ARM- en Windows-platforms

De Azure Pipelines open source, platformoverschrijdende agent is altijd ondersteund op 64-bits (x64) Windows, macOS en Linux. In deze sprint introduceren we twee nieuwe ondersteunde platforms: Linux/ARM en Windows/32-bits. Deze nieuwe platforms bieden u de mogelijkheid om te bouwen op minder algemene, maar niet minder belangrijke platforms, zoals de Raspberry Pi, een Linux-/ARM-machine.

Variabelengroepen klonen

We hebben ondersteuning toegevoegd voor het klonen van variabelegroepen. Wanneer u een variabelengroep wilt repliceren en slechts enkele van de variabelen wilt bijwerken, hoeft u het tijdrovende proces van het toevoegen van variabelen niet één voor één te doorlopen. U kunt nu snel een kopie van uw variabelengroep maken, de waarden op de juiste manier bijwerken en deze opslaan als een nieuwe variabelengroep.

Variabelegroep klonen

Notitie

De waarden van de geheime variabele worden niet gekopieerd wanneer u een variabelengroep kloont. U moet de versleutelde variabelen bijwerken en vervolgens de gekloonde variabelengroep opslaan.

Doorvoeringen en werkitems voor alle gekoppelde bronnen bekijken

Door onze inspanningen voor verbeterde traceerbaarheid voort te zetten, kunnen we aankondigen dat klanten nu de details van doorvoeren en werkitems kunnen zien voor alle artefacten die zijn gekoppeld aan de pijplijn. Standaard worden het doorvoer- en werkitem vergeleken met de laatste implementatie in dezelfde fase. U kunt echter zo nodig vergelijken met een andere eerdere implementatie.

Gekoppelde bronnen

Uitvoeren vanuit pakket dat wordt ondersteund in Azure App Service-implementaties

De versie Azure App Service Deploy task (4.*) ondersteunt nu RunFromPackage (voorheen RunFromZip genoemd).

App Service ondersteunt een aantal verschillende technieken voor het implementeren van uw bestanden, zoals msdeploy (ook wel WebDeploy genoemd), git, ARM en meer. Maar al deze technieken hebben een beperking. Uw bestanden worden geïmplementeerd in de map wwwroot (met name d:\home\site\wwwroot) en de runtime voert de bestanden van daaruit uit.

Met Uitvoeren van pakket is er geen implementatiestap meer waarmee de afzonderlijke bestanden naar wwwroot worden gekopieerd. In plaats daarvan wijst u het naar een zip-bestand en wordt de zip gekoppeld aan wwwroot als een alleen-lezen bestandssysteem. Dit heeft verschillende voordelen:

  • Vermindert het risico op problemen met het vergrendelen van bestanden.
  • Kan worden geïmplementeerd in een productie-app (met opnieuw opstarten).
  • U kunt zeker zijn van de bestanden die in uw app worden uitgevoerd.
  • Verbetert de prestaties van Azure App Service implementaties.
  • Kan de koude starttijden verkorten, met name voor JavaScript-functies met grote npm-pakketstructuren.

Linux-containers implementeren met de taak App Server Deploy

De 4.*-versie van de Azure App Service Deploy-taak ondersteunt nu het implementeren van uw eigen aangepaste container in Azure Functions op Linux.

Het Linux-hostingmodel voor Azure Functions is gebaseerd op Docker-containers die meer flexibiliteit bieden bij het verpakken en gebruiken van app-specifieke afhankelijkheden. Functies in Linux kunnen in 2 verschillende modi worden gehost:

  1. Ingebouwde containerinstallatiekopieën: U brengt de code van de functie-app mee en Azure biedt en beheert de container (ingebouwde installatiekopiemodus), zodat er geen specifieke docker-gerelateerde kennis vereist is. Dit wordt ondersteund in de bestaande versie van App Service Taak Implementeren.
  2. Aangepaste containerinstallatiekopieën: We hebben de App Service Deploy-taak uitgebreid om ondersteuning te bieden voor het implementeren van aangepaste containerinstallatiekopieën in Azure Functions op Linux. Wanneer uw functies een specifieke taalversie nodig hebben of een specifieke afhankelijkheid of configuratie vereisen die niet is opgegeven in de ingebouwde installatiekopieën, kunt u een aangepaste installatiekopieën bouwen en implementeren in Azure Function in Linux met behulp van Azure Pipelines.

Azure-testplannen

Azure Test Runner-client voor het uitvoeren van handmatige tests voor bureaubladtoepassingen

U kunt nu de ATR-client (Azure Test Runner) gebruiken om handmatige tests uit te voeren voor bureaubladtoepassingen. Hiermee kunt u overstappen van Microsoft Test Manager naar Azure Test Plans. Raadpleeg onze richtlijnen hier. Met behulp van de ATR-client kunt u handmatige tests uitvoeren en de testresultaten voor elke teststap vastleggen. U hebt ook mogelijkheden voor het verzamelen van gegevens, zoals schermopname, actielogboek voor afbeeldingen en audio-video-opname. Als u een probleem vindt bij het testen, gebruikt u Test Runner om een bug te maken met teststappen, schermopnamen en opmerkingen die automatisch in de fout zijn opgenomen.

ATR vereist een eenmalige download en installatie van de runner. Selecteer Uitvoeren voor bureaubladtoepassing zoals hieronder wordt weergegeven.

Azure Test Runner

Azure Test Runner installeren

Azure-artefacten

Openbare preview van pijplijnartefacten

We brengen een openbare preview van Pijplijnartefacten uit, een nieuw zeer schaalbaar artefacttype dat is ontworpen voor gebruik met Azure Pipelines. Pijplijnartefacten is gebaseerd op dezelfde technologie die wordt gebruikt door de onlangs aangekondigde functie Universal Packages en kan de tijd die nodig is om build-uitvoer op te slaan voor grote builds van enterprise-klasse aanzienlijk verkorten.

Wiki

Code publiceren als wiki met machtigingen voor Bijdragen

Eerder konden alleen gebruikers met de machtiging Opslagplaats maken voor een Git-opslagplaats code publiceren als wiki. Hierdoor waren de beheerders of makers van de opslagplaats een knelpunt voor aanvragen om Markdown-bestanden te publiceren die worden gehost in Git-opslagplaatsen als wiki's. U kunt nu code publiceren als wiki als u alleen de machtiging Bijdragen hebt voor de codeopslagplaats.

Beheer

PAW's dwingen CAP af

In februari 2017 hebben we ondersteuning aangekondigd voor Beleid voor voorwaardelijke toegang van Azure Active Directory (CAP), maar er was een beperking waardoor alternatieve verificatiemechanismen, zoals persoonlijke toegangstokens, cap niet afdwingden. We zijn blij te kunnen aankondigen dat we deze leemte hebben opgevuld en Dat Azure DevOps nu cap IP-fencingbeleid zal volgen bij het gebruik van PAW's, SSH-sleutels, alternatieve verificatiereferenties en OAuth. Beheerders hoeven niets te doen om te profiteren van deze functie. Deze wordt automatisch toegepast op alle bestaande beleidsregels.

Volgende stappen

Notitie

Deze functies worden in de komende twee tot drie weken geïmplementeerd.

Lees meer over de nieuwe functies hieronder en ga naar Azure DevOps om ze zelf uit te proberen.

Ga naar Azure DevOps

Feedback geven

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

Een suggestie doen

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

Met vriendelijke groet,

Aaron Bjork