Récemment, je me suis heurté à une bête encore peu connue dans le monde de DevOps : les pipelines Azure DevOps. J'ai immédiatement ressenti l'absence de directives ou d'articles clairs sur le sujet ; je ne sais pas à quoi cela est dû, mais Microsoft a clairement du travail à faire en matière de vulgarisation de cet outil. Aujourd'hui, nous allons créer un pipeline pour des tests automatisés dans le cloud Azure.

Alors, la tâche :
Nous avons un logiciel qui est construit à l'aide du même Azure DevOps, assemblé à partir d'un projet sur WIX. Si cela vous intéresse, je pourrais également écrire sur cet outil. En fait, c'est une méthode plus optimisée pour automatiser la construction d'installateurs Windows, remplaçant le traditionnel InstallShield. Donc, notre logiciel se construit avec succès et génère un artefact, un certain setup.exe, qui installe l'application dans le système Windows. Il est nécessaire d'installer cette application sur une machine virtuelle ressemblant à la production, de copier les tests automatisés préparés par l'équipe de test, de les exécuter et de récupérer les résultats pour déterminer si la branche est bonne ou mauvaise, avant de fusionner. Tout comme dans GitLab, mais à travers des chemins plus tortueux.

Comme environnement de virtualisation où nous allons exécuter nos tests, nous utilisons évidemment Azure DevTest Labs, une entité dans les abonnements Azure, qui est spécialement conçue pour faire tourner toutes sortes de tests à un coût raisonnable.

1. Intégration côté cloud

Pour commencer, nous devrons intégrer notre DevTest Labs à Azure DevOps, pour cela nous avons besoin d'un Service Principal, qui est en fait un compte de service, permettant aux pipelines d'accéder au cloud et de créer ou supprimer des ressources pour eux-mêmes.

Allons dans l'abonnement et trouvons le service Azure Active Directory.

Nous trouvons les App Registrations et cliquons sur New Registration, ce qui va créer notre service principal. Je ne vais pas détailler les paramètres à choisir lors de la création, car cela peut varier selon les abonnements.

Maintenant, nous devons donner des droits à notre directeur de service. Pour cela, allons dans les abonnements, l'icône avec la clé. Sélectionnons notre abonnement.

Ensuite, dans Access Control, nous cliquons sur Role Assignment et cherchons dans la recherche le nom de ce compte que nous venons de créer. Nous donnons le rôle de Contributor, cela suffit.

Ensuite, retournons à notre Service Principal dans Azure AD et ouvrons ses propriétés. Plus tard, nous aurons besoin de tous les ID qui y figurent, nous les notons.

C'est ainsi que se termine notre configuration du portail, et nous passons à Azure DevOps.

2. Intégration avec Azure DevOps

Tout d'abord, nous allons dans les paramètres du projet et choisissons les connexions de service. Nous créons un nouvel élément de type Azure Resource Manager.

Nous avons besoin de tous les ID que nous avons notés. Nous cliquons sur utiliser la version complète de la boîte de dialogue de connexion de service. Nous entrons toutes les données que nous avons obtenues de Service Principal. Nous cliquons sur vérifier et si tout est bon, nous enregistrons la connexion. Maintenant, nos pipelines peuvent l'utiliser pour se connecter au cloud.

3. Création d'un pipeline

Nous passons maintenant à la partie la plus intéressante, la construction du pipeline proprement dit. Nous ouvrons le menu Pipelines-Builds.

Nous sommes accueillis par le menu de création d'un nouveau build, qui tentera par défaut de créer un fichier YAML avec la configuration appropriée. Nous déclinons poliment cette option et choisissons l'option classique. Nous comprenons le désir de Microsoft de tout faire comme les gens et de permettre une personnalisation maximale des pipelines via YAML, mais la documentation insuffisante et le simple non-fonctionnement pratique de nombreux modules nous indiquent qu'il est encore trop tôt pour utiliser cette fonctionnalité.

Parmi la multitude de templates, nous aurons besoin d'un simple Pipeline vide. Après sa création, nous rencontrons une fenêtre d'édition vide dans laquelle nous passerons beaucoup de temps.

Nous cliquons donc sur + et accédons à un certain magasin de modules, d'où nous aurons besoin d'ajouter les composants suivants.

Avant de commencer à configurer les tâches du pipeline, nous devons créer et placer quelques fichiers dans le projet. Cela inclura le modèle ARM de notre machine virtuelle, que nous générerons dans Azure DevTest Labs, un script pour récupérer l'IP de la machine après sa création et, si vous le souhaitez, des scripts pour nos tests ou ce que nous voulons exécuter sur l'hôte.

4. Génération du modèle ARM

Pour créer la machine virtuelle, nous devrons d'abord générer un modèle pour celle-ci, un fichier JSON que nous placerons dans le code du projet, afin que le pipeline puisse le lire.

Allons dans notre laboratoire et trouvons le menu Formulas (bases réutilisables), puis cliquons sur créer un nouveau.

Nous serons accueillis par une longue liste d'images en tant que base, le choix de la taille de la machine, tout comme lors de la création de la machine virtuelle. À ce stade, nous ne nous arrêterons pas là, mais passerons directement au dernier point des propriétés de la machine, à savoir les artefacts. Vous pouvez utiliser toutes les configurations nécessaires pour votre environnement. Par exemple, j'ajoute la machine à domaine J'ajoute un compte de service en tant qu'administrateur afin que le pipeline puisse accéder à cette machine sous ce compte. Tout cela peut varier, mais pour tester le code avec succès, nous avons besoin d'un artefact sur lequel nous allons nous attarder. Pour installer la dernière version du logiciel que nous testons sur notre machine, nous utiliserons l'artefact « Télécharger l'artefact Azure Pipelines et exécuter le script ». Vous vous rappelez quand je disais qu'un build avec l'installateur de l'application était généré ? Eh bien, maintenant nous devons dire à la machine virtuelle, plus précisément au modèle, de récupérer cet artefact. Et pas seulement le récupérer, mais aussi l'installer, pour cela nous remplissons des champs spécifiques en indiquant le projet, le nom du build et la clé secrète. La clé secrète, comme dans tous les systèmes de ce type, est générée dans le compte, ici dans Azure DevOps, et est enregistrée dans Secrets dans votre laboratoire. À ce sujet, il y a un petit détail : nous allons la conserver dans Secrets, mais ça n'affecte pas le modèle, qui sera exécuté par un autre utilisateur dans le cadre du pipeline. C'est pourquoi nous devrons entrer à nouveau manuellement la clé secrète dans le modèle.

Un autre artefact qui doit absolument être inclus est « Configurer WinRM », car nous en aurons besoin pour un accès ultérieur à la machine. Il n'y a qu'un paramètre, le nom d'hôte. Comme nous ne le connaissons pas à l'avance, nous allons utiliser la variable %COMPUTERNAME%.

Nous avons donc ajouté tous les artefacts nécessaires, passons maintenant à la raison de notre venue ici. Nous extrayons le modèle ARM généré dans l'onglet Avancé de la même fenêtre de création de formule.

Nous copions le contenu de la page dans le fichier VMtemplate.json et le plaçons à la racine du projet. Nous n'avons plus besoin du cloud, revenons au pipeline.

5. Configuration du pipeline

Commençons par le plus important et intéressant : créer une machine virtuelle, c'est pour cela que nous avons réalisé toutes ces intégrations et modèles. Dans la section Abonnement Azure RM, nous choisissons notre connexion de service que nous avons configurée au point 2. Ensuite, un environnement de laboratoire disponible devrait apparaître. Puis, nous sélectionnons le fichier json que nous avons généré et définissons certaines variables obligatoires. Le nom d'utilisateur et le mot de passe de la machine peuvent être définis directement ou par des variables, mais je ne suis pas vraiment sûr que cela fonctionne, peu importe ce que j’écris, je n’arrivais pas à me connecter à la machine avec ces identifiants. Il est important de donner un nom à la machine et d'essayer de le rendre toujours unique. Pour cela, j'utilise une variable d'environnement de build.

Ensuite, nous configurons un autre point essentiel. Après le démarrage de la machine, nous devons savoir quels sont ses paramètres, ou mieux encore, le pipeline doit le savoir. Pour cela, nous créons un script, par exemple GetLabVMParams.ps1, et le plaçons également dans le projet. J'ai pris le texte du script sur le site de Microsoft, mais je l'ai légèrement modifié pour mon environnement, car il prenait l'IP publique et le FQDN de la machine. Je n'ai ni l'un ni l'autre, mais j'ai une IP privée qui n'est pas si facile à obtenir, donc j'ai ajouté un morceau.

