Wie der erste Artikel [1] gezeigt hat,

Transkript

1 Visual Studio Online, Teil 2: Continuous Integration Der ewig integrierte Stenz Wie man mit dem neuen Visual Studio Online Code schreiben und verwalten kann, war Bestandteil des ersten Artikels. Diesmal wird gezeigt, wie man sich eine produktive Entwicklungsumgebung in Kombination mit Azure aufsetzt. Auf einen Blick Patrick Speidel ist als Manager Software Development angestellt. Als Team- und Projektleiter ist er unter anderem verantwortlich für die Pflege und Weiterentwicklung des hauseigenen ERP-Clients, hat aber auch regelmäßig Berührung mit Webthemen. Sie erreichen ihn unter der -Adresse Inhalt Mit Visual Studio Online lässt sich ein Continuous Integration Workflow aufsetzen. Der Trick dabei ist, zwei Azure-Websites zu verwenden. Dank Dashboard erhält man dann auch einen Überblick über den Zustand des Projekts. dnpcode A1404Monaco Wie der erste Artikel [1] gezeigt hat, sind die Fähigkeiten des Monaco Editors beachtlich. Da kommt teilweise echter Visual-Studio-Luxus auf. Produktives Arbeiten ist definitiv möglich. Kombiniert man mit dem, was Visual Studio Online sonst noch anbietet, lässt sich mit wenigen Handgriffen und Mausklicks eine vollwertige Entwicklungsumgebung für mehrere auch verteilt sitzende Entwickler quasi aus dem Nichts stampfen. Die Lösung verfügt dann über automatisierte Builds, Deployments und alles, was noch dazugehört. Dabei sind allerdings ein paar Dinge zu beachten. Das Wichtigste ist die Trennung in zwei Azure-Websites. Einmal die mit dem Code, der mit Monaco online bearbeitet wird, und dann die Seite, die für den Anwender sichtbar ist. [Abb. 1] Eingeben der Eckdaten wie Projektname und Auswahl des Templates. [Abb. 2] Das Dashboard des neuen Projekts. Es zeigt noch Dummy- Einträge unter anderem für das Burndown-Chart an. Frisch ans Werk, Gesellen! Alles beginnt mit dem Anlegen eines neuen Projekts in Visual Studio Online. Sollten Sie Visual Studio Online noch nicht eingerichtet haben, können Sie das ganz einfach über den Link Starten Sie kostenlos auf der Webseite von Visual Studio Online nachholen [2]. Die Grundvariante Basic von Visual Studio Online ist für bis zu fünf Benutzer kostenlos. Man kann damit beliebig viele Projekte und Code Repositories anlegen, dabei seine Arbeit unter Anwendung diverser Vorgehensmodelle allen voran natürlich Scrum strukturieren und außerdem das Feature nutzen, das hier eine Hauptrolle spielt: Builds in der Azure Cloud ausführen lassen. Nachdem man sich mit seinem Live Account bei Visual Studio Online angemeldet hat, öffnet

2 man den Dialog zum Erstellen eines neuen Projekts und gibt Name und weitere Eckdaten ein (Abbildung 1). Bei der Auswahl des Repository-Typs bietet sich Git an, da man damit die breiteste Unterstützung auch für andere Editoren hat. Auch Monaco kommt damit bestens zurecht, wie schon im ersten Teil gezeigt wurde. Der Team Foundation Server legt dann das Team-Projekt an und wenige Sekunden später wird Ihnen das Dashboard des Projekts präsentiert. Nachdem noch kein Backlog angelegt und keine Sprints geplant sind, sieht man nur Burndown- Dummies (Abbildung 2). Im weiteren Verlauf der Entwicklung werden diese zu hilfreichen Anzeigen des Projektstatus und der noch offenen Aufgaben. Das soll hier aber nicht näher behandelt werden. Interessant ist vielmehr der Reiter Code. Klickt man ihn an, findet man erwartungsgemäß noch keinen Inhalt. Dafür zeigt Visual Studio Online aber eine Anleitung an, wie man Inhalt hier hineinbekommt (Abbildung 3). Grundsätzlich gibt es dafür zwei Wege: Man geht von dem leeren Repository aus oder man befüllt das Repository aus einem bereits bestehenden. Wir gehen von Letzterem aus: Die Codebasis des Beispiels ist eine simple ASP.NET-Anwendung, die zuvor in Visual Studio Express 2013 for Web angelegt wurde. Um also nun Code in das Repository zu pushen, muss man Visual Studio lokal auf dem Rechner starten, die Solution öffnen und im Team Explorer den Code ins Cloud-Repository publizieren (publish). Den Pfad zum Git Repository in Visual Studio Online findet man in der Anleitung, die im leeren Repository online steht (Abbildung 4), oder man nutzt die Möglichkeit, sich im Team Explorer mit einem Team-Projekt zu verbinden, gibt dort das eben erstellte Online-Team-Projekt an und publisht dann. Nach erfolgreichem Publishing findet man die Solution nun auch online (siehe Abbildung 5). Alle Schotten dicht, nun wird gebrowst Ab sofort kann man alle Anwendungen außer dem Browser schließen und nur noch online arbeiten. Der nächste Schritt ist, eine Azure-Website anzulegen, die sich auch aus dem eben befüllten Online-Git-Repository speist. In dieser wird [Abb. 3] Hilfen im Projekt: Wie Sie Code einfüllen können, verrät dieser Dialog. [Abb. 4] Auch hier gibt Visual Studio Online Hilfen: So bekommen Sie vorhandenen Code ins System. [Abb. 5] Geschafft: Die Solution steht in Visual Studio Online zur Verfügung. [Abb. 6] Anlegen einer Azure- Website. [Abb. 8] Das Einverständnis für die Verbindung geben. [Abb. 9] Verbindung ist hergestellt. Die neuen Website erscheint in der Liste. [Abb. 7] Wählen, woher der Quellcode für die Website kommt

3 Visual Studio Online, Teil 2: Continuous Integration [Abb. 10] Anhand des Reiters Bereitstellungen sieht man, dass die Verknüpfung hergestellt ist und auf Wunsch auch wieder getrennt werden kann (rechts unten). [Abb. 11] Auf Knopfdruck bauen und auf den Zielserver verteilen. [Abb. 13] Fortschritt des Builds. später die eigentliche Webseite laufen. Dazu meldet man sich bei Azure an [3] und klickt am unteren Rand auf das Plus- Symbol. Wählen Sie dann Server Website Benutzerdefiniert Erstellen und geben Sie den gewünschten URL und die Region ein und ob Sie eine Datenbank verknüpfen möchten (Abbildung 6). [Abb. 12] Über die Priorität kann man steuern, wie schnell der Build fertiggestellt ist. Besonders wichtig bei diesem Schritt ist anzuwählen, dass man hierher aus der Quellcodeverwaltung veröffentlichen möchte. Dies lässt sich zwar auch später noch konfigurieren, aber hier hat man das dann gleich als Schritt beim Wizard mit drin. Durch Klicken auf den Weiter-Pfeil rechts unten kommt man zu dem Dialog, in dem man das Repository, das verknüpft werden soll, auswählen kann (Abbildung 7). Die Wahl fällt auf Visual Studio Online, im nächsten Schritt gibt man den Kontonamen an und autorisiert sich (Abbildung 8), woraufhin man in einem Dialog nochmals explizit sein Einverständnis für die Verknüpfung gibt. Es werden alle dort verfügbaren Team- Projekte geladen und nach der Auswahl des entsprechenden Projekts und einem Klick auf den Fertigstellen-Button wird die Azure-Website erzeugt und erscheint dann in der Liste der Websites (Abbildung 9). Öffnen Sie nun das Dashboard der Website in Azure, sehen Sie an dem Reiter Bereitstellungen, dass sie mit der Sourcecode-Verwaltung verknüpft ist. Unten im Bereich Auf einen Blick finden Sie außerdem die Möglichkeit, die Verknüpfung wieder aufzuheben, sollten Sie dies wünschen (Von Visual Studio Online trennen). Ja, bin ich denn schon verbunden? Während der Erstellung der Verknüpfung zwischen Git-Repository und Azure-Website wurde in Visual Studio Online eine neue Build-Definition angelegt. Zu finden ist sie dort unter Build. Sie trägt den Namen der Solution mit dem Appendix CD für Continuous Delivery. Stößt man einen neuen Build an (Abbildungen 11, 12), wird er in die Queue gelegt, die Solution wird komplett aus dem Repository gezogen, gebaut und auf die Azure-Website kopiert. Je nach Auslastung und Verfügbarkeit der Build Controller dauert es ein paar Sekunden, bis der Build startet. Während er läuft, kann man durch Doppelklick auf den Eintrag den Fortschritt sehen (Abbildung 13) und nach Abschluss die Auswertung zum Build-Verlauf (Abbildung 14). Besonders wichtig ist hier natürlich der Hinweis, dass das Deployment geklappt hat. Auch in der Azure-Konsole kann man sehen, dass ein Deployment passiert ist, hier findet sich eine Historie über die letzten Deplyoments und wie sie abgelaufen sind (Abbildung 15). Und nicht zuletzt kann man sich natürlich auch von dem Ergebnis des Deployments überzeugen, wenn man die erstellte Seite im Browser aufruft. Das ist schön und macht Spaß, aber es soll ja noch mehr passieren. Code soll editiert und eingecheckt werden und dann soll das alles automatisch passieren. Dazu benötigt man wie schon eingangs erwähnt noch eine weitere

4 [Abb. 14] Überblick über den Build-Lauf. [Abb. 15] Hat der Build geklappt? Der Bereitstellungsverlauf gibt Auskunft. [Abb. 16] Eine weitere Azure- Website enthält den Quellcode. [Abb. 18] Dazu wird das Repository geklont. [Abb. 17] Den Quellcode in die Bearbeitungsseite holen. Azure-Website. Die wird es dann sein, die den kompletten Quellcode und nicht nur die veröffentlichte Seite enthält und die man mit Monaco online editieren kann. Auf zwei Beinen Dazu legt man nun in Azure eine weitere Website an. Die Schritte sind ähnlich wie eben, nur dass man nun nicht angibt, aus der Quellcodeverwaltung veröffentlichen zu wollen. Es bietet sich an, die Site genauso zu nennen wie die vorher angelegte und sie mit einem Appendix, zum Beispiel DEV, zu kennzeichnen. So findet man sich später besser zurecht, vor allem wenn man mehr als eine Seite unter Azure hostet. Nachdem Azure die Site erfolgreich initialisiert hat, öffnet man dort die Verwaltung der Site und dann den Reiter Konfigurieren. Wie schon im ersten Artikel beschrieben, aktiviert man nun die Option In Visual Studio Online bearbeiten und [Abb. 19] Der Sourcecode fließt in die Website. [Abb. 20] Geschafft: Jetzt kann der Code bearbeitet werden

5 Visual Studio Online, Teil 2: Continuous Integration [Abb. 21] Kleine Änderung, große Welle? Muss es jedesmal der gesamte Build sein? [Abb. 22] Das Umstellen des Verzeichnisses auf die Assembly des Start- Projekts. [Abb. 23] Schnell mal bauen: Über die Kommandozeile den Build anstoßen. [Abb. 24] Einen Parameter verändern und schon zeigt Visual Studio Online einen Link zu der Stelle an, an der ein Fehler passiert. speichert die Konfiguration (Abbildung 16). Daraufhin findet man im Dashboard ebendiese Funktion. Ein Klick darauf bringt Monaco auf den Schirm. Noch allerdings ohne Code. Den muss man nun aus dem Repository holen. Dazu geht man links auf das Git-Symbol und in der dann angezeigten Auswahl entscheidet man sich für Connect to Visual Studio Online (Abbildung 17). Nachdem man sich autorisiert hat, kann man wieder das Team-Projekt wählen und den Klonprozess starten (Abbildung 18). Monaco wechselt in die Konsolenansicht und nachdem man sich ein weiteres Mal, diesmal am Repository, authentifiziert hat, fließt der Sourcecode endlich nach Monaco (Abbildungen 19 und 20). Jetzt kann man den Code online editieren. Monaco unterstützt dabei nach Kräften, wie bereits beschrieben. Nach einem Commit und dann einem Push in Git wird nun automatisch ein neuer Build in die Bearbeitungsschlange gestellt und nach Abschluss des Builds auf die zweite Website kopiert. Man kann das wieder wie oben schon gesehen auf der Webseite des Visual Studio Online beobachten. Jedes Mal ganz rum? Das ist schon mal ganz schön, aber will man jedes Mal einchecken, wenn man etwas geändert hat, und auf den Continuous Integration Build warten, um zu sehen, ob das, was man geändert hat, auch funktioniert (Abbildung 21)? Nein. Dafür gibt es heute natürlich Unit Tests, die man gezielt starten könnte. Aber auch das ist Code, der kompiliert werden und der irgendwo laufen muss. Aber obwohl Monaco jede Änderung im Code automatisch speichert, bedeutet das nicht, dass auch alles gleich im Hintergrund kompiliert wird. Auch fällt auf, wenn man einmal im linken Menü den Run-Knopf wählt oder die zugehörige Tastenkombination [Strg]+[F5] drückt: Es wird einem zwar ein Link angeboten, der auch geöffnet werden kann, aber dann bekommt man nur eine Fehlermeldung zu sehen: You do not have permission to view this directory or page. So lässt sich nicht arbeiten! Muss man aber auch nicht. Monaco und Azure bieten nämlich auch hier eine Lösung an. Der erste Schritt ist, in Azure eine Einstellung zu ändern. Wichtig dabei ist, dass diese Änderung für die Site passiert, auf der man Code schreibt also die Azure

6 [Abb. 25] Direktlink zur fehlerhaften Stelle. Website, die wie oben vorgeschlagen mit DEV im Namen gekennzeichnet ist. Unter Konfigurieren scrollt man fast ganz nach unten und findet dort die Möglichkeit, virtuelle Anwendungen und Verzeichnisse zu konfigurieren. Standardmäßig gibt es dort einen Eintrag für das Root-Verzeichnis der Website, die auf den Folder site\wwwroot im Filesystem zeigt. Der Trick besteht nun darin, den Folder auf den Namen der Assembly des Start- Projekts der Solution zu stellen. In dem Beispiel hier wird aus site\wwwroot site\ wwwroot\dnpspezial (Abbildung 22). Der Aufruf der Seite im Browser ruft nun wenigstens keine Fehlermeldung mehr hervor. Aber wie kommt man nun dazu, dort wirklich das zu finden, was man gerade entwickelt hat? Dazu muss man es bauen. Und das geht ganz einfach. Über die Konsole. Die kam vorher schon einmal kurz zu Ehren, als Git als Kommandozeilenoperation aufgerufen wurde. Aber das passierte automatisch. Die Konsole ist aber natürlich auch manuell bedienbar, das ist sozusagen sogar ihr ursprünglicher Existenzgrund. Das ist simpel Es ist so einfach wie es klingt. Man öffnet die Konsole, entweder per Klick auf den zugehörigen Button links oder per Shortcut [Shift]+[Ctrl]+[C] oder auch über den Start-Helper ([Strg]+[E]) und gibt einen Befehl ein: msbuild und [Return], schon läuft der Build los, und zwar meist sogar recht schnell (Abbildung 23). Eventuell auftretende Build-Fehler werden hierbei natürlich auch angezeigt. [Abb. 26] Mit einem [Strg]-Klick ist man beim Fehler so wie man das von Visual Studio her kennt. Wenn man weiß, wo man hinfassen muss, bietet Monaco dann sogar den Luxus eines Links, der direkt zur defekten Codestelle führt. Dazu muss man in der jeweiligen csproj-datei in der Property Group den Schalter GenerateFullPaths auf true setzen (Abbildung 24). Normalerweise ist GenerateFullPaths gar nicht vorhanden, dann kann man es neu direkt hinzufügen über Monaco in Azure. Ein Build, der fehlschlägt, bietet nun neben der Fehlermeldung und dem Dateinamen des Files, in dem der Fehler steckt, einen Direktlink zu der Codestelle (Abbildungen 25, 26). Will man es ganz perfekt machen, legt man sich nun noch eine dritte Azure- Website an. Diese ist dann die wirklich produktive. So hat man eine Dev-Umgebung, eine QA und eben die produktive Seite, die wirklich nach außen gezeigt wird. So geht s! Mit diesem Trio aus drei Azure-Websites können Sie richtig arbeiten produktiv. Und das klappt sogar im Team. Und an verteilten Standorten. Und gleichzeitig. Und ohne sich ins Gehege zu kommen. Dazu legt sich einfach jeder Developer eine eigene Azure-Website an, die er aus dem Git-Repository bestücken kann. Dann wird lokal entwickelt und getestet und nach Fertigstellung der Arbeit wird wieder per Git ins Repository zurückgeschoben (push). Dort startet automatisch ein Continuous Integration Build. Nebenbei können Sie Ihre Arbeit noch mit Visual Studio Online und zum Beispiel dem Scrum- Template strukturieren, koordinieren und überwachen. Das ist echter Luxus für lau. Eine sehr interessante Perspektive. [tib] [1] Patrick Speidel, Monaco ganz ohne Franz, dotnetpro 3/2014, S. 36, [2] Visual Studio Online, [3] Windows Azure Mangement Console,