Kürzlich bin ich auf ein nicht so beliebtes Tier in der DevOps-Welt gestoßen, Azure DevOps-Pipelines. Ich hatte sofort das Gefühl, dass keine klaren Anweisungen oder Artikel zu diesem Thema vorhanden waren. Ich weiß nicht, womit es verbunden ist, aber Microsoft hat eindeutig etwas zu tun, um das Tool bekannt zu machen. Heute werden wir eine Pipeline für automatisierte Tests in der Azure-Cloud erstellen.
Also die Aufgabe:
Es gibt Software, die mit denselben Azure DevOps erstellt und aus einem Projekt unter WIX zusammengestellt wird. Bei Interesse werde ich über dieses Tool schreiben. Tatsächlich ist dies eine automatisiertere Methode zum Erstellen von Windows-Installationsprogrammen, die das Standard-InstallShield ersetzt. Unsere Software erstellt und generiert also erfolgreich ein Artefakt, eine bestimmte setup.exe, mit der die Anwendung auf einem Windows-System installiert wird. Es ist erforderlich, diese Anwendung in eine virtuelle Maschine zu integrieren, die einem Produkt ähnelt, die vom dortigen Testteam vorbereiteten automatisierten Tests zu kopieren, auszuführen und die Ergebnisse zu sammeln, um den Zweig vor dem Zusammenführen als gut oder schlecht zu betrachten. Alles ist wie in GitLab,
nur durch w ....Als Virtualisierungsumgebung, in der wir unsere Tests ausführen, verwenden wir offensichtlich Azure DevTest Labs, eine Entität in Azure-Abonnements, die erstellt wurde, um alle Arten von Test-Unsinn für angemessenes Geld zu verdrehen.
1. Cloud-seitige Integration
Zunächst müssen wir unsere DevTest Labs in Azure DevOps integrieren, für die wir einen Service Principal benötigen, im Wesentlichen ein Servicekonto, mit dem Sie zu den Pipelines in der Cloud gehen und dort Ressourcen für uns selbst erstellen / löschen können.
Wechseln Sie zum Abonnement und suchen Sie den Azure Active Directory-Dienst

Wir finden App-Registrierungen und klicken auf Neue Registrierung. Dadurch wird unser Service-Prinzip erstellt. Ich werde nicht darüber nachdenken, welche Einstellungen ich beim Erstellen auswählen werde. Dies kann für verschiedene Abonnements unterschiedlich sein.

Jetzt müssen wir unserem Serviceleiter Rechte einräumen. Gehen Sie dazu mit einem Schlüssel zum Abonnementsymbol. Wählen Sie unser Abonnement.

Klicken Sie anschließend in der Zugriffssteuerung auf Rollenzuweisung und suchen Sie dieses Konto in der Suche anhand des soeben erstellten Namens. Wir geben die Rolle des Mitwirkenden, das ist genug.

Kehren Sie anschließend zu unserem Dienstprinzipal in Azure AD zurück und öffnen Sie dessen Eigenschaften. Später benötigen wir alle dort vorhandenen IDs, wir speichern sie.
Hier enden unsere Portaleinstellungen und wir wechseln zu Azure DevOps.
2. Integration auf der Seite von Azure DevOps
Zunächst gehen wir in die Projekteinstellungen und wählen Serviceverbindungen. Erstellen Sie ein neues Element vom Typ Azure Resource Manager.

Jetzt brauchen wir alle IDs, die wir aufgezeichnet haben. Klicken Sie auf Vollversion des Dialogfelds Dienstverbindung verwenden. Und geben Sie alle Daten ein, die wir vom Service Principal erhalten haben. Klicken Sie auf Überprüfen. Wenn alles in Ordnung ist, behalten Sie die Verbindung bei. Jetzt können unsere Pipelines damit eine Verbindung zur Cloud herstellen.

3. Erstellen einer Pipeline
Nun kommen wir zum interessantesten, dem Bau der Pipeline selbst. Öffnen Sie das Menü Pipelines-Builds

Wir werden von einem Menü zum Erstellen eines neuen Builds begrüßt, das standardmäßig versucht, eine YAML-Datei mit einer geeigneten Konfiguration für uns zu erstellen. Wir lehnen dies höflich ab und wählen die klassische Version. Der Wunsch von Microsoft, alles wie Menschen zu tun und die Möglichkeit zu geben, Pipelines über YAML so weit wie möglich anzupassen. Die geringe Dokumentation und die praktische Inoperabilität vieler Module zeigen jedoch, dass es zu früh ist, diese Funktionalität zu nutzen.

Aus der Vielzahl der Vorlagen benötigen wir eine einfache leere Pipeline. Nach seiner Erstellung werden wir von einem leeren Bearbeitungsfenster begrüßt, in dem wir viel Zeit verbringen werden.

Klicken Sie also auf + und gelangen Sie in einen bestimmten Modulspeicher, von dem aus wir die folgenden Komponenten aus der Liste benötigen.

Bevor wir mit der Konfiguration der Pipeline-Aufgabe fortfahren, müssen wir mehrere Dateien erstellen und in das Projekt einfügen. Dies ist die ARM-Vorlage unserer virtuellen Maschine, die wir in Azure DevTest Labs generieren, das Skript zum Abrufen der IP-Maschine nach ihrer Erstellung und, falls gewünscht, die Skripte unserer Tests oder das, was wir auf dem Host ausführen möchten.
4. Generierung von ARM-Vorlagen
Um eine virtuelle Maschine zu erstellen, müssen wir zuerst eine Vorlage dafür generieren, eine JSON-Datei, die wir in den Projektcode einfügen, damit sie von der Pipeline von dort gelesen werden kann.
Wir gehen in unser Labor und suchen das Menü Formeln (wiederverwendbare Basen). Klicken Sie, um ein neues zu erstellen.

Wir werden von einer langen Liste von Bildern als Basis begrüßt, die Auswahl der Größe der Maschine, genau wie beim Erstellen einer virtuellen Maschine. In diesem Stadium werden wir nicht aufhören, sondern sofort zum letzten Element der Maschineneigenschaften übergehen, nämlich zu Artefakten. Sie können alle Konfigurationen verwenden, die für Ihre Umgebung erforderlich sind. Beispielsweise füge ich der Domäne einen Computer hinzu und füge ihr als Administrator ein Dienstkonto hinzu, damit die Pipeline dann unter diesem Konto auf diesen Computer zugreifen kann. Dies kann alles variieren, aber für ein erfolgreiches Testen des Codes benötigen wir ein Artefakt, auf das wir näher eingehen werden. Um die neueste Version der von uns getesteten Software auf unserem Computer zu installieren, verwenden wir das Artefakt "Azure-Pipelines herunterladen" und "Skript ausführen". Erinnern Sie sich an den Anfang, als ich sagte, dass irgendwo ein Build mit dem Anwendungsinstallationsprogramm ausgeführt wird? Jetzt müssen wir der virtuellen Maschine oder besser gesagt der Vorlage mitteilen, damit er dieses Artefakt nimmt. Und ich habe es nicht nur aufgenommen, sondern auch festgelegt, für die wir spezielle Felder ausfüllen, in denen das Projekt, der Name des Builds und der geheime Schlüssel angegeben sind. Der geheime Schlüssel wird wie in allen Systemen dieser Art im Konto generiert, in diesem Fall in Azure DevOps, und in Secrets in Ihrem Labor gespeichert. Es gibt eine kleine Einschränkung: In Secrets werden wir es speichern, aber es ist weder kalt noch heiß. Es wird von einem anderen Benutzer als Teil der Pipeline gestartet. Daher müssen wir den geheimen Schlüssel erneut manuell in die Vorlage eingeben.
Ein weiteres Artefakt, das enthalten sein muss, ist "WinRM konfigurieren". Wir benötigen es für den späteren Zugriff auf den Computer. Es gibt nur einen Parameter, den Hostnamen. Da wir es nicht im Voraus wissen, werden wir die Variable% COMPUTERNAME% verwenden.

Nachdem wir alle erforderlichen Artefakte hinzugefügt haben, werden wir uns damit befassen, warum wir überhaupt hierher gekommen sind. Wir erhalten die generierte ARM-Vorlage auf der Registerkarte Erweitert des gleichen Formelerstellungsfensters.

Kopieren Sie den Inhalt der Seite in die Datei VMtemplate.json und legen Sie ihn im Stammverzeichnis des Projekts ab. Wir brauchen die Cloud nicht mehr, wir kehren zur Pipeline zurück.
5. Pipeline-Konfiguration
Beginnen wir mit dem Wichtigsten und Interessantesten, dem Erstellen einer virtuellen Maschine. Aus diesem Grund haben wir alle diese Integrationen und Vorlagen erstellt. Im Azure RM-Abonnement wählen wir unsere Dienstverbindung aus, die wir in Absatz 2 konfiguriert haben. Als Nächstes wird die verfügbare Laborumgebung angezeigt. Dann wählen wir json aus, das wir generiert haben, und definieren einige obligatorische Variablen. Der Benutzername und das Passwort des Autos können entweder direkt oder mit Variablen festgelegt werden, aber ich bin mir nicht sicher, ob es funktioniert. Was auch immer ich dort schreibe, ich konnte unter diesen Credits nicht in das Auto einsteigen. Die Hauptsache ist, den Namen des Autos so einzustellen, dass es immer möglich ist einzigartig. Dafür verwende ich die Build-Umgebungsvariable.

Als nächstes legen wir einen weiteren wichtigen Punkt fest. Nach dem Start des Autos müssen wir auch die Parameter irgendwie kennen, und es ist besser, nicht für uns, sondern für die Gewinnlinie. Dazu erstellen wir ein Skript, zum Beispiel GetLabVMParams.ps1, und fügen es dort in das Projekt ein. Ich habe den Text des Skripts auf der Microsoft-Website übernommen, ihn jedoch für meine Umgebung leicht korrigiert, weil Er nahm PublicIP- und FQDN-Maschinen. Ich habe keine, aber es gibt PrivateIP, das nicht so einfach zu bekommen ist, also habe ich ein Stück hinzugefügt.
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
Von allem, was das Skript liest, benötigen wir nur die Variable labVMIpAddress. Nun, das ist für mich, vielleicht brauchst du etwas anderes, dafür habe ich nichts gelöscht und nur den Überschuss auskommentiert.
Ich werde auch die letzte Zeile des Skripts erläutern. Sie ermöglicht unserem Build-Computer den Zugriff auf jeden Host über WinRM.
Im nächsten Schritt führen wir unser wunderbares Skript aus. Er benötigt dieselbe Verbindung zur Cloud, die Eingabevariable mit der Maschinen-ID, die zu diesem Zeitpunkt bereits aus dem vorherigen Schritt bekannt sein wird. Wie? Hier ist es notwendig, so etwas Wunderbares wie Ausgabevariablen zu erwähnen. Jeder Schritt kann eine Liste von Variablen enthalten, die an die nächsten Pipeline-Schritte weitergegeben werden. Dementsprechend ist eine solche Variable für unser Superskript labVMIpAddress. Vergessen Sie nicht, dies anzugeben.

Außerdem mache ich ziemlich einfache Dinge, die außerdem von Fall zu Fall variieren können. Ich führe ein Remote-Skript mit der Erstellung von Bällen aus, in das ich dann meine Skripte hochlade.
New-Item “C:\test" –type directory New-SMBShare –Name “test” –Path “C:\test” –FullAccess everyone
Aus dem Namen der Kohlköpfe geht hervor, dass wir dann ein Beispielskript auf die Maschine kopieren und es in einem weiteren Schritt ausführen. Als Adresse des Remote-Computers ist unsere Variable $ (labVMIpAddress) für uns nützlich. Als Nächstes verwenden wir die Aufgabe „Artefakt von den Kugeln aufnehmen“ und kopieren die Ergebnisse des Skripts in unsere Build-Umgebung. Anschließend speichern wir diese Dateien im Build-Artefakt mit derselben Standardaufgabe. Nachdem wir das Auto nicht mehr brauchen, töten wir es mit dem letzten Schritt. Die Hauptschwierigkeit, wie aus dem Band des Artikels hervorgeht, besteht darin, sich in die Cloud zu integrieren und Kontakt mit der von Ihnen erstellten virtuellen Maschine aufzunehmen. Dann können Sie bereits so viel Spaß haben, wie nötig.
Dies ist mein erster Artikel, also urteile nicht streng, Kommentare sind willkommen.