Die Web-API und die Blazor-Seiten laufen bisher auf Ihrem Rechner. Für den Pilot müssen sie im Netz stehen, für Frau Aydin und die Pilotgruppe, mit Anmeldung und mit der Datenbank in Azure SQL aus Lektion M3.4. Diese Lektion bringt sie nach Azure, auf Azure Container Apps. Weil K3 das Handwerk dafür schon lehrt, steht hier nur, was am Auftragsbuch besonders ist, und wo K3 gilt, verweist die Lektion darauf.
| Thema | Steht in | Was das Auftragsbuch daraus macht |
|---|---|---|
| Azure im Überblick, Ressourcengruppen, Kosten | K3, Modul 3.1 | Sie kennen sie; die Lektion setzt Gruppe und Umgebung voraus |
| Bicep, Module, azd | K3, Modul 3.2 („Die Sprache Bicep“, „azd: die Anwendung und ihre Infrastruktur“) | ein Modul für die Container App mit den Einstellungen des Auftragsbuchs |
| Verwaltete Identität, Key Vault | K3, Modul 3.3 („Keine Schlüssel: Managed Identity“, „Key Vault“) | die Identität bekommt die Rolle aus Lektion M3.3, nicht mehr |
| Pipeline, Tests im Build, Ausliefern ohne Geheimnis | K3, Modul 3.7 | die Reihenfolge im Doppelbetrieb: erst das Schema, dann der Code |
| Schema ändern, während die alte Version läuft | K3, Modul 3.6 („Das Schema ändern, während die alte Version läuft“) | Expand and Contract aus Lektion M3.3 |
Was ausgeliefert wird, und was nicht
Ausgeliefert werden zwei Anwendungen: die Web-API Brandt.Auftragsbuch.Api und die Blazor-Web-App Brandt.Auftragsbuch.Web. Das Windows-Programm gehört nicht dazu: Es läuft auf den Rechnern der Firma und hat seinen eigenen Weg
(Lektion M2.5). Dazu bleibt der alte Weg im Doppelbetrieb am Leben: Er benutzt dieselbe Datenbank und darf von keiner Auslieferung gestört werden. Daraus folgen drei Dinge, die die Lektion aufgreift. Die Anwendung steht hinter einem
Ingress, der TLS beendet, und die Anmeldung muss damit zurechtkommen. Die Anwendung greift ohne Kennwort auf die Datenbank zu. Und jede Auslieferung nimmt Rücksicht auf ein Programm, das sie nicht kennt.