通过Azure DevOps实现ASP.NET Core项目的持续集成与部署

通过Azure DevOps实现ASP.NET Core项目的持续集成与部署：从代码提交到云端发布的全自动化流水线

作为一名常年与.NET技术栈打交道的开发者，我深知手动编译、打包、部署的繁琐与低效。在尝试了多种CI/CD工具后，Azure DevOps以其与Azure云服务的无缝集成、强大的流水线功能和灵活的配置，成为了我团队自动化部署的首选。今天，我就来分享一下如何为你的ASP.NET Core项目搭建一套高效、可靠的持续集成与部署（CI/CD）流水线，其中会穿插一些我实战中踩过的“坑”和总结的经验。

一、前期准备：项目与资源

在开始配置流水线之前，我们需要准备好“原材料”。首先，确保你有一个托管在Azure Repos、GitHub或其他Azure DevOps支持的仓库中的ASP.NET Core项目。其次，你需要一个Azure订阅，用于创建应用服务（App Service）作为部署目标。我强烈建议在项目根目录下添加一个 `Dockerfile`（如果你选择容器化部署）或仔细检查 `.csproj` 文件，确保SDK版本等配置明确，这能避免后续流水线中许多因环境差异导致的问题。

二、创建构建流水线（CI）

持续集成的核心是自动化构建和测试。登录你的Azure DevOps组织，进入项目，导航到“Pipelines” -> “Pipelines”，点击“Create Pipeline”。

1. 连接代码仓库：选择你的代码仓库位置（如Azure Repos Git）并授权。

2. 选择模板：对于ASP.NET Core项目，直接选择“Starter pipeline”或“ASP.NET Core”模板。系统会生成一个基础的 `azure-pipelines.yml` 文件。我的经验是，从模板开始，再根据项目需求定制，比完全手写更高效。

3. 配置构建任务：下面是一个我常用的、功能比较完整的 `azure-pipelines.yml` 构建阶段示例，它包含了还原、构建、测试、发布构建产物等关键步骤。

trigger:
- main  # 设置在main分支有推送时触发构建

pool:
  vmImage: 'ubuntu-latest'  # 也可以使用 'windows-latest'

variables:
  buildConfiguration: 'Release'
  dotnetSdkVersion: '8.x'  # 明确指定SDK版本，避免不兼容

steps:
- task: UseDotNet@2
  inputs:
    version: '$(dotnetSdkVersion)'
    includePreviewVersions: false  # 生产环境建议关闭预览版

- task: DotNetCoreCLI@2
  displayName: 'Restore NuGet packages'
  inputs:
    command: 'restore'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'Build the project'
  inputs:
    command: 'build'
    arguments: '--configuration $(buildConfiguration) --no-restore'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'Run Unit Tests'
  inputs:
    command: 'test'
    arguments: '--configuration $(buildConfiguration) --no-build --verbosity normal'
    projects: '**/*Tests.csproj'  # 确保模式能匹配到你的测试项目

- task: DotNetCoreCLI@2
  displayName: 'Publish artifacts'
  inputs:
    command: 'publish'
    arguments: '--configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory) --no-build'
    projects: '**/*.csproj'
    zipAfterPublish: true  # 这是一个非常实用的选项，会自动打包

- task: PublishBuildArtifacts@1
  displayName: 'Publish build artifact'
  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)'
    ArtifactName: 'drop'

踩坑提示： 注意 `projects` 参数的路径匹配。如果解决方案结构复杂（例如多个启动项目），可能需要更精确的路径。`zipAfterPublish: true` 能大大简化后续部署任务的配置，是我强烈推荐的做法。

三、配置发布流水线（CD）

构建成功后，我们需要将产物部署到Azure应用服务。在Azure DevOps中，这通常在“Releases”部分完成。

1. 创建发布流水线： 在“Releases”中点击“New pipeline”，选择“Azure App Service deployment”模板。

2. 链接构建产物： 在“Artifacts”区域，点击“Add an artifact”，选择你刚才创建的构建流水线产生的产物（通常叫“drop”）。记得开启持续部署触发器，这样每次构建成功就会自动创建发布。

3. 配置部署阶段： 点击“Stage 1”进行配置。最关键的一步是连接Azure订阅。

• 点击“Manage”链接，跳转到服务连接管理页面。
• 创建新的“Azure Resource Manager”服务连接，使用“Service principal (automatic)”方式授权。这个过程需要Azure租户管理员权限，如果遇到权限问题，这是第一个需要排查的点。

4. 填写部署参数： 回到阶段任务，选择刚刚创建的Azure服务连接、目标Azure订阅、以及对应的应用服务名称。其他参数如“Package or folder”通常保持默认 `$(System.DefaultWorkingDirectory)/**/*.zip` 即可，因为它会自动找到我们构建阶段生成的zip包。

实战经验： 对于生产环境，我强烈建议配置多阶段发布，例如“Dev -> Staging -> Production”，并在阶段间添加审批门控。在预生产环境（Staging）配置“部署槽位（Deployment Slot）”进行交换部署，可以实现零停机更新和快速回滚，这是保障线上服务稳定的黄金法则。

四、关键配置与优化技巧

1. 管理连接字符串与应用配置： 千万不要将生产环境数据库连接字符串等敏感信息硬编码在代码或配置文件中！Azure DevOps提供了“Variable Groups”和“Azure Key Vault”集成。在“Library”中创建变量组，将敏感信息设为密钥变量，然后在发布流水线中链接这个变量组。在部署任务中，可以通过“Application and Configuration Settings”将变量注入到应用服务的应用设置中，覆盖 `appsettings.json` 里的值。

2. 使用YAML定义多阶段流水线（进阶）： 新版本的Azure DevOps支持将整个CI/CD流程（构建+多环境发布）定义在一个YAML文件中，实现“Pipeline as Code”。这带来了版本化、可重复、易于代码评审的巨大优势。下面是一个简化的多阶段YAML流水线概念示例：

stages:
- stage: Build
  jobs:
  - job: BuildJob
    steps:
    # ... 上述构建步骤 ...
- stage: DeployToStaging
  dependsOn: Build
  condition: succeeded()
  jobs:
  - deployment: Deploy
    environment: 'staging'  # 与环境关联，便于跟踪
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureWebApp@1
            inputs:
              azureSubscription: 'Your-Service-Connection'
              appName: 'YourApp-Staging'
- stage: DeployToProduction
  dependsOn: DeployToStaging
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
  jobs:
  - deployment: Deploy
    environment: 'production'
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureWebApp@1
            inputs:
              azureSubscription: 'Your-Service-Connection'
              appName: 'YourApp-Production'

3. 监控与通知： 配置完成后，别忘了在发布流水线的每个阶段设置“Post-deployment conditions”，添加通知。可以配置在失败时发送邮件或Teams消息给团队，让我们能第一时间响应问题。

五、总结与排错思路

通过以上步骤，一个基本的ASP.NET Core项目自动化CI/CD流水线就搭建完成了。整个过程体现了“一次配置，终身受益”的DevOps理念。最后，分享几个常见的排错思路：

• 构建失败： 首先检查日志，最常见的原因是本地能编译但服务器上失败，往往是SDK版本、NuGet源或项目文件路径问题。使用`UseDotNet`任务明确指定SDK版本。
• 部署失败： 检查Azure服务连接的权限是否足够（至少要有目标应用服务的贡献者权限），以及应用服务名称、资源组是否正确。
• 应用启动失败： 部署成功但网站无法访问。去Azure门户的应用服务日志流（Log Stream）或查看“诊断和解决问题”板块，这里通常会有详细的运行时错误信息，比如数据库连接失败、缺少某个依赖等。

将CI/CD流程建立起来，只是第一步。后续可以探索集成安全扫描、性能测试、自动化UI测试等，让流水线变得更加智能和健壮。希望这篇教程能帮助你顺利踏上自动化部署之旅，把时间更多地留给创造价值的功能开发上。