Setup Dotnet Azure Site

Setup .NET Azure Deployment Site

Overview

Creates a complete new deployment environment (staging, QA, demo) for an existing .NET Azure-hosted app by analyzing production, provisioning the right Azure resources, detecting or creating GitHub Actions CI/CD, and wiring up per-environment secrets.

Core principle: Share what can be shared; skip what staging doesn't need. New databases can live on the existing production SQL server — no new server cost. Communication and email services can be referenced cross-resource-group at no extra cost. Data Factory and alert rules are almost never needed in staging.

Prerequisites

Before starting, confirm:

• az login — Azure CLI authenticated
• gh auth login — GitHub CLI authenticated
• Contributor access on the Azure subscription
• Admin access on the GitHub repository

Phase 1: Gather Information

Ask the user for these inputs upfront:

Derive resource names from environment name (confirm with user):

• Resource group: {product}-{env}-rg
• App prefix: {product}-{env}
• App URL: {product}-{env}.azurewebsites.net

Phase 2: Analyze Production

az resource list \
  --resource-group <prod-rg> \
  --query "[].{name:name, type:type, kind:kind}" \
  --output table

Phase 3: Resource Decision Matrix

For each resource type found in production, apply:

Confirm this plan with the user before running any commands.

Phase 4: Create Azure Resources

Resource Group

az group create --name <new-rg> --location <region>

App Service Plan

az appservice plan create \
  --name <prefix>-plan \
  --resource-group <new-rg> \
  --location <region> \
  --sku B1 \
  --is-linux    # omit for Windows-hosted apps

App Service (.NET)

az webapp create \
  --name <prefix>-app \
  --resource-group <new-rg> \
  --plan <prefix>-plan \
  --runtime "DOTNET|8"    # adjust to match target framework version

Function App (if present in production)

az storage account create \
  --name <prefix>store \
  --resource-group <new-rg> \
  --location <region> \
  --sku Standard_LRS

az functionapp create \
  --name <prefix>-func \
  --resource-group <new-rg> \
  --storage-account <prefix>store \
  --consumption-plan-location <region> \
  --runtime dotnet \
  --runtime-version 8 \
  --functions-version 4

SQL Databases

Ask the user which database strategy to use, then follow the matching path:

Option A — Copy production data + scrub:

# Copies land on the same server — no extra server cost
az sql db copy \
  --name <prod-db-name> \
  --resource-group <prod-rg> \
  --server <prod-sql-server> \
  --dest-name <prefix>-<db-name> \
  --dest-resource-group <prod-rg> \
  --dest-server <prod-sql-server>

After the copy completes, run environment-specific scrub scripts to anonymize or remove sensitive production data before anyone uses the staging environment.

Option B — Empty database + run migrations:

az sql db create \
  --server <prod-sql-server-name> \
  --resource-group <prod-rg> \    # databases belong to the server's resource group
  --name <prefix>-<db-name> \
  --service-objective S0

EF Core migrations can run automatically on first deploy if the app is configured for it, or manually after deploy: dotnet ef database update --connection "<conn-string>"

Get connection string (both options):

az sql db show-connection-string \
  --server <prod-sql-server-name> \
  --name <prefix>-<db-name> \
  --client ado.net

Application Insights

az monitor app-insights component create \
  --app <prefix>-insights \
  --resource-group <new-rg> \
  --location <region>

az monitor app-insights component show \
  --app <prefix>-insights \
  --resource-group <new-rg> \
  --query connectionString -o tsv

App Settings (Connection Strings + Config)

az webapp config appsettings set \
  --name <prefix>-app \
  --resource-group <new-rg> \
  --settings \
    "APPLICATIONINSIGHTS_CONNECTION_STRING=<conn-str>" \
    "ASPNETCORE_ENVIRONMENT=Staging"
    # Add database connection strings and any other required config keys here

Service Principal for GitHub Actions

az ad sp create-for-rbac \
  --name <prefix>-deploy-sp \
  --role Contributor \
  --scopes /subscriptions/<subscription-id>/resourceGroups/<new-rg> \
  --sdk-auth

Save the full JSON output — this becomes AZURE_CREDENTIALS in GitHub.

Phase 5: GitHub Setup

Create Branch

git checkout <base-branch> && git pull
git checkout -b <new-branch>
git push -u origin <new-branch>

Detect Existing CI/CD

Before creating a workflow, check what already exists:

ls .github/workflows/

• No workflows directory / empty → Create .github/workflows/deploy.yml using references/workflow-dotnet.yml as the template
• Workflow file(s) exist → Open the existing deploy workflow, add <new-branch> to the on.push.branches list; a matching GitHub Environment (created below) will supply the correct secrets automatically

Create GitHub Environment + Secrets

Critical: Use GitHub Environments — not repo-level secrets. When one repo deploys to multiple branches from the same workflow, repo-level secrets are shared across all branches, meaning every push deploys to the same Azure site regardless of branch. GitHub Environments give each branch its own isolated secret set. The branch name must exactly match the GitHub Environment name.

# Create the environment
gh api repos/<owner>/<repo>/environments/<new-branch> --method PUT

# Secrets scoped to this environment only
gh secret set AZURE_CREDENTIALS      --env <new-branch> --body '<service-principal-json>'
gh secret set AZURE_WEBAPP_NAME      --env <new-branch> --body '<prefix>-app'
gh secret set AZURE_RESOURCE_GROUP   --env <new-branch> --body '<new-rg>'
gh secret set AZURE_FUNCTIONAPP_NAME --env <new-branch> --body '<prefix>-func'
# Add any app-specific secrets (API keys, third-party credentials, etc.)

In the workflow, environment: ${{ github.ref_name }} auto-selects the matching environment and loads its secrets based on the branch being pushed — no changes to the workflow file needed when adding future environments.

Workflow File

See references/workflow-dotnet.yml for the complete template. Key points:

• Run dotnet publish before deploying — use package: ./publish, not package: .
• FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true suppresses Node.js 20 deprecation warnings in logs

Phase 6: Verify

# Stream startup logs to catch config errors immediately
az webapp log tail --name <prefix>-app --resource-group <new-rg>

1. Push a commit to the new branch — watch the GitHub Actions run complete
2. Open the App Service URL and confirm the app loads
3. Confirm Application Insights receives telemetry
4. Verify database connectivity through normal app behavior

Common Pitfalls

Cost Estimate

Typical per-environment cost (adjust for your region):