Dela via

YAML-förbättringar i Azure Pipelines – Sprint 142-uppdatering

  • Artikel

I Sprint 142-uppdateringen av Azure DevOps har det gjorts flera förbättringar av YAML, till exempel att lägga till anpassade räknare i dina versioner, ange grenar för att skapa för pull-begäranden och använda mallar infogade. Vi har också aktiverat den nya navigeringen för alla användare, introducerat ett mörkt tema och förbättrat funktionerna för länkning och bifogade filer i Azure Boards.

Mer information finns i listan Funktioner nedan.

Funktioner

Allmänt:

Azure Boards:

Azure-lagringsplatser:

Azure Pipelines:

Azure-testplaner:

Azure Artifacts:

Wiki:

Administration:

Allmänt

Ny navigering är aktiverad för alla användare

Vi har aktiverat vår nya navigering för alla användare! Detta är en viktig milstolpe i lanseringen av vår nya produktdesign. Medan vi flyttar alla till den nya navigeringsmodellen med den här versionen kommer användarna fortfarande att kunna välja bort och använda den gamla navigeringen fram till den 16 januari 2019. Du kan välja bort genom att välja förhandsgranskningsfunktioner från menyn under din avatar längst upp till höger på varje sida.

Mer information finns i blogginlägget om navigeringsuppdatering .

Mörkt tema

En av våra långvariga funktionsförfrågningar har varit att erbjuda ett mörkt tema. Vi är glada att meddela dig att detta nu är tillgängligt som en del av den nya navigeringen. Du kan aktivera mörkt tema genom att välja Tema på menyn under din avatar längst upp till höger på varje sida.

Mörkt tema

Azure-tavlor

Organisera referensmaterial med mer omfattande bifogade arbetsobjekt

Genom att koppla filer till arbetsobjekt kan du och ditt team centralisera referensmaterial så att de alltid är nära när du behöver dem. Nu är det enklare att lägga till en ny bifogad fil genom att helt enkelt dra och släppa filen var som helst i arbetsobjektsformuläret. Du kan fortsätta att visa de bifogade filerna som en lista eller växla till en rutnätsvy för att visa en miniatyrförhandsgranskning. Dubbelklicka på filen för att öppna en förhandsgranskning och bläddra igenom dem för att snabbt hitta den information du behöver.

Bifogade filer för arbetsobjekt

Hantera beroenden genom att länka arbetsobjekt mellan dina organisationer

Genom att länka relaterat eller beroende arbete får du en bredare kontext till det arbete som du spårar och hjälper dig att hantera beroenden med andra team. Med länkar för distansarbete kan du nu hålla reda på arbetet i olika organisationer inom företaget. Kopiera bara URL:en för ett befintligt arbetsobjekt, gå till ett annat arbetsobjekt och skapa en länk med någon av de tre nya länktyperna: Förbrukar från, Genererar för och Fjärrrelaterad. Mer information om spårning i Azure Boards finns i dokumentationen för länkning av arbetsobjekt .

Anteckning

Behörigheter respekteras i båda Azure DevOps-organisationerna, som båda måste backas upp av samma Azure AD klientorganisation.

Fjärrlänk

När du börjar hantera flera beroenden använder du det nya fältet Antal fjärrlänkar i Frågor för att lista arbetsobjekt som har fjärrberoenden i projektet, eller överväg att installera dependency tracker-tillägget . Det här tillägget, som skapades av Windows-gruppen på Microsoft för att uppfylla deras skalningsbehov, bygger på fjärrlänkar för att visa en omfattande hierarki och grafisk representation av dina beroenden.

Tidigare gick det inte att öppna ett arbetsobjekt från sökresultatsidan om förhandsgranskningsfönstret för arbetsobjektet var inaktiverat. Detta skulle göra det svårt att gräva i sökresultaten. Nu kan du klicka på arbetsobjektets rubrik för att öppna arbetsobjekten i ett modalt fönster. Den här funktionen har prioriterats från UserVoice.

Azure-lagringsplatser

Tilläggsförfattare kan fråga efter kontext om den aktuella lagringsplatsen

En av utmaningarna för en författare av ett versionskontrolltillägg är att få kontexten för lagringsplatsen som visas för användaren, till exempel namn, ID och URL. För att hjälpa till med detta har vi lagt till VersionControlRepositoryService som en tilläggstillgänglig tjänst. Med detta kan en tilläggsförfattare fråga efter information om den aktuella Git-lagringsplatskontexten i webbgränssnittet. Den har för närvarande en metod, getCurrentGitRepository().

  • Om en Git-lagringsplats väljs returneras ett GitRepository-objekt med grundläggande data om lagringsplatsen (namn, ID och URL)
  • Om en TFVC-lagringsplats har valts eller om tjänsten nås utanför Azure Repos-sidorna returneras null.

Här är ett exempeltillägg som använder den här tjänsten.

Azure-pipelines

Lägga till anpassade byggräknare i dina byggen

