Récemment, je suis tombé sur une bête pas si populaire dans le monde DevOps, les pipelines Azure DevOps. Immédiatement, j'ai ressenti l'absence d'instructions ou d'articles clairs sur le sujet, je ne sais pas à quoi il est lié, mais Microsoft a clairement quelque chose à travailler en termes de vulgarisation de l'outil. Aujourd'hui, nous allons créer un pipeline pour les tests automatisés dans le cloud Azure.

Donc, la tâche:
Il existe des logiciels qui s'appuient sur les mêmes Azure DevOps, qui sont assemblés à partir d'un projet sur WIX. S'il y a un intérêt, j'écrirai sur cet outil. En fait, il s'agit d'un moyen plus automatisé de créer des programmes d'installation Windows, qui remplace le InstallShield standard. Ainsi, notre logiciel construit et génère avec succès un artefact, un certain setup.exe, qui place l'application sur un système Windows. Il est nécessaire de placer cette application dans une machine virtuelle similaire à un prod, de copier les tests automatisés préparés par l'équipe de test là-bas, de les exécuter et de collecter les résultats afin de considérer la branche comme bonne ou mauvaise avant de fusionner. Tout est comme dans GitLab, uniquement via w ....

En tant qu'environnement de virtualisation où nous exécuterons nos tests, nous utilisons évidemment Azure DevTest Labs, une entité dans les abonnements Azure, qui a été créée pour déformer toutes sortes de non-sens de test en elle pour un prix raisonnable.

1. Intégration côté cloud

Tout d'abord, nous devons intégrer nos laboratoires DevTest à Azure DevOps, pour lesquels nous avons besoin d'un principal de service, essentiellement un compte de service qui vous permet d'accéder aux pipelines dans le cloud et d'y créer / supprimer des ressources pour nous-mêmes.

Accédez à l'abonnement et recherchez le service Azure Active Directory



Nous trouvons les enregistrements d'applications et cliquez sur Nouvel enregistrement, cela créera notre principal de service. Je ne passerai pas en revue les paramètres que je choisirai lors de la création, cela peut différer selon les abonnements.



Maintenant, nous devons donner des droits à notre directeur de service. Pour ce faire, accédez à l'icône d'abonnement avec une clé. Choisissez notre abonnement.



Ensuite, dans Contrôle d'accès, cliquez sur Attribution de rôle et recherchez ce compte dans la recherche par le nom que vous venez de créer. Nous donnons le rôle de contributeur, cela suffit.



Ensuite, revenez à notre principal de service dans Azure AD et ouvrez ses propriétés. Plus tard, nous aurons besoin de tous les identifiants qui s'y trouvent, nous les enregistrons.

C'est là que se terminent nos paramètres de portail et nous allons à Azure DevOps.

2. Intégration du côté d'Azure DevOps

Tout d'abord, nous allons dans les paramètres du projet et sélectionnez Connexions de service. Créez un nouvel élément de type Azure Resource Manager.



Maintenant, nous avons besoin de tous les identifiants que nous avons enregistrés. Cliquez sur utiliser la version complète de la boîte de dialogue de connexion au service. Et entrez toutes les données que nous avons reçues du directeur de service. Cliquez sur vérifier et si tout va bien, conservez la connexion. Nos pipelines peuvent désormais l'utiliser pour se connecter au cloud.

3. Création d'un pipeline

Nous passons maintenant à la plus intéressante, la construction du pipeline lui-même. Ouvrez le menu Pipelines-Builds



Nous sommes accueillis par un menu pour créer une nouvelle construction, qui tentera par défaut de créer un fichier YAML pour nous avec une configuration appropriée. Nous refusons poliment cela et choisissons la version classique. Le désir de Microsoft de tout faire comme les gens et de donner la possibilité de personnaliser autant que possible les pipelines via YAML, mais la documentation limitée et juste l'inopérabilité pratique de nombreux modules nous indique qu'il est trop tôt pour utiliser cette fonctionnalité.



De la variété des modèles, nous avons besoin d'un simple pipeline vide. Après sa création, nous sommes accueillis par une fenêtre d'édition vide, dans laquelle nous allons passer beaucoup de temps.



Alors, cliquez sur + et entrez dans un certain magasin de modules, d'où nous aurons besoin des composants suivants de la liste.



Avant de procéder à la configuration de la tâche de pipeline, nous devons créer et placer plusieurs fichiers dans le projet. Ce sera le modèle ARM de notre machine virtuelle, que nous générerons dans Azure DevTest Labs, le script pour obtenir la machine IP après sa création et, si vous le souhaitez, les scripts de nos tests ou ce que nous voulons exécuter sur l'hôte.

4. Génération de modèles ARM

Pour créer une machine virtuelle, nous devons d'abord générer un modèle pour cela, un fichier json, que nous mettons dans le code du projet afin qu'il puisse être lu à partir de là par le pipeline.

Nous allons dans notre laboratoire et trouvons le menu Formules (bases réutilisables), cliquez pour en créer un nouveau.



