Deployment rhythm
When I am moving an application through Azure App Service, I want the commands arranged around intent instead of memorization. The sequence is usually: confirm target, inspect config, deploy, stream logs, verify health, and document what changed.
Quick commands I keep nearby
az login
az account show
az webapp list --resource-group <rg> --output table
az webapp show --resource-group <rg> --name <app>
az webapp config appsettings list --resource-group <rg> --name <app>
az webapp deployment slot list --resource-group <rg> --name <app>
az webapp log tail --resource-group <rg> --name <app>What matters during incident response
During a rough release, I care less about command trivia and more about whether I can answer four questions quickly: Did the right build land? Did configuration drift? Did the app restart cleanly? Are logs and health checks agreeing with each other?
- Inspect slot assignments before and after swaps.
- Confirm app settings and connection strings in the active slot.
- Stream logs immediately after deployment to catch startup failures.
- Compare health endpoint behavior with telemetry and request timing.
Operational calm under pressure
The strongest release process is the one that stays composed, leaves a trace, and makes the next diagnosis easier than the last one. Good operational design is part of good product engineering.