Build-räknare är ett sätt att unikt numrera och märka versioner. Tidigare kunde du använda specialvariabeln $(rev:r) för att åstadkomma detta. Nu kan du definiera egna räknarvariabler i byggdefinitionen som ökas automatiskt varje gång du kör en version. Det gör du på variabelfliken i en definition. Den här nya funktionen ger dig mer kraft på följande sätt:

  • Du kan definiera en anpassad räknare och ange dess startvärde. Du kan till exempel starta räknaren på 100. $(rev:r) börjar alltid vid 0.
  • Du kan använda din egen anpassade logik för att återställa en räknare. $(rev:r) är knutet till generering av versionsnummer och återställs automatiskt när det finns ett nytt prefix i versionsnumret.
  • Du kan definiera flera räknare per definition.
  • Du kan fråga efter värdet för en räknare utanför en version. Du kan till exempel räkna antalet versioner som har körts sedan den senaste återställningen med hjälp av en räknare.

Mer information om byggräknare finns i dokumentationen om användardefinierade variabler .

Använd YAML för att ange grenar som ska skapas för pull-begäranden

YAML-pipelines kan ange vilka grenar som ska skapas för pull-begäranden (pull-begäranden). Du kan välja grenar att inkludera och exkludera. Den här möjligheten var tidigare tillgänglig i webbgränssnittet. Genom att flytta den till YAML-filen blir den en del av ditt config-as-code-arbetsflöde.

Ett exempel på hur du använder PR-utlösare kan se ut så här:

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

steps:
- script: echo My PR build!

Använda YAML-malluttryck infogade

YAML-mallar är ett kraftfullt sätt att återanvända delar av pipelines. Förutom att ta hänsyn till vanlig kod kan du med malluttryck ändra värden och styra vad YAML ingår i. Fram till nu måste ett malluttryck uppta hela värdet i ett YAML-uttryck. Det här exemplet fungerar eftersom uttrycket är hela värdet för lösningsegenskapen.

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

Nu har vi lättat på begränsningen och tillåter infogade mallar som du ser i exemplet nedan.

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

Förbättra felsökningen med pipelinens initieringslogg

När en pipeline körs måste Azure Pipelines se till att pipelinedefinitionen är korrekt, bestämma vilka jobb som ska schemaläggas, begära att agenter kör jobben med mera. Hittills har den här processen varit helt ogenomskinlig, så när saker gick fel var det nästan omöjligt för en kund att felsöka problemet. Vi introducerar en ny typ av logg, som kallas pipelinens initieringslogg, som gör informationen synlig. Du kan komma åt pipelinens initieringslogg genom att välja alternativet Ladda ned alla loggar i en färdig version.

Standardkvarhållning för YAML-pipelines

Vi arbetar på ett sätt för användare att konfigurera kvarhållningsprinciper för YAML-pipelines. Tills den nya funktionen är tillgänglig har vi ökat standardkvarhållningen för alla YAML-versioner till 30 dagar eftersom många användare vill behålla sina versioner längre än vår tidigare standardkvarhållning på 10 dagar. Vi tog bort kvarhållningsfliken i redigeraren för YAML-pipelines tills den nya modellen är på plats.

Skapa på Linux-/ARM- och Windows 32-bitarsplattformar

Azure Pipelines-öppen källkod, plattformsoberoende agent har alltid stötts på 64-bitars (x64) Windows, macOS och Linux. Den här sprinten introducerar två nya plattformar som stöds: Linux/ARM och Windows/32-bitars. Dessa nya plattformar ger dig möjlighet att bygga vidare på mindre vanliga, men inte mindre viktiga, plattformar som Raspberry Pi, en Linux/ARM-dator.

Klona variabelgrupper

Vi har lagt till stöd för kloning av variabelgrupper. När du vill replikera en variabelgrupp och bara uppdatera några av variablerna behöver du inte gå igenom den omständliga processen att lägga till variabler en i taget. Nu kan du snabbt göra en kopia av din variabelgrupp, uppdatera värdena på rätt sätt och spara dem som en ny variabelgrupp.

Klona variabelgrupp

Anteckning

Värdena för den hemliga variabeln kopieras inte över när du klonar en variabelgrupp. Du måste uppdatera de krypterade variablerna och sedan spara den klonade variabelgruppen.

Se incheckningar och arbetsobjekt för alla länkade källor

Vi fortsätter vårt engagemang för förbättrad spårbarhet och är glada att kunna meddela att kunderna nu kan se inchecknings- och arbetsobjektsinformationen för alla artefakter som är länkade till pipelinen. Som standard jämförs inchecknings- och arbetsobjektet med den senaste distributionen i samma fas. Du kan dock jämföra med andra tidigare distributioner om det behövs.

Länkade källor

Kör från paket som stöds i Azure App Service distributioner

