Consolidate Azure Bicep deployment path and preserve App Service settings

[srkirkland]

Context

We found two Bicep entrypoints in the repo:

• infrastructure/azure/main.bicep
• web/deploy/main.bicep

The existing production Azure resource group rg-walter-prod in subscription 003283b1-cc5e-417a-b037-01ff3c05537b was created by the newer infrastructure/azure path, not by the older web/deploy path.

Azure deployment evidence from rg-walter-prod:

• Deployment: walter-walter-production-20260330163541
• Parameters: appName=walter, env=production, linuxFxVersion=DOTNETCORE|8.0
• App Service Plan: /subscriptions/003283b1-cc5e-417a-b037-01ff3c05537b/resourceGroups/Shared/providers/Microsoft.Web/serverFarms/Petunia
• Outputs:
  • Web App: web-walter-production-dfvhbu
  • SQL Server: sql-walter-production-dfvhbu
  • SQL Database: walter

Those generated names match infrastructure/azure/main.bicep, which builds names as web-<appName>-<env>-<token> and sql-<appName>-<env>-<token>. The older web/deploy template/scripts use explicit names like walter and walter-test, so they are not compatible with the current prod resource names.

Current risks

1. web/deploy is legacy/confusing

   The web/deploy/test/run-deploy.sh and web/deploy/production/run-deploy.sh scripts still point at web/deploy/main.bicep, use explicit resource names, and contain hard-coded SQL password values. Keeping these scripts around makes it unclear which infrastructure path should be used.

2. Re-running current infrastructure Bicep may overwrite App Service settings

   Current prod App Service settings include names such as:

   • Auth__ClientSecret
   • DB_CONNECTION
   • DM_CONNECTION
   • Financial__ApiUrl
   • Financial__ConsumerKey
   • Financial__ConsumerSecret
   • Financial__ScopeApp
   • Financial__ScopeEnv
   • Financial__TokenEndpoint
   • Iam__ApiKey
   • OTEL_EXPORTER_OTLP_ENDPOINT
   • OTEL_EXPORTER_OTLP_HEADERS
   • OTEL_EXPORTER_OTLP_PROTOCOL
   • OTEL_RESOURCE_ATTRIBUTES
   • WEBSITE_HTTPLOGGING_RETENTION_DAYS

   infrastructure/azure/modules/webapp.bicep currently writes Microsoft.Web/sites/config appsettings using only the appSettings object passed by the template. That could delete settings managed outside Bicep.

3. Deployment history exposes generated DB_CONNECTION

   Although sqlAdminPassword is a secure parameter, the composed DB_CONNECTION is passed into the nested web deployment as part of a plain object parameter. Azure deployment history for the nested web deployment can therefore show the connection string, including the SQL password. Do not copy the exposed value into the repo or issue comments.

Recommended direction

Use infrastructure/azure going forward and retire/archive the old web/deploy Bicep path.

For compatibility with existing prod, future deployments must preserve these identity inputs:

• Subscription: 003283b1-cc5e-417a-b037-01ff3c05537b
• Resource group: rg-walter-prod
• appName=walter
• env=production

Changing env to prod, omitting env, changing the resource group, or changing appName would generate different resource names.

What to build

Clean up the Azure IaC so infrastructure/azure is the single supported deployment path and App Service settings are not accidentally overwritten or leaked through deployment history.

Acceptance criteria

• web/deploy is removed, archived, or replaced with documentation pointing to infrastructure/azure as the supported IaC path.
• Documentation explains that prod currently maps to appName=walter and env=production, producing web-walter-production-dfvhbu and sql-walter-production-dfvhbu in rg-walter-prod.
• The infrastructure deployment preserves existing App Service settings that are managed outside Bicep.
• The generated database connection string is not exposed as a plain nested deployment parameter in Azure deployment history.
• The resulting deployment path supports what-if before applying changes.
• The SQL admin password should be rotated if the exposed deployment-history value is still valid.

Notes

One likely implementation path is to make the web module merge desired settings with existing App Service settings, or to stop managing app settings in Bicep and let Azure DevOps, Key Vault, or another configuration owner manage them. If Bicep continues to set DB_CONNECTION, ensure the parameter flow stays secure and does not surface the full connection string in deployment history.