Vad är Azure Artifacts?

Slutförd

I den här lektionen får du en kort översikt över hur du kan använda Azure Artifacts för att på ett säkert sätt skapa och hantera paket som dina appar kan använda.

Låt oss återkoppla med teamet när de bestämmer om Azure Artifacts är det lämpliga sättet att vara värd för deras .NET-paket.

Mara: Det verkar mig som om det vore vettigt för oss att vara värd för det nya modellpaketet i Azure Artifacts. Vi är redan en del av Microsoft Azure DevOps-organisationen, så autentiseringen skulle vara enklare än att försöka konfigurera den på en annan pakethanterare.

Andy: jag tittade på det före mötet och det verkar enkelt för mig. Jag håller med Mara.

Amita: Vad är Azure Artifacts?

Andy: Azure Artifacts är en lagringsplats i din Azure DevOps-organisation där du kan hantera beroenden för din kodbas. Azure Artifacts kan lagra artefakter och binärfiler. Den tillhandahåller en container som kallas feedför grupper av beroenden. Utvecklare som har åtkomst till feeden kan enkelt använda eller publicera paket.

Hur skapar jag ett paket och använder det i pipelinen?

Tim: Så om jag förstår rätt använder appkoden redan paket från NuGet. Vi ska skapa ett eget paket och vara värd för det i Azure Artifacts. Kan du rita bitarna och hur de ska fungera tillsammans? Jag har svårt att föreställa mig hela processen.

Andy: Visst. Nu ska vi gå över processen med att skapa ett paket och använda det i vår Azure DevOps-pipeline.

Andy flyttar sig till whiteboarden.

Bild av ett whiteboard-diagram som visar stegen för att skapa och använda ett paket.

Skapa paketet

Först måste vi skapa ett projekt i Azure Artifacts. Vi kan göra detta från Azure DevOps.

Sedan skapar vi en pipeline i Azure Pipelines som ansluter till GitHub-lagringsplatsen för paketkoden. Sedan skapar pipelinen koden, paketerar den och skickar paketet till Azure Artifacts.

Vi måste uppdatera appen som använder det här paketet för att peka på Azure Artifacts-flödet som vi skapade.

Därefter uppdaterar vi pipelinen som skapar vår app. Med uppdateringen kan vi använda vår Azure Artifacts-feed för att hämta det nya paketberoendet och skapa som vanligt.

Uppdatera paketet

Tim: Vad händer om någon uppdaterar paketet?

Andy: När du uppdaterar paketet med en ny funktion eller felkorrigering och kör tester för att se till att det fungerar korrekt ökar du paketets versionsnummer. Genomför sedan ändringen. Paketpipelinen ser incheckningen och skapar en ny artefakt i Azure Artifacts med det nya versionsnumret. Oroa dig inte, det gamla paketet med det lägre versionsnumret finns fortfarande för appar som är beroende av den versionen. Det är därför du vanligtvis inte avlistar ett paket.

Vår app kanske vill använda den här nyare versionen av paketet. I så fall uppdaterar vi appen för att referera till den nyare versionen och kör testerna lokalt för att se till att den nya versionen fungerar med vår app. När vi är nöjda med att allt fungerar skickar vi appändringen till pipelinen. Den bygger med den nya versionen av paketberoendet.

Amita: Detta låter som en bra plan, och det kommer att hjälpa det andra laget också. Det kommer också att hålla koden från som driver, som du uttryckte det. Det kommer också att hjälpa QA.

Inkludera en versionsstrategi i byggpipelinensystemet

När du använder en buildpipeline behöver paket versioner innan de kan användas och testas. Men först när du har testat paketet kan du känna till dess kvalitet. Eftersom paketversioner aldrig bör ändras blir det svårt att välja en viss version i förväg.

Azure Artifacts associerar en kvalitetsnivå med varje paket i sina flöden och skiljer mellan förhandsversioner och släppversioner. Azure Artifacts erbjuder olika vyer i listan över paket och deras versioner, som separerar dem baserat på deras kvalitetsnivå. Den här metoden fungerar bra med semantisk versionshantering, vilket är användbart för att förutsäga avsikten med en viss version. Azure Artifacts använder också en beskrivning för att inkludera ytterligare metadata från Azure Artifacts-flödet. En vanlig användning för vyer är att dela paketversioner som har testats, verifierats eller distribuerats, men som håller tillbaka paket som fortfarande är under utveckling och inte redo för offentlig förbrukning.

Feeds i Azure Artifacts har tre olika vyer som standard. Dessa vyer läggs till när en ny feed skapas. De tre vyerna är:

  • Release: Vyn @release innehåller alla paket som anses vara officiella releaser.
  • Förhandsversion: Vyn @prerelease innehåller alla paket som har en tagg i sitt versionsnummer.
  • Local: Vyn @local innehåller alla versions- och förhandsversionspaket och paket som laddats ned från överordnade källor.

Du kan använda vyer för att hjälpa paketmatare att filtrera mellan utgivna och outgivna versioner av paket. I grund och botten ger vyer konsumenten möjlighet att fatta ett medvetet beslut att välja mellan utgivna paket eller välja att delta i förhandsversioner av en viss kvalitetsnivå.

Paketsäkerhet i Azure Artifacts

Att säkerställa säkerheten för dina paket är lika viktigt som att garantera säkerheten för resten av koden. En aspekt av paketsäkerhet är att skydda åtkomsten till paketflödena (där ett flöde i Azure Artifacts är där du lagrar paket). Om du anger behörigheter för flödet kan du dela dina paket med så många eller så få personer som ditt scenario kräver.

Flödesbehörigheter

Feeds har fyra åtkomstnivåer: Ägare, Deltagare, Medarbetare och Läsare. Varje åtkomstnivå har en viss uppsättning behörigheter. Ägare kan till exempel lägga till alla typer av identiteter – individer, team och grupper – till valfri åtkomstnivå. Som standard är Project Collection Build Service en medarbetare och projektteamet är läsare.

Konfigurera pipelinen för åtkomst till säkerhets- och licensklassificeringar

Det finns flera verktyg från tredje part som hjälper dig att utvärdera säkerhets- och licensklassificeringen för de programvarupaket som du använder.

Vissa av dessa verktyg söker igenom paketen när de inkluderas i byggprocessen eller CD-pipelinen. Under byggprocessen genomsöker verktyget paketen och ger omedelbar feedback. Under CD-processen använder verktyget byggartefakter och utför genomsökningar. Två exempel på sådana verktyg är Mend Bolt och Black Duck. Med Azure DevOps använder du bygguppgifter för att införliva genomsökning i din pipeline.