环境特定基础设施
在跨环境部署应用程序时，会出现不同的要求：
| 组件 |
开发环境 |
生产环境 |
| 网络 |
公共访问 |
VNet集成 + 私有端点 |
| 存储 |
带限制的公共访问 |
仅私有端点 |
| 应用服务计划 |
B2基础版 |
S1标准版 |
| 安全 |
托管身份 |
增强的网络隔离 |
我们可以使用基于环境变量自适应的一组Bicep文件，而不是为每个环境维护单独的基础设施模板或复杂的配置文件。这种方法消除了基础设施漂移，同时保持部署简单一致。
基于环境变量设置资源
为了根据环境类型有条件地配置资源，azd利用环境变量AZURE_ENV_TYPE在部署时做出决策。
在后台，azd将AZURE_ENV_TYPE作为envType参数传递给Bicep：
1
2
3
|
@description('Environment type - determines networking configuration (dev/test/prod)')
@allowed(['dev', 'test', 'prod'])
param envType string = 'dev'
|
然后，此参数驱动Bicep中的条件性资源部署：
网络部署：
1
2
3
4
5
6
7
8
9
10
|
// 仅在生产环境中部署网络基础设施
module network './network.bicep' = if (envType == 'prod') {
name: 'networkDeployment'
params: {
location: location
tags: tags
abbrs: abbrs
resourceToken: resourceToken
}
}
|
存储配置：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
module storageAccount 'br/public:avm/res/storage/storage-account:0.17.2' = {
name: 'storageAccount'
params: {
name: storageAccountName
allowSharedKeyAccess: false
publicNetworkAccess: envType == 'prod' ? 'Disabled' : 'Enabled'
networkAcls: envType == 'prod' ? {
defaultAction: 'Deny'
virtualNetworkRules: []
bypass: 'AzureServices'
} : {
defaultAction: 'Allow'
virtualNetworkRules: []
bypass: 'AzureServices'
}
// ... 其他配置
}
}
|
应用服务计划大小调整：
1
2
3
4
|
sku: {
name: envType == 'prod' ? 'S1' : 'B2'
tier: envType == 'prod' ? 'Standard' : 'Basic'
}
|
增强默认CI/CD工作流
azd包含一个强大的命令来引导CI/CD管道：
这会生成一个基本工作流。但是，对于开发到生产的推广，需要使用以下步骤增强它：
重要更新
更新于2025年7月30日：原始方法使用本地文件备份（在同一作业中复制zip文件）。然而，社区指出使用原生CI/CD工件系统更符合惯例。我们已更新存储库和以下步骤，使用GitHub Action Artifacts。
1. 一次性打包：
1
2
3
4
5
|
- name: Package Application
run: |
mkdir -p ./dist
azd package app --output-path ./dist/app-package.zip
echo "Application packaged successfully"
|
2. 上传应用程序包：
1
2
3
4
5
6
|
- name: Upload Application Package
uses: actions/upload-artifact@v4
with:
name: app-package
path: ./dist/app-package.zip
retention-days: 30
|
3. 部署到开发环境：
1
2
|
- name: Deploy to Development
run: azd deploy app --from-package ./dist/app-package.zip --no-prompt
|
4. 验证门控：
1
2
3
4
5
6
7
8
9
10
|
- name: Validate Application
run: |
echo "Validating application in development environment..."
# TODO: 在此添加验证逻辑：
# 示例：
# - 健康检查和集成测试
# - 安全和合规性扫描
# - 性能验证
sleep 3 # 模拟验证时间
echo "Application validation passed"
|
5. 下载应用程序包：
1
2
3
4
5
|
- name: Download Application Package
uses: actions/download-artifact@v4
with:
name: app-package
path: ./prod-deploy
|
6. 设置环境变量：
1
2
3
4
5
6
7
8
9
|
- name: Promote to Production
run: |
# 通过将-dev替换为-prod来创建生产环境名称，如果没有-dev后缀则添加-prod
PROD_ENV_NAME="${AZURE_ENV_NAME%-dev}-prod"
echo "Production environment name: $PROD_ENV_NAME"
# 为此步骤设置环境变量
export AZURE_ENV_NAME="$PROD_ENV_NAME"
export AZURE_ENV_TYPE="prod"
|
7. 部署到生产环境：
1
2
3
4
5
6
7
8
9
10
11
|
# 使用工件包 - 真正的"一次构建，到处部署"
PACKAGE_PATH="./prod-deploy/app-package.zip"
if [ -f "$PACKAGE_PATH" ]; then
echo "Deploying to production using artifact package: $PACKAGE_PATH"
azd deploy app --from-package "$PACKAGE_PATH" --no-prompt
echo "Production deployment completed successfully"
else
echo "Package artifact not found - falling back to regular deployment"
azd deploy --no-prompt
fi
|
逐步设置
按照以下步骤设置开发和生产环境，然后配置CI/CD管道：
1. 从模板初始化项目
1
|
azd init -t https://github.com/puicchan/azd-dev-prod-appservice-storage
|
这会下载包含所有Bicep文件和增强的GitHub Actions工作流的完整实现。
2. 设置开发环境
当提示输入环境名称时，使用myproj-dev（或您喜欢的带有-dev后缀的命名模式）。
注意：默认的envType是dev，因此您不需要为开发设置AZURE_ENV_TYPE环境变量。基础设施将自动配置为具有公共访问和成本优化的资源。
3. 设置生产环境
创建并配置生产环境：
1
2
3
4
5
6
7
8
|
# 创建新的生产环境
azd env new myproj-prod
# 将环境类型设置为生产
azd env set AZURE_ENV_TYPE prod
# 部署生产环境
azd up
|
这会配置具有VNet集成、私有端点和增强安全性的生产基础设施。请注意，运行azd up也会将应用程序部署到生产基础设施。这是为了演示目的，加上我们仍处于开发阶段。在真实场景中，如果应用程序已经在生产中，您可能永远不会直接部署应用程序。
4. 切换回开发环境
1
|
azd env select myproj-dev
|
您现在可以在开发环境中进行开发和测试。
5. 进行代码更改
编辑您的应用程序代码（例如，修改app/templates/index.html或app.py）以测试推广工作流。
6. 配置CI/CD管道
GitHub Actions工作流通过开发到生产的推广逻辑得到增强。具体来说，管道将：
- 在开发环境（
myproj-dev）中部署和验证
- 使用相同的包自动推广到生产环境（
myproj-prod）
- 自动处理环境命名转换
一旦配置完成，每次推送到主分支都会触发自动的开发到生产推广管道！
总结
总之，这种模式结合了条件性Bicep部署、包保留和智能环境命名，使用相同的构建工件创建可靠的开发到生产推广流程。