Wat is Azure Artifacts?
In deze les krijgt u een kort overzicht van hoe u Azure Artifacts kunt gebruiken om veilig pakketten te maken en beheren die uw apps kunnen gebruiken.
Laten we teruggaan met het team terwijl ze bepalen of Azure Artifacts de juiste manier is om hun .NET-pakket te hosten.
Mara: Het lijkt me logisch dat we het nieuwe modelpakket hosten in Azure Artifacts. We maken allemaal deel uit van de Microsoft Azure DevOps-organisatie, dus verificatie zou eenvoudiger zijn dan het instellen ervan op een ander pakketbeheer.
Andy: heb ik daar voor de vergadering naar gekeken en het lijkt me heel eenvoudig. Ik ben het met Mara eens.
Amita: Wat zijn Azure Artifacts?
Andy: Azure Artifacts is een opslagplaats in uw Azure DevOps-organisatie waar u de afhankelijkheden voor uw codebasis kunt beheren. Azure Artifacts kan uw artefacten en binaire bestanden opslaan. Het biedt een container, een feedgenoemd, voor groepen afhankelijkheden. Ontwikkelaars die toegang hebben tot de feed, kunnen eenvoudig pakketten gebruiken of publiceren.
Hoe maak ik een pakket en gebruik dit in de pijplijn?
Tim: Dus, als ik het goed begrijp, maakt de app-code al gebruik van pakketten van NuGet. We gaan ons eigen pakket maken en hosten in Azure Artifacts. Kun je de stukken tekenen en hoe ze samenwerken? Ik vind het moeilijk om me het hele proces voor te stellen.
Andy: Zeker. Laten we het proces van het maken van een pakket doorlopen en dit gebruiken in onze Azure DevOps-pijplijn.
Andy gaat naar het whiteboard.
Het pakket maken
Eerst moeten we een project maken in Azure Artifacts.
We kunnen dit doen vanuit Azure DevOps.
Vervolgens maken we een pijplijn in Azure Pipelines die verbinding maakt met de GitHub-opslagplaats voor de pakketcode. Vervolgens bouwt de pijplijn de code, verpakt deze en pusht het pakket naar Azure Artifacts. 
We moeten de app bijwerken die dit pakket gebruikt om te verwijzen naar de Azure Artifacts-feed die we hebben gemaakt. 
Daarna werken we de pijplijn bij waarmee onze app wordt gemaakt. Met de update kunnen we onze Azure Artifacts-feed gebruiken om de nieuwe pakketafhankelijkheid op te halen en als normaal te bouwen. 
Het pakket bijwerken
Tim: Wat als iemand het pakket bijwerkt?
Andy: Wanneer u het pakket bijwerkt met een nieuwe functie of foutoplossing en tests uitvoert om ervoor te zorgen dat het correct werkt, verhoogt u het versienummer van het pakket. Voer vervolgens de wijziging door. De pakketpijplijn ziet de doorvoer en maakt een nieuw artefact in Azure Artifacts met het nieuwe versienummer. Maak u geen zorgen, het oude pakket met het lagere versienummer is er nog steeds voor apps die afhankelijk zijn van die versie. Daarom haalt u een pakket meestal niet van de lijst.
Onze app kan deze nieuwere versie van het pakket gebruiken. In dat geval werken we de app bij om te verwijzen naar de nieuwere versie en voeren we de tests lokaal uit om ervoor te zorgen dat deze nieuwe versie met onze app werkt. Wanneer we tevreden zijn dat alles werkt, verzenden we de app-wijziging naar de pijplijn. Het bouwt met de nieuwe versie van de pakketafhankelijkheid.
Amita: Dit klinkt als een goed plan en het zal het andere team ook helpen. De code blijft ook van afdrijven, terwijl u deze plaatst. Dat zal ook QA helpen.
Een versiebeheerstrategie opnemen in uw build-pijplijn
Wanneer u een build-pijplijn gebruikt, hebben pakketten versies nodig voordat ze kunnen worden gebruikt en getest. Maar pas nadat u het pakket hebt getest, kunt u de kwaliteit ervan kennen. Omdat pakketversies nooit mogen worden gewijzigd, wordt het lastig om vooraf een bepaalde versie te kiezen.
Azure Artifacts koppelt een kwaliteitsniveau aan elk pakket in de feeds en maakt onderscheid tussen voorlopige versies en releaseversies. Azure Artifacts biedt verschillende weergaven van de lijst met pakketten en hun versies, waarbij ze worden gescheiden op basis van hun kwaliteitsniveau. Deze benadering werkt goed met semantische versiebeheer, wat handig is voor het voorspellen van de intentie van een bepaalde versie. Azure Artifacts maakt ook gebruik van een descriptor om extra metagegevens uit de Azure Artifacts-feed op te nemen. Een veelvoorkomend gebruik van weergaven is het delen van pakketversies die zijn getest, gevalideerd of geïmplementeerd, terwijl pakketten die nog in ontwikkeling zijn, worden achtergehouden en nog niet klaar zijn voor openbaar gebruik.
Feeds in Azure Artifacts hebben standaard drie verschillende weergaven. Deze weergaven worden toegevoegd op het moment dat er een nieuwe feed wordt gemaakt. De drie weergaven zijn:
- Release: de weergave @release bevat alle pakketten die als officiële releases worden beschouwd.
- Prerelease-: de weergave @prerelease bevat alle pakketten met een label in hun versienummer.
- Lokale: de weergave @local bevat alle release- en voorlopige pakketten en de pakketten die zijn gedownload uit upstream-bronnen.
U kunt weergaven gebruiken om gebruikers van pakketfeeds te helpen filteren tussen uitgebrachte en niet-uitgebrachte versies van pakketten. Met “views” kan een consument in feite een bewuste keuze maken uit vrijgegeven pakketten of ervoor kiezen om voor prereleases van een bepaald kwaliteitsniveau te kiezen.
Pakketbeveiliging in Azure Artifacts
Het waarborgen van de beveiliging van uw pakketten is net zo belangrijk als de beveiliging van de rest van uw code. Een aspect van pakketbeveiliging is het beveiligen van de toegang tot de pakketfeeds (waarbij een feed, in Azure Artifacts, is waar u pakketten opslaat). Als u machtigingen voor de feed instelt, kunt u uw pakketten delen met zo veel of zo weinig personen als uw scenario vereist.
Feedmachtigingen
Feeds hebben vier toegangsniveaus: Eigenaren, Inzenders, Samenwerkers en Lezers. Elk toegangsniveau heeft een bepaalde set machtigingen. Eigenaren kunnen bijvoorbeeld elk type identiteit (personen, teams en groepen) toevoegen aan elk toegangsniveau. De buildservice voor projectverzamelingen is standaard een samenwerker en uw projectteam is een lezer.
De pijplijn configureren voor toegang tot beveiligings- en licentieclassificaties
Er zijn verschillende hulpprogramma's van derden beschikbaar om u te helpen bij het beoordelen van de beveiligings- en licentieclassificatie van de softwarepakketten die u gebruikt.
Sommige van deze hulpprogramma's scannen de pakketten terwijl ze worden opgenomen in de bouw- of CD-pijplijn. Tijdens het buildproces scant het hulpprogramma de pakketten en geeft het onmiddellijk feedback. Tijdens het CD-proces gebruikt het hulpprogramma de buildartefacten en voert het scans uit. Twee voorbeelden van dergelijke gereedschappen zijn Mend Bolt en Black Duck. Met Azure DevOps gebruikt u buildtaken om scannen in uw pijplijn op te nemen.