The web API and the Blazor pages have so far run on your machine. For the pilot they have to be on the network, for Ms. Aydin and the pilot group, with sign-in and with the database in Azure SQL from lesson M3.4. This lesson brings them to Azure, to Azure Container Apps. Because K3 already teaches the craft for that, this lesson covers only what is special about the Order Book, and where K3 applies, the lesson points to it.
| Topic | Covered in | What the Order Book makes of it |
|---|---|---|
| Azure at a glance, resource groups, costs | K3, module 3.1 | You know them; the lesson assumes the group and the environment |
| Bicep, modules, azd | K3, module 3.2 (“The Bicep language”, “azd: the application and its infrastructure”) | one module for the container app with the settings of the Order Book |
| Managed identity, Key Vault | K3, module 3.3 (“No keys: managed identity”, “Key Vault”) | the identity gets the role from lesson M3.3, nothing more |
| Pipeline, tests in the build, delivering without a secret | K3, module 3.7 | the order during dual running: the schema first, then the code |
| Changing the schema while the old version runs | K3, module 3.6 (“Changing the schema while the old version runs”) | expand and contract from lesson M3.3 |
What gets shipped, and what does not
Two applications are shipped: the web API Brandt.OrderBook.Api and the Blazor web app Brandt.OrderBook.Web. The Windows program is not part of it: It runs on the company's machines and has its own route
(lesson M2.5). In addition, the old route stays alive during dual running: It uses the same database and must not be disturbed by any deployment. Three things follow from this, and the lesson takes them up. The application sits behind an
ingress that terminates TLS, and sign-in has to cope with that. The application reaches the database without a password. And every deployment takes into account a program that it does not know.