Nous serons accueillis par une longue liste d'images comme base, le choix de la taille de la machine, tout comme lors de la création d'une machine virtuelle. À ce stade, nous ne nous arrêterons pas, nous allons immédiatement passer au dernier élément des propriétés de la machine, à savoir les artefacts. Vous pouvez utiliser toutes les configurations nécessaires à votre environnement. Par exemple, j'ajoute une machine au domaine et j'y ajoute un compte de service en tant qu'administrateur afin que le pipeline puisse ensuite accéder à cette machine sous ce compte. Tout cela peut varier, mais pour réussir les tests du code, nous avons besoin d'un artefact, sur lequel nous nous attarderons plus en détail. Pour mettre la dernière version du logiciel que nous avons testé sur notre machine, nous utiliserons l'artefact Télécharger les pipelines Azure et exécuter l'artefact Script. Rappelez-vous au début, j'ai dit que quelque part une construction va avec le programme d'installation de l'application? Maintenant, nous devons dire à la machine virtuelle, ou plutôt au modèle, pour qu'il aille prendre cet artefact. Et je ne l'ai pas simplement récupéré, mais également défini, pour lequel nous remplissons des champs spéciaux indiquant le projet, le nom de la génération 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, dans ce cas dans Azure DevOps et stockée dans Secrets dans votre laboratoire. Il y a une petite mise en garde, dans Secrets, nous l'enregistrerons, mais ce n'est ni froid ni chaud, il sera lancé à partir d'un autre utilisateur dans le cadre du pipeline, donc nous devrons saisir à nouveau manuellement la clé secrète dans le modèle.

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



Nous avons donc ajouté tous les artefacts nécessaires, nous allons passer à la raison pour laquelle nous sommes venus ici. Nous obtenons le modèle ARM généré dans l'onglet Avancé de la même fenêtre de création de formule.



Copiez le contenu de la page dans le fichier VMtemplate.json et placez-le à la racine du projet. Nous n'avons plus besoin du cloud, nous revenons au pipeline.

5. Configuration du pipeline

Commençons par le plus important et le plus intéressant, la création d'une machine virtuelle, pour cela nous avons fait toutes ces intégrations et modèles. Dans l'abonnement Azure RM, nous sélectionnons notre connexion de service, que nous avons configurée à l'étape 2. Ensuite, l'environnement de laboratoire disponible s'affiche. Ensuite, nous sélectionnons json que nous avons généré et nous définissons quelques variables obligatoires. Le nom d'utilisateur et le mot de passe de la voiture peuvent être définis directement ou avec des variables, mais je ne suis pas sûr du tout que cela fonctionne, quoi que j'écrive là-bas, je ne pourrais pas entrer dans la voiture avec ces crédits, l'essentiel est de définir le nom de la voiture afin qu'il soit toujours possible unique. Pour cela, j'utilise la variable d'environnement de génération.



Ensuite, nous avons mis en place un autre point important. Après le décollage de la voiture, nous devons également connaître ses paramètres d'une manière ou d'une autre, et ce n'est pas mieux pour nous mais pour la ligne de paiement. Pour ce faire, nous créons un script, par exemple GetLabVMParams.ps1 et le mettons là, dans le projet. J'ai pris le texte du script sur le site Web de Microsoft, mais je l'ai légèrement corrigé pour mon environnement, car il a pris des machines PublicIP et FQDN. Je n'en ai pas, mais il y a PrivateIP qui n'est pas si facile à obtenir, j'ai donc ajouté un morceau.

Param( [string] $labVmId) $labVmComputeId = (Get-AzureRmResource -Id $labVmId).Properties.ComputeId # Get lab VM resource group name $labVmRgName = (Get-AzureRmResource -Id $labVmComputeId).ResourceGroupName # Get the lab VM Name $labVmName = (Get-AzureRmResource -Id $labVmId).Name # Get lab VM public IP address # $labVMIpAddress = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).IpAddress # Get lab VM FQDN # $labVMFqdn = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).DnsSettings.Fqdn # Get lab VM private IP address $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 # Set a variable labVmRgName to store the lab VM resource group name Write-Host "##vso[task.setvariable variable=labVmRgName;]$labVmRgName" # Set a variable labVMIpAddress to store the lab VM Ip address Write-Host "##vso[task.setvariable variable=labVMIpAddress;]$labVMIpAddress" # Set a variable labVMFqdn to store the lab VM FQDN name Write-Host "##vso[task.setvariable variable=labVMFqdn;]$labVMFqdn" Write-Output $labVMIpAddress Set-Item wsman:\localhost\client\trustedhosts * -Force 

De tout ce que le script lit, nous n'avons besoin que de la variable labVMIpAddress. Eh bien, c'est pour moi, peut-être avez-vous besoin d'autre chose, pour cela, je n'ai rien supprimé et j'ai juste commenté l'excès.

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

L'étape suivante, nous exécutons notre merveilleux script. Il aura besoin de la même connexion au cloud, la variable d'entrée avec l'ID de la machine, qui à ce moment-là sera déjà connue de l'étape précédente. Comment? Ici, il est nécessaire de mentionner une chose aussi merveilleuse que les variables de sortie. Chaque étape peut avoir une liste de variables qui sont transmises aux prochaines étapes du pipeline. En conséquence, pour notre super script, une telle variable sera labVMIpAddress, n'oubliez pas de l'indiquer.



De plus, je fais des choses assez simples qui, en plus, peuvent varier d'un cas à l'autre. J'exécute un script à distance avec la création de boules, dans lequel je téléchargerai ensuite mes scripts.

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

D'après le nom des choux, il est clair que nous copions ensuite un exemple de script sur la machine et l'exécutons en une étape de plus. En tant qu'adresse de la machine distante, notre variable $ (labVMIpAddress) nous est utile. Ensuite, nous utilisons la tâche «ramasser l'artefact des boules» et copions les résultats du script dans notre environnement de build, puis nous enregistrons ces fichiers dans l'artefact de build avec la même tâche standard. Une fois que nous n'avons plus besoin de la voiture, nous la tuons à la dernière étape. La principale difficulté, comme on peut le voir dans le volume de l'article, est de s'intégrer au cloud et d'établir le contact avec la machine virtuelle que vous avez créée, alors vous pouvez déjà vous amuser autant que vous en avez besoin.

Ceci est mon premier article, alors ne jugez pas strictement, les commentaires sont les bienvenus.