Azure与Visual Studio Online多环境发布管理技术咨询

Hey Sam, let’s walk through your questions one by one—this is a standard setup I’ve implemented multiple times, so I’ll share hands-on, actionable advice tailored to your stack.

1. Azure Resource Configuration: Slots vs. Separate App Services, and SQL Server Setup #

Let’s break this down by resource type:

App Service Decision #

• Deployment Slots are perfect for Staging to Production workflows: They let you deploy to a staging slot, run validation, then swap to production with zero downtime. This is ideal for pre-production environments that need to mirror production closely.
• Separate App Services are better for Dev, QA, and early-stage environments: These environments often need independent configurations (like lower pricing tiers, custom scaling rules, or isolated resources). Separate App Services also prevent accidental cross-environment interference (e.g., a Dev deployment breaking QA).
• My Recommendation: Use separate App Services for Dev/QA, and deployment slots on your Production App Service for Staging → Prod swaps.

SQL Server/Database Decision #

• Dev/QA Environments: You can safely use a single SQL Server with multiple databases (one per environment). This saves cost and simplifies management—just ensure each database has its own credentials and access controls.
• Production Environment: Always use a separate dedicated SQL Server for production. This ensures isolation for security, performance, and compliance reasons. You don’t want a Dev/QA database issue affecting production.
• Bonus Tip: For QA, consider using an anonymized copy of production data to make integration tests more realistic.

2. Visual Studio Online (VSO) Task Configuration #

Build Stage Best Practices #

• Build Configuration: Use the Release configuration for your build—this ensures you’re generating optimized, production-ready artifacts. Avoid environment-specific builds (like Dev or QA) here; keep your build artifact environment-agnostic.
• Database Project Management: In the build stage, add a task to build your database project and generate a Dacpac file. This artifact will be used in the release stage to deploy to each environment’s database.
• Build Tasks Order: Stick to this flow:
  • NuGet Restore (pull all dependencies)
  • Build Solution (target your ASP.NET and database projects)
  • Run Unit Tests (fast, isolated tests—no database connection needed)
  • Publish Web App (generate a zip artifact for deployment)
  • Publish Database Project (generate the Dacpac)

Release Stage Setup #

• Database Deployment: Yes, deploy databases in the release stage—this lets you target each environment’s specific database. Use the Azure SQL Database Deployment task in VSO, pointing to the Dacpac from your build artifact.
• Connection String Management:
  • Web App: Don’t hardcode connection strings in web.config. Instead, use App Service Application Settings in Azure—these automatically override web.config values. In your VSO release task, set these values using environment-specific variables (store them in VSO Variable Groups for easy management).
  • Database Deployment: Use VSO variables to pass the target database connection string to the Azure SQL Database Deployment task. Store these variables in secure variable groups (mark them as secret to protect credentials).

3. Testing & Test Plans Integration #

When to Run Tests #

• Unit Tests: Run these in the build stage—they’re fast, don’t depend on external resources, and catch issues early before artifacts are generated.
• Integration Tests (including database tests): Run these in the release stage, right after deploying to an environment (like Dev or QA). These tests need to connect to the real environment’s database and services, so they have to run post-deployment.

Modifying Connection Strings for Tests (No app.config Transform) #

If your test project doesn’t use app.config transforms, use VSO’s Variable Substitution feature:

1. In your test project’s app.config, replace connection strings with placeholder values like $(TestDbConnectionString).
2. In your VSO release definition, create environment-specific variables (e.g., TestDbConnectionString for Dev, QA, etc.).
3. Enable variable substitution in the test run task—VSO will automatically replace the placeholders with the environment-specific values.

What’s the Role of Test Plans? #

VSO Test Plans are your centralized hub for managing:

• Test Cases: Define manual or automated test cases for your application.
• Test Execution: Trigger test runs after deploying to an environment (e.g., after deploying to QA, kick off a test plan run).
• Defect Tracking: Link failed tests directly to work items (like bugs) in VSO.
• Gatekeeping: Use test plan results as a gate in your release pipeline—block deployment to Staging/Prod if tests fail.

内容的提问来源于stack exchange，提问作者Sam