Qu’est-ce qu’Azure Artifacts ?
Dans cette unité, vous voyez brièvement comment utiliser Azure Artifacts pour créer et gérer de manière sécurisée des packages que vos applications peuvent consommer.
Voyons la décision de l’équipe pour déterminer si Azure Artifacts est la méthode appropriée pour héberger son package .NET.
Mara : Il me semble qu’il serait judicieux d’héberger le nouveau package Models dans Azure Artifacts. Nous faisons déjà tous partie de l’organisation Microsoft Azure DevOps. L’authentification serait donc plus simple que si nous tentions de la configurer sur un autre gestionnaire de package.
Andy : J’y ai réfléchi avant la réunion et cela me semble logique. Je suis d’accord avec Mara.
Amita : C’est quoi Azure Artifacts ?
Andy : Azure Artifacts est un dépôt dans votre organisation Azure DevOps où vous pouvez gérer les dépendances pour votre base de code. Azure Artifacts peut stocker vos artefacts et vos fichiers binaires. Il fournit un conteneur, appelé flux, pour les groupes de dépendances. Les développeurs qui ont accès au flux peuvent facilement consommer ou publier des packages.
Comment faire pour créer un package et l’utiliser dans le pipeline ?
Tim : Si je comprends bien, le code d’application utilise déjà des packages de NuGet. Nous allons créer notre propre package et l’héberger dans Azure Artifacts. Pouvez-vous dessiner les différents éléments et comment ils fonctionneront ensemble ? J’ai du mal à visualiser l’ensemble du processus.
Andy : Bien sûr. Examinons le processus de création de package et de son utilisation dans notre pipeline Azure DevOps.
Andy se dirige vers le tableau blanc.
Créer le package
Tout d’abord, nous avons besoin de créer un projet dans Azure Artifacts. 
Nous pouvons le faire à partir d’Azure DevOps.
Ensuite, nous allons créer un pipeline dans Azure Pipelines qui se connecte au dépôt GitHub correspondant au code du package, le génère, l’empaquette, puis envoie (push) le package vers Azure Artifacts. 
Nous avons besoin de mettre à jour l’application qui utilise ce package pour qu’elle pointe vers le flux Azure Artifacts que nous avons créé. 
Après cela, nous mettons à jour le pipeline qui crée notre application. Cette mise à jour nous permet d’utiliser notre flux Azure Artifacts pour extraire la nouvelle dépendance de package et générer la build comme d’habitude. 
Mettre à jour le package
Tim : Que se passe-t-il si quelqu’un met à jour le package ?
Andy : Quand vous mettez à jour le package avec une nouvelle fonctionnalité ou une correction de bogue, puis que vous exécutez des tests pour vérifier qu’il fonctionne correctement, augmentez le numéro de version du package. Ensuite, commitez le changement. Le pipeline du package voit le commit et crée un artefact dans Azure Artifacts avec le nouveau numéro de version. Ne vous inquiétez pas, l’ancien package avec le numéro de version inférieur est toujours disponible pour les applications qui dépendent de cette version. C’est pourquoi vous ne retirez généralement pas un package de la liste.
Notre application peut avoir besoin d’utiliser cette version plus récente du package. Dans ce cas, nous mettons à jour l’application pour qu’elle référence la version plus récente et nous exécutons les tests localement pour vérifier que cette nouvelle version fonctionne avec notre application. Quand nous avons pu vérifier que tout fonctionne bien, nous soumettons la modification apportée à l’application au pipeline. La build est générée avec la nouvelle version de la dépendance de package.
Amita : Ce plan me paraît efficace. Il aidera l’autre équipe et cela empêchera également le code de dériver. Cela aidera également le département Assurance qualité.
Ajouter une stratégie de versioning dans votre pipeline de build
Quand vous utilisez un pipeline de build, les packages ont besoin de versions pour pouvoir être consommés et testés. En revanche, c’est seulement une fois que vous avez testé le package que vous pouvez en connaître la qualité. Étant donné que les versions de package ne doivent jamais être modifiées, il est difficile d’en choisir une particulière au préalable.
Azure Artifacts associe un niveau de qualité à chaque package dans ses flux et une distinction entre les préversions et les versions finales. Azure Artifacts propose différentes vues de la liste des packages et de leurs versions, qui les séparent en fonction de leur niveau de qualité. Cette approche fonctionne bien avec la gestion sémantique de version, qui s’avère utile pour prédire l’intention d’une version particulière. Azure Artifacts utilise aussi un descripteur pour inclure des métadonnées supplémentaires issues du flux Azure Artifacts. Une utilisation courante de ces vues a pour but de partager des versions de package qui ont été testées, validées ou déployées, tout en mettant de côté les packages qui sont toujours en cours de développement et ne sont pas prêts pour l’utilisation publique.
Par défaut, les flux dans Azure Artifacts ont trois vues différentes. Ces vues sont ajoutées au moment où un nouveau flux est créé. Les trois vues sont les suivantes :
- Version : la vue @release contient tous les packages considérés comme des versions officielles.
- Préversion : la vue @prerelease contient tous les packages dont le numéro de version comporte une étiquette.
- Local : la vue @local contient tous les packages de versions finales et de préversions, ainsi que les packages téléchargés à partir de sources en amont.
Vous pouvez utiliser des vues pour aider les consommateurs d’un flux de package à filtrer les versions finales et les versions non publiées des packages. En bref, les vues permettent à un consommateur de faire un choix avisé parmi des packages de versions finales ou d’inclure des préversions d’un certain niveau de qualité.
Sécurité des packages dans Azure Artifacts
Garantir la sécurité de vos packages est aussi important que garantir la sécurité du reste de votre code. L’un des aspects de la sécurité des packages a trait à la sécurisation de l’accès à leurs flux (dans Azure Artifacts, un flux est l’emplacement où vous stockez les packages). La définition d’autorisations d’accès à un flux vous permet de partager vos packages avec autant de personnes que nécessaire pour votre scénario.
Autorisations de flux
Les flux ont quatre niveaux d’accès : propriétaires, contributeurs, collaborateurs et lecteurs. Chaque niveau d’accès possède un ensemble d’autorisations. Par exemple, les propriétaires peuvent ajouter le type d’identité de leur choix (individus, équipes et groupes) à tout niveau d’accès. Par défaut, le service de build de la collection de projets est collaborateur et votre équipe de projet est lecteur.
Configurer le pipeline pour accéder aux évaluations de la sécurité et des licences
Il existe plusieurs outils disponibles auprès de tiers pour évaluer la sécurité et les licences des packages logiciels que vous utilisez.
Certains de ces outils analysent les packages au moment où ils sont inclus dans le pipeline de build ou de déploiement continu (CD). Pendant le processus de génération, ils analysent les packages et fournissent des commentaires instantanés. Pendant le processus CD, les outils utilisent les artefacts de build et effectuent des analyses. Mend Bolt et Black Duck sont deux exemples de ce type d’outils. Avec Azure DevOps, vous utilisez des tâches de génération pour incorporer l’analyse dans votre pipeline.