Param( [string] $labVmId)

$labVmComputeId = (Get-AzureRmResource -Id $labVmId).Properties.ComputeId

# Obtenir le nom du groupe de ressources de la VM de laboratoire
$labVmRgName = (Get-AzureRmResource -Id $labVmComputeId).ResourceGroupName

# Obtenir le nom de la VM de laboratoire
$labVmName = (Get-AzureRmResource -Id $labVmId).Name

# Obtenir l'adresse IP publique de la VM de laboratoire
# $labVMIpAddress = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).IpAddress

# Obtenir le FQDN de la VM de laboratoire
# $labVMFqdn = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).DnsSettings.Fqdn

# Obtenir l'adresse IP privée de la VM de laboratoire
$VmNetworkdetails= (((Get-AzureRmVM -ResourceGroupName $labVmRgName -Name $labVmName).NetworkProfile).NetworkInterfaces).Id
$nicname = $VmNetworkdetails.substring($VmNetworkdetails.LastIndexOf("/"))+1)
$labVMnetwork = (Get-AzureRmNetworkInterface -Name $nicname -ResourceGroupName $labVmRgName)|Select-Object -ExpandProperty IPConfigurations 
$labVMIpAddress = $labVMnetwork.PrivateIpAddress

# Définir une variable labVmRgName pour stocker le nom du groupe de ressources de la VM de laboratoire
Write-Host "##vso[task.setvariable variable=labVmRgName;]$labVmRgName"

# Définir une variable labVMIpAddress pour stocker l'adresse IP de la VM de laboratoire
Write-Host "##vso[task.setvariable variable=labVMIpAddress;]$labVMIpAddress"

# Définir une variable labVMFqdn pour stocker le nom FQDN de la VM de laboratoire
Write-Host "##vso[task.setvariable variable=labVMFqdn;]$labVMFqdn"

Write-Output $labVMIpAddress

Set-Item wsman:localhostclienttrustedhosts * -Force

Parmi toutes les données lues par le script, nous avons seulement besoin de la variable labVMIpAddress. Cela me concerne, peut-être que vous aurez besoin d'autre chose, donc je n'ai rien supprimé et j'ai simplement commenté les parties inutiles.

Je vais aussi expliquer la dernière ligne du script, elle permet à notre machine de build d'accéder à n'importe quel hôte via WinRM.

La prochaine étape consiste à lancer notre merveilleux script. Il nécessitera la même connexion au cloud, ainsi qu'une variable d'entrée avec l'ID de la machine, qui sera déjà connue d'après l'étape précédente. Comment ? Il est important de mentionner une chose incroyable, appelée les variables de sortie. Chaque étape peut avoir une liste de variables qui sont transférées aux étapes suivantes du pipeline. Par conséquent, pour notre super script, une variable sera labVMIpAddress, n'oubliez pas de l'indiquer.

Ensuite, je fais des choses assez simples qui peuvent varier d'un cas à l'autre. J'exécute un script distant pour créer un partage, dans lequel je vais ensuite charger mes scripts.

New-Item "C:test" –type directory
New-SMBShare –Name "test" –Path "C:test" –FullAccess everyone

Comme le nom des tâches l'indique, nous allons copier un certain script d'exemple sur la machine et l'exécuter ensuite. Pour l'adresse de la machine distante, nous utiliserons notre variable $(labVMIpAddress). Ensuite, nous utilisons la tâche « récupérer l'artéfact du partage » et copions les résultats de l'exécution du script dans notre environnement de build, puis, avec la même tâche standard, nous sauvegardons ces fichiers dans l'artéfact de build. Une fois que nous n'avons plus besoin de la machine, nous terminons l'étape en la détruisant. La principale difficulté, comme on peut le voir dans le volume de l'article, est de s'intégrer au cloud et d'établir un contact avec la machine virtuelle que vous avez créée, après cela, vous pouvez vous amuser autant que vous le souhaitez.

C'est mon premier article, donc ne jugez pas trop sévèrement, les remarques sont les bienvenues.

Source : habr.com