AI can make deploying and upgrading Blazor Blogs much easier, but the best results come from using it as a careful deployment co-pilot rather than giving it unrestricted access. A good AI workflow prepares, validates, deploys, verifies, and records evidence at every step.

Start with the right prompt

Be specific about the target and the outcome. A useful request should include the application, Azure resource group, App Service name, release version, and the requirement to preserve existing data.

Deploy the current Blazor Blogs 10.06.00 release to my production App Service. First back up the live site files and database, publish a self-contained Windows package, deploy with cleanup disabled, apply only pending schema scripts, verify the site and protected content, and delete temporary backup artifacts after successful verification.

Ask the AI to show a plan before it changes production. If the assistant has deployment-planning tools, require it to complete the preparation and validation workflow before execution.

Give AI access without giving away secrets

Open the project in the AI-enabled editor and authenticate with the deployment tools you already trust. Give the assistant access to the repository and the selected Azure subscription, but do not paste passwords, connection strings, publish profiles, Stripe keys, or Google OAuth secrets into chat.

Blazor Blogs supports appsettings.Local.json for local connection settings. That file is excluded from Git and should remain outside source control. Production connection strings can also be supplied through environment or App Service configuration.

Ask AI to inspect before it acts

A strong assistant should verify all of the following before deployment:

  • The current Git branch and release version.
  • Whether the working tree contains unrelated or uncommitted changes.
  • The exact Azure subscription, resource group, App Service, runtime, and region.
  • Whether deployment slots, custom domains, or special application settings exist.
  • The current database schema version and where persistent uploads, blog files, and downloads are stored.
  • That tests and the Release build pass.

Back up before every update

Tell AI that backup is a mandatory deployment gate, not an optional cleanup task. The backup should include:

  • The live App Service site files, including wwwroot/uploads, wwwroot/blogs, wwwroot/files, and private download files.
  • The production database as a BACPAC or supported native backup.
  • App Service configuration and the connection-source information needed for rollback.

The assistant should stop if it cannot prove that the database backup exists before it applies schema scripts. For a production site, a source-control snapshot is not a database backup.

Use the repository deployment path

For a code-only update, use the repository's deployment script rather than asking AI to invent a new process:

./deploy/Deploy-Website.ps1 -ResourceGroup <resource-group> -WebsiteName <site>

The script publishes a Release package, rejects protected user-content folders from the publish output, and uses Azure ZIP deployment with cleanup disabled. That design keeps existing uploads, images, downloads, and local settings in place.

For an Aspire-managed installation, ask AI to review the deployment graph first and then use the supported Aspire workflow:

aspire publish --non-interactive
aspire deploy

Validate the package before upload

A good AI deployment should not upload immediately after a build. Ask it to confirm:

  • The project targets the intended framework.
  • All automated tests pass.
  • The Release publish succeeds.
  • The package contains no uploads, blog images, private downloads, local settings, or secrets.
  • The deployment uses the intended App Service and subscription.
  • Any Azure policy or authentication issue is resolved.

Upgrade the database safely

After the application files are deployed, Blazor Blogs can guide an administrator through the pending database updates. For an automated deployment, the assistant should read the stored version and run only scripts newer than that version, in order.

Do not ask AI to drop tables, recreate the database, or replay old scripts blindly. The standard Blazor Blogs upgrade process is incremental and is designed to preserve existing rows.

Verify the deployment

The update is not complete when the ZIP upload reports success. Ask AI to verify:

  • The App Service is Running.
  • The home page, RSS feed, login, and downloads routes return HTTP 200.
  • The database reports the expected schema version.
  • Existing posts, categories, users, files, and settings still exist.
  • Protected files are present and byte-for-byte unchanged.
  • Custom domains, HTTPS, and important application settings still work.

If the AI cannot verify one of these checks, it should stop and report the exact failure rather than claiming success.

Keep rollback available until verification finishes

For a code-only problem, redeploy the captured pre-update site ZIP. Do not delete rollback files until the site, database, and content checks have passed. Database changes are normally forward-only, so a database backup must be available before the first schema update.

For a public repository, temporary backups, BACPACs, local configuration files, and deployment packages must never be committed. Remove them after verification and confirm the Git working tree contains no generated secrets or production data.

A good AI deployment checklist

  1. Inspect the repository and exact Azure target.
  2. Create and show the deployment plan.
  3. Get explicit approval before changing production.
  4. Run tests, build, and package-safety checks.
  5. Back up the site and database.
  6. Deploy with --clean false.
  7. Apply only pending schema scripts.
  8. Verify routes, records, settings, and protected files.
  9. Keep rollback artifacts until verification passes.
  10. Delete temporary artifacts and record the final evidence.

The operator remains responsible

AI is excellent at running repeatable checks, collecting evidence, and handling long deployment sequences. It should not be trusted to guess between production and test resources, expose credentials, delete infrastructure, reset a database, or silently bypass a failed check.

Use AI to make deployments more repeatable and safer: require a plan, require backups, review destructive operations, preserve user content, and verify measurable results. That combination lets you move quickly without giving up control of your production website.