Builds automatisieren mit Visual Studio Team Services

Builds automatisieren mit Visual Studio Team Services

Builds automatisieren mit Visual Studio Team Services

… oder “wer ist Bob”? BobOK, mal ganz langsam und von vorne.

Es war noch nie so einfach mal eben einen Build-Server und einen Continuous Build & Continuous Deployment Prozess aufzusetzen wie mit den Visual Studio Team Services (VSTS).

Zunächst also mal kurz im VSTS eingeloggt und unter den Einstellungen der Collection zu den Agent Queues gewechselt. Hier kann man alles was man für einen neuen Agent braucht als ZIP herunterladen.

Agent Herunterladen

Als nächstes brauchen wir einen neuen Server, der unsere Build ausführen soll. Ich habe mal eben flux einen Windows Server 2012 R2 als VM aus einem Template angelegt. Da der Server ja nur Builds machen soll, ist der noch nicht einmal Mitglied der Domäne.

Als nächstes also das ZIP entpackt und die ConfigureAgent.cmd gestartet. Hier kann dem Agent ein Name gegen werden, unter dem er im VSTS später angezeigt wird. Außerdem muss hier der VSTS-Mandant angegeben werden. Anschließend erfolgt eine einmalige Authorisation des Agenten an VSTS – und fertig. Der Agent läuft schon sofort.

Damit wir auch unsere erste Anwendung bauen und deployen können brauchen wir noch ein paar Werkzeuge: GIT, Node.JS und die AzurePowerShell. Am einfachsten gibt es das von Chocolatey.

Also mit :

@powershell -NoProfile -ExecutionPolicy Bypass -Command "iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin

erst Chocolatey installieren und dann mit

choco install git nodejs azurepowershell

den Rest nachschieben. Nun einmal die CMD beenden und neu starten (damit die Path-Anpassungen auch übernommen werden) und dann den VsoAgent.exe neu starten (wenn man den als Windows-Dienst eingerichtet hat, dann einfach den Service einmal neustarten).

Nun kann man im VSTS in der Agent Queue den neuen Agent sehen – und auch seine Capabilities. Hier dürfte nun unter anderem AzurePS und node.js als Capability zu erkennen sein.

Nun können wir uns also an unsere Anwendung machen. Ich habe dazu eine kleine Web-Anwendung erstellt. Node.js brauche ich übrigens weil ich Gulp für den Build verwende. Nachdem unsere Anwendung nun also in GIT eingecheckt ist, können wir auch eine Build-Definition erstellen.

Dazu wählen wir als erstes ein neues Template aus – ich habe hier ein leeres Template gewählt.

Neue Build-Definition erstellen

Anschließend noch das Code-Repository bestimmten und die Agent-Queue. Hier verwende ich die “Default”-Queue, dort hat sich ja auch mein neuer Build-Agent registriert.

Neue Build-Definition einrichten

Nun habe ich also meine neue Build-Definition, der ich in meinem Fall zwei Tasks hinzugefügt habt:

  1. npm install
  2. gulp package

Build-Schritte hinzufügen

Dies Tasks sind analog zu dem, was ich auf meiner Workstation machen würde, nachdem ich das Git-Repository ge-cloned habe. Erst mal mit npm install alle notwendigen Abhängigkeiten laden und dann mit Gulp den eigentlich Build-Prozess anwerfen.

Mit Hilfe von Gulp werden alle meine benötigten HTML, CSS und JS Dateien zusammengestellt, minifiziert und anschließend in einem ZIP-Archiv zusammengepackt.

Nun kann ich den Build manuell Starten (Queuen). Das Ergebnis zeigt dann, dass alles funktioniert hat.

Build-Zusammenfassung

Perfekt – wir haben unseren ersten Build erfolgreich durchgeführt.

Zum Abschluss fehlt noch, dass der Build immer angestoßen wird, wenn es etwas neues gibt – sprich, dass bei jedem Checkin in das Repository der Build angestoßen wird. Dazu wird unter den Triggern des Builds einfach das Continuous Integration aktiviert.

Continuous-Build einrichten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Time limit is exhausted. Please reload the CAPTCHA.