Azure App Service Distribuera uppgiftsversion (4.*) stöder nu RunFromPackage (kallades tidigare RunFromZip.

App Service stöder ett antal olika tekniker för att distribuera dina filer, till exempel msdeploy (även kallat WebDeploy), git, ARM med mera. Men alla dessa tekniker har en begränsning. Filerna distribueras under mappen wwwroot (specifikt d:\home\site\wwwroot) och körningen kör sedan filerna därifrån.

Med Kör från-paketet finns det inte längre något distributionssteg som kopierar de enskilda filerna till wwwroot. I stället pekar du bara på en zip-fil och zip-filen monteras på wwwroot som ett skrivskyddat filsystem. Detta har flera fördelar:

  • Minskar risken för problem med filkopieringslåsning.
  • Kan distribueras till en produktionsapp (med omstart).
  • Du kan vara säker på vilka filer som körs i din app.
  • Förbättrar prestandan för Azure App Service distributioner.
  • Kan minska kalla starttider, särskilt för JavaScript-funktioner med stora npm-paketträd.

Distribuera Linux-containrar med appserverdistributionsaktiviteten

4.*-versionen av Azure App Service Deploy-uppgiften stöder nu distribution av din egen anpassade container till Azure Functions på Linux.

Linux-värdmodellen för Azure Functions baseras på Docker-containrar som ger större flexibilitet när det gäller paketering och användning av appspecifika beroenden. Funktioner i Linux kan finnas i två olika lägen:

  1. Inbyggd containeravbildning: Du tar med funktionsappkoden och Azure tillhandahåller och hanterar containern (inbyggt avbildningsläge), så ingen specifik Docker-relaterad kunskap krävs. Detta stöds i den befintliga versionen av App Service Deploy-uppgift.
  2. Anpassad containeravbildning: Vi har förbättrat uppgiften App Service Distribuera för att stödja distribution av anpassade containeravbildningar till Azure Functions i Linux. När dina funktioner behöver en specifik språkversion eller kräver ett specifikt beroende eller en konfiguration som inte finns i den inbyggda avbildningen kan du skapa och distribuera en anpassad avbildning till Azure Function i Linux med hjälp av Azure Pipelines.

Azure-testningsplaner

Azure Test Runner-klienten för att köra manuella tester för skrivbordsprogram

Nu kan du använda Azure Test Runner-klienten (ATR) för att köra manuella tester för skrivbordsprogram. Detta hjälper dig att flytta från Microsoft Test Manager till Azure Test Plans. Läs vår vägledning här. Med ATR-klienten kan du köra dina manuella tester och registrera testresultaten för varje teststeg. Du har också funktioner för datainsamling, till exempel skärmbild, bildåtgärdslogg och ljudvideoinspelning. Om du hittar ett problem när du testar använder du Test Runner för att skapa en bugg med teststeg, skärmbilder och kommentarer som automatiskt ingår i buggen.

ATR kräver en engångsnedladdning och installation av löparen. Välj Kör för skrivbordsprogram enligt nedan.

Azure Test Runner

Installera Azure Test Runner

Azure Artifacts

Offentlig förhandsversion av pipelineartefakter

Vi släpper en offentlig förhandsversion av Pipeline Artifacts, en ny mycket skalbar artefakttyp som är utformad för användning med Azure Pipelines. Pipelineartefakter baseras på samma teknik som används av den nyligen tillkännagivna universalpaketfunktionen och kan avsevärt minska den tid det tar att lagra byggutdata för stora företagsklassversioner.

Wiki

Publicera kod som wiki med Contribute-behörigheter

Tidigare kunde endast användare med behörigheten Skapa lagringsplats på en git-lagringsplats publicera kod som wiki. Detta gjorde lagringsplatsens administratörer eller skapare till en flaskhals för alla begäranden om att publicera Markdown-filer som finns i git-lagringsplatser som wikis. Nu kan du publicera kod som wiki om du bara har behörigheten Bidra på kodlagringsplatsen.

Administration

PAT:erna framtvingar CAP

I februari 2017 tillkännagav vi stöd för Azure Active Directory Conditional Access Policy (CAP), men det fanns en begränsning att alternativa autentiseringsmekanismer, till exempel personliga åtkomsttoken, inte skulle tillämpa CAP. Vi är glada att kunna meddela att vi har fyllt denna lucka och Azure DevOps kommer nu att följa CAP IP-fäktningsprinciper när du använder PATs, SSH-nycklar, alternativa autentiseringsuppgifter och OAuth. Administratörer behöver inte göra något för att dra nytta av den här funktionen. Den tillämpas automatiskt för alla befintliga principer.

Nästa steg

Anteckning

Dessa funktioner kommer att lanseras under de kommande två till tre veckorna.

Läs om de nya funktionerna nedan och gå till Azure DevOps för att prova dem själv.

Gå till Azure DevOps

Så här ger du feedback

Vi vill gärna höra vad du tycker om dessa funktioner. Använd feedbackmenyn för att rapportera ett problem eller ge ett förslag.

Ge ett förslag

Du kan också få råd och dina frågor som besvaras av communityn på Stack Overflow.

Tack,

Aaron Björk