Lehrziele

• ASP.NET Core Razor Pages
• ASP.NET Core WebApi
• Entity Framework Core
• Unit of Work / Repositories
• Validierung
• Azure Grundlagen
• Azure Web App
• Azure DevOps
• Azure Build Pipelines
• Azure Release Pipelines

Allgemeines

Es ist eine einfache Anwendung zur Verwaltung von Sensoren un deren Messwerte gegegeben. Diese lokal lauffährige Anwednung (Web API und Web App) soll nun per Continuous Integration und Continuous Deliviery gebaut und ausgeliefert werden. Somit können kurze Release Zyklen eingehalten werden was die Kennzahl time to market für neue Features drastisch reduziert.

Die Grundfunktionalität ist bereits implementiert und befindet sich im Ordner source/

Überblick

Core

Die Entitätsklassen sind bereits angelegt. Auch die Annotationen zur Definition (inkl. der Migrationen) der Datenbank sind bereits implementiert.

Import / Persistence

Die einzelnen Zeilen der csv-Datei werden verarbeitet sodass am Schluss eine Collection von Measurements mit ihren Sensoren zurückgegeben wird.

Die Migration wurde bereits angelegt und muss nur verwendet werden, wenn an den Entitätsklassen Änderungen vorgenommen werden:

• Persistence als StartupProject
• Add-Migration InitialMigration
• UpdateDatabase mit Kontrolle, ob DB angelegt wurde
• Die Daten über die ImportConsole importieren.

Die ConnectionStrings wurden in den relevanten Projekten schon in der appSettings.json festgelegt.

ASP.NET Core Razor Pages (SmartSchool.Web)

Die Web App besteht aus folgenden Seiten.

Page "Index"

Anforderungen:

• Anzeige der Sensoren
  • Sortierung nach Name und Location
• Dritte Spalte enthält die Anzahl der Messungen für den Sensor
  • Nicht alle Messwerte aus der Datenbank laden!
• Der Name führt als Link zu einer Übersicht der Messwerte für den Sensor
• Der Link "Edit Sensor" verweist auf eine Bearbeitungsseite für den Sensor

Page "Members/Edit"

Anforderungen:

• Funktionalität
  • Name, Unit und Location können geändert werden
• Validierungen
  • Siehe nächste Überschrift
  • Es sind entsprechende Fehlermeldungen beim fehlerhaften Feld auszugeben
• "Save" führt zur Überblicksseite des Sensors mit den letzten 20 Messungen
• "Back to List" führt wieder auf die Hauptseite

Nach dem Anlegen kontrollieren Sie das Ergebnis über die Hauptseite.

Validierung

1. Name (Pflichtfeld)
2. Location (Pflichtfeld)

Zusätzliche Validierung (Spezialistenaufgabe)

1. Es dürfen keine zwei Sensoren mit dem gleichen Namen und der gleichen Location existieren!

Page "Sensors/List?id=7"

Diese Seite erreicht man über den Namenslink (1. Spalte) der Hauptseite.

Neben den Stammdaten des Sensors sind die letzten 20 Messwerte inklusive Zeit, Wert und Einheit auszugeben.

ASP.NET WebApi (SmartSchool.Web)

Es sind bereits folgende API-Controller implementiert.

Route /api/measurements/id

• Die Struktur der Daten entnehmen Sie dem Musterausdruck:

  

• Sollte die id nicht existieren, ist NotFound zurückzugeben

  

Route /api/measurements/measurementat

• Liefert für den Sensor den zu der Zeit gültigen Wert

• SensorId 5: 20.10.2018 13:00

  

• SensorId 5: 20.10.2018 12:59:16

  

• SensorId 5: 20.10.2018 12:59:17

  

• SensorId 5: 20.10.2017 13:00

  

Post-Route /api/measurements

• Erzeugt für den Sensor einen neuen Messwert

  

  

• Zeit darf nicht in der Zukunft liegen

  

• Ungültige SensorId liefert NotFound

Route /api/sensors

• Liefert die Sensornamen alphabetisch sortiert

  

Route /api/sensors/id

• Liefert die Sensordaten (entsprechend Muster)

  

• Gibt es die id nicht, wird NotFound geliefert

  

Route /api/sensors/countofmeasurements

• Liefert die Sensordaten (entsprechend Muster) und die Anzahl der Messungen je Sensor

• Sortiert nach Sensorname und Location

• Es sind möglichst wenige Daten von der Datenbank zu laden

• Die Dauer der Abfrage ist zu optimieren

  

Route /api/sensors/averagevalues

• Liefert die Sensordaten (entsprechend Muster) und den Durchschnitt der Messwerte je Sensor

• Sortiert nach Sensorname und Location

• Es sind möglichst wenige Daten von der Datenbank zu laden

• Die Dauer der Abfrage ist zu optimieren

  

Vorbereitung

Microsoft bietet neben GitHub, welches hauptsächlich zum Verwalten von Open Source Projekten verwendet wird auch Azure DevOps an.

Aufgaben

1. Melden Sie sich bei Azure DevOps mit ihrem <IhrName>@htblaleonding.onmicrosoft.com Benutzer an.

2. Erstellen Sie ein neues Projekt:

   

   • Name: SmartSchool-Azure
   • Visiblity: Public

   

3. Klonen Sie das (leere) Azure DevOps Projekt in Visual Studio

   

   • Wählen Sie in Visual Studio ihren <IhrName>@htblaleonding.onmicrosoft.com Benutzer aus.
   • Wählen Sie den lokalen Pfad aus, wohin das Projekt geklont werden soll (z.B.: c:\HTL\SmartSchool-Azure).

4. Übernehmen Sie die bereits fertige Implementierung source/ in das geklonte lokale Projektverzeichnis (z.B.: c:\HTL\SmartSchool-Azure).

5. Öffnen Sie die Solution SmartSchool.sln in Visual Studio.

6. In Visual Studio sollten Sie nun folgende Darstellung haben:

   

7. Vorbereitung der lokalen Datenbank

   1. Definieren Sie das Projekt SmartSchool.ImportConsole als Startup Project

   2. Starten Sie das Projekt SmartSchool.ImportConsole per F5

   3. Folgende Ausgabe sollte ersichtlich sein:

      

8. Starten der Web App bzw. der Web Api

   1. Definieren Sie das Projekt SmartSchool.Web als Startup Project

   2. Starten Sie das Projekt SmartSchool.Web per F5

   3. Folgende Ausgabe sollte ersichtlich sein:

      

   4. Beim Klick auf API in der Navigationsleiste oben solle folgende Ausgabe ersichtlich sein:

      

9. Commiten und pushen sie die Änderungen in das Azure DevOps Projekt

Continuous Integration

Die Web App bzw. die Web Api (Swagger) sollten wie in den Screenshots dargestellt aufgerufen werden. Erst danach können die folgende Punkte des Tutorials durchgeführt werden!

Unter Continuous Integration versteht man die fortlaufende und permanente Zusammenführung aller Komponenten zur kompletten Anwendung.

Dh. dass bei jeglicher Code-Änderung (Push in das Git-Repository) ein Compile- und Testzyklus durchlaufen wird und am Ende als Resultat die ausführbare Anwendung als Artefakt hinterlegt wird. Auf diesem hinterlegten Artefakt setzt dann im Anschluss Continuous Deliviery auf - siehe dazu dann das nächste Kapitel.

Aufgaben

1. Melden Sie sich bei Azure DevOps mit ihrem <IhrName>@htblaleonding.onmicrosoft.com Benutzer an.

2. Navigieren Sie im Projekt SmartSchool-Azure zum Abschnitt Pipelines:

   

3. Erstellen Sie eine neue Pipeline:

   

4. Wählen Sie die Quelle für ihren Source Code aus - in diesem Fall Azure Repos Git:

   

5. Wählen Sie das Repository aus - in diesem Fall SmartSchool-Azure:

   

6. Wählen Sie die Vorlage für ihre Pipeline aus - in diesem Fall Starter pipeline:

   

7. Bennen Sie die Pipeline 'build-all.yml' und ersetzen Sie die Vorlage mit folgendem Code (Source zum Kopieren finden Sie unten):

   

   1. Der Trigger legt fest wann die Pipeline ausgeführt werden soll Details. In diesem Fall wird die Pipeline bei jedem Push auf den master Branch ausgeführt.

   2. Der Pool legt die Umgebung fest in welcher die Pipeline ausgeführt werden soll Details. In diesem Fall ist dies ein Windows Server 2019 (windows-latest).

   3. Im Abschnitt Variables können Variablen definiert werden, welche im Weiteren dann verwendet werden können.

   4. Dieser Step stellt sicher, dass das Werkzeug NuGet zur Verfügung steht.

   5. In diesem Schritt werden die NuGet-Pakete, welche in den einzelnen Projekten definiert sind geladen.

   6. Nun wird die gesamte Solution kompiliert.

   7. In diesem Schritt werden die Unit Tests durchgeführt.

   8. Hier wird die Datei .runsettings in das Staging-Verezichnis kopiert. Dorthin werden alle Dateien kopiert, welche im letzten Schritt (9) dann als Build Artefakt veröffentlicht werden sollen.

   9. Abschließend werden alle Dateien aus dem Staging-Verzeichnis als Build Artefakt veröffentlicht. Diese Artefakte dienen als Basis für die Auslieferung in der Release Pipeline.

   Source:

   trigger:
    - master
   
   pool:
      vmImage: 'windows-latest'
   
   variables:
      solution: '**/*.sln'
      buildPlatform: 'Any CPU'
      buildConfiguration: 'Release'
   
   steps:
    - task: NuGetToolInstaller@1
      displayName: NuGet (Installation)
   
    - task: NuGetCommand@2
      displayName: NuGet (Restore)
      inputs:
        restoreSolution: '$(solution)'
   
    - task: VSBuild@1
      displayName: Build Solution
      inputs:
        solution: '$(solution)'
        msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:DesktopBuildPackageLocation="$(build.artifactStagingDirectory)\WebApp\WebApp.zip" /p:DeployIisAppPath="Default Web Site" /p:GenerateDocumentation=true'
        platform: '$(buildPlatform)'
        configuration: '$(buildConfiguration)'
   
    - task: DotNetCoreCLI@2
      displayName: 'Run Unit Tests'
      inputs:
        command: 'test'
        arguments: '--no-build --configuration $(buildConfiguration)'
        publishTestResults: true
        projects: '**/SmartSchool.Test.csproj'
   
    - task: CopyFiles@2
      displayName: Copy Test Configuration
      inputs:
        SourceFolder: '$(Build.SourcesDirectory)'
        Contents: '**/*.runsettings'
        TargetFolder: '$(build.artifactStagingDirectory)'
   
    - task: PublishBuildArtifacts@1
      displayName: Publish SmartSchool.Web as Build Artefact
      inputs:
        artifactName: drop

8. Führen Sie die Pipline rechts oben per Run aus.

9. Während der Ausführung der Pipline können Sie sich die Logs der einzelnen Scrhitte anzeigen lassen:

   

10. Nachdem die Pipeline ausgeführt wurde sehen Sie folgendes Ergebnis:

    

    Sie sehen einerseits, dass alle Schritte der Build Pipline erfolgreich durchgeführt wurden, sowei der kompilierte Code aus dem master-Branch stammt, genau ein Build Artefakt erzeugt/veröffentlicht wurde und dass alle Tests (100%) erfolgreich durchgeführt wurden.

Continuous Delivery

Die Build-Pipeline muss erfolgreich durchlaufen werden. Erst danach können die folgende Punkte des Tutorials durchgeführt werden!

Auf Basis der kompilierten Artefakte (Web App mit Razor Pages und die Web Api) kann nun eine Auslieferung erfolgen. Sollte bei jedem Build eine Auslieferung erfolgen so spricht man von Continuous Deliviery.

Aufgaben

1. Melden Sie sich im Azure Portal mit ihrem <IhrName>@htblaleonding.onmicrosoft.com Benutzer an.

2. Wechseln Sie rechts oben auf das Standardverzeichnis:

   

3. Dort sollten Sie eine Resource Group mit ihrem Namen finden, in welcher Sie nun die in Azure gehostete Web-Site konfigurieren werden.

   Hinweis: Eine Resource Group stellt einen Behälter dar, in welchem verschiedenste Azure Services zusammengefasst werden können.

   

4. Wählen Sie ihre Resource Group aus und klicken Sie auf Add:

   

5. Suchen Sie nach dem Service Web App

6. Legen Sie folgende Konfiguration für ihre neue Web App fest:

   

   Bei Punkt (1) ist wichtig, dass Sie anstatt smartschool-jf hinten ihr Kürzel anstatt -jf verwenden!

7. Analog zur Web App für die Produktivumgebung legen Sie auch eine Web App für die Staging Umgebung an:

   

   Bei Punkt (1) ist wichtig, dass Sie anstatt smartschool-jf-staging ihr Kürzel anstatt -jf- verwenden!

8. Konfiguration der erstellten Web App Services (smartschool-jf-staging und smartschool-jf)

   1. Connection String für die Verbindung zur Datenbank in beiden Web App Services konfigurieren:

      

      Bezeichnung	Wert
      Name	DefaultConnection
      Value	Server=tcp:htl-samples.database.windows.net,1433;Initial Catalog=SmartSchoolAzure;Persist Security Info=False;User ID=appuser;Password=htlleonding2020#;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
      Type	SQLAzure

      

   2. ASPNETCORE_ENVIRONMENT Application Setting in der Staging Web App konfigurieren - somit werden detailierte Fehlermeldungen ausgegeben:

      

      Bezeichnung	Wert
      Name	ASPNETCORE_ENVIRONMENT
      Value	Development

9. Melden Sie sich bei Azure DevOps mit ihrem <IhrName>@htblaleonding.onmicrosoft.com Benutzer an.

10. Navigieren Sie im Projekt SmartSchool-Azure zum Abschnitt Pipelines:

    

11. Erstellen Sie eine neue Pipeline:

    

12. Wählen Sie als Vorlage Empty job aus:

    

13. Benennen Sie ihre Release Pipeline auf Deployment um:

    

14. Konfigurieren Sie das Build Artefact welches als Basis für ihr Deployment dienen soll:

    

15. Trigger für das Deployment konfigurieren:

    

    Mit diesem Trigger wird bei jedem erfolgreichem Build die Release Pipeline für die Auslieferung angestoßen.

16. Konfigurieren Sie die Auslieferung in die Staging Umgebung:

    

17. Legen Sie fest in welche Web App die gebauten Artefakte ausgeliefert werden sollen:

    

18. Dupliziern Sie die Staging Stage und nennen Sie sie Production:

    

    Mit dieser Stage wird nach dem Deployment in die Staging Umgebung auch ein Deployment in die Produktivumgebung durchgeführt.

19. Festlegen eines Pre deployment approvals für die Production Stage:

    

    Dies hat den Grund, dass eine Persion das Deployment auf die Produktivumgebung freigeben muss.

20. Manuelles Deployment durchführen:

    

    Die Release Pipeline ist liefert standardmäßig nun jedes mal in die Staging- bzw. Production-Umgebung aus, sobald ein neuer Build vorhanden ist. Zum Testen kann auch manuell ein Release erstellt werden. Das Erstellen eines Releases ist gleichbedeutend mit dem Anfordern einer Auslieferung.

21. Staging Umgebung auf korrekte Funktionalität prüfen:

    

22. Nach dem Staging-Deployment wird nun in die Production-Umgebung ausliefern:

    

23. Staging Umgebung auf korrekte Funktionalität prüfen:

    

24. Ansicht des Release nach dem Deployment:

    

    Somit ist das Release-1 in beiden Umgebungen (Staging und Production) sauber ausgeliefert.

Zusammenfassung

Nun ist es möglich eine neue Anforderung per Code-Ändeurng und anschließendem Commit/Push in die Staging- bzw. im Anschluß in die Production-Umgebung auszuliefern.

Dieses Diagram fasst die einzelnen Schritte zusammen: