GitLab Duo Self-Hosted 接入 Microsoft Foundry，企业可在自选 Azure 环境运行 AI 能力

预计阅读时间：8 分钟

GitLab 正在扩大 GitLab Duo Self-Hosted 的模型选择范围：组织可以使用通过 Microsoft Foundry 部署的模型，为 GitLab 的 AI 开发能力提供推理后端。对受数据驻留、网络隔离或合规策略约束的团队来说，这意味着 AI 能力不必完全依赖 GitLab 之外的公共模型服务，而可以落在组织选定的 Azure 环境中。

变化在哪里

这次扩展的核心不是新增一个独立的聊天入口，而是扩大 GitLab Duo Self-Hosted 可连接的模型部署选项。模型由组织通过 Microsoft Foundry 管理，并运行在组织选择的 Azure 环境中；GitLab Duo 则继续面向软件开发流程提供 AI 辅助能力。

这样的架构把两个关注点分开了：

GitLab 负责将 AI 能力嵌入代码托管、合并请求和开发工作流。
Microsoft Foundry 负责模型的部署、资源位置和 Azure 侧治理。
企业可以根据自身的安全、合规和网络要求选择 Azure 环境与模型配置。

摘要并未说明所有可用模型、具体版本或完整配置参数。因此，实际接入时应以当前 GitLab Duo Self-Hosted 和 Microsoft Foundry 文档中的兼容性列表为准，不要假设任意 Foundry 模型都能直接使用。

为什么自托管选项重要

企业采用 AI 开发工具时，真正的阻力通常不在模型效果，而在数据边界。源代码、漏洞信息、内部 API、合并请求讨论和日志都可能包含敏感内容。把模型部署到组织可控的 Azure 环境，可以帮助团队围绕以下问题建立更清晰的控制面：

数据应存储在哪个区域。
推理请求经过哪些网络边界。
哪些项目和用户可以调用 AI 能力。
如何记录访问、消耗与故障。
模型升级是否需要经过内部评审。

这并不等同于“自托管后自动合规”。组织仍然需要确认数据是否离开指定网络、Azure 资源的权限配置是否正确、日志是否包含敏感内容，以及模型供应商和版本是否符合内部政策。

可以怎样规划接入

一个可操作的落地路径是先把模型部署、连接配置和 GitLab 功能验证拆成三个阶段：

在 Microsoft Foundry 中创建或选择目标模型部署，并确认所在 Azure 区域、访问方式和配额。
在非生产 GitLab 环境中配置 GitLab Duo Self-Hosted 的模型连接，验证认证、网络连通性和响应能力。
以代码解释、测试生成或合并请求辅助等有限场景开始，观察质量、延迟、成本与数据访问范围，再逐步扩大使用面。

下面是一个可改造的 Azure CLI 示例。它用于准备 Azure 侧资源和环境变量，具体的 Microsoft Foundry 命令、资源类型和 GitLab 配置键可能会随产品版本变化，因此运行前应替换占位符，并按当前文档校正参数。这个示例不声称能单独完成 GitLab Duo 接入。

#!/usr/bin/env bash
set -euo pipefail

SUBSCRIPTION_ID="00000000-0000-0000-0000-000000000000"
RESOURCE_GROUP="rg-gitlab-duo-ai"
LOCATION="eastus"
FOUNDRY_RESOURCE="foundry-gitlab-duo"
MODEL_DEPLOYMENT="duo-model"

az login
az account set --subscription "$SUBSCRIPTION_ID"
az group create \
  --name "$RESOURCE_GROUP" \
  --location "$LOCATION"

# 根据当前 Microsoft Foundry CLI/API 版本替换为实际的 Foundry 资源创建命令。
# 这里保留资源名、区域和部署名，便于接入自动化流水线。
export AZURE_RESOURCE_GROUP="$RESOURCE_GROUP"
export AZURE_LOCATION="$LOCATION"
export FOUNDRY_RESOURCE_NAME="$FOUNDRY_RESOURCE"
export MODEL_DEPLOYMENT_NAME="$MODEL_DEPLOYMENT"

printf 'Prepared resource group: %s\n' "$AZURE_RESOURCE_GROUP"
printf 'Target model deployment: %s\n' "$MODEL_DEPLOYMENT_NAME"

在 GitLab 侧，建议把连接信息放入受保护的 CI/CD 变量或平台提供的安全配置中，而不是提交到仓库。至少应区分以下几类配置：

# 示例配置，字段名需要按实际 GitLab Duo Self-Hosted 版本调整
ai_backend:
  provider: microsoft_foundry
  endpoint: ${FOUNDRY_ENDPOINT}
  deployment: ${MODEL_DEPLOYMENT_NAME}
  auth: managed_identity
  region: ${AZURE_LOCATION}

如果环境使用 API 密钥而不是托管身份，应通过密钥管理服务注入凭据，并设置轮换策略。生产环境还应为模型调用建立超时、限流、重试和降级行为，避免模型服务短暂不可用时拖慢合并请求等核心流程。

评估时不要只看回答质量

模型接入完成后，建议用真实但经过脱敏的工程任务建立评估集，至少覆盖：

代码解释是否准确，是否遗漏关键副作用。
测试生成是否能运行，是否覆盖边界条件。
合并请求总结是否引用了实际变更，而不是生成泛化描述。
在组织代码和内部术语下，回答是否保持稳定。
请求延迟、并发限制和 Azure 资源成本是否可接受。

还要单独测试权限边界。一个用户无权读取的项目，不应因为 AI 助手而获得额外上下文。对于源代码、凭据、个人信息和生产日志，也应在进入模型前明确脱敏或阻断规则。

采用建议

Microsoft Foundry 支持让 GitLab Duo Self-Hosted 更贴近企业已有的 Azure 治理体系，但它带来的不是一次性安装任务，而是一项跨 GitLab、Azure、身份和模型运营的系统集成。比较稳妥的做法是：

先确认 GitLab Duo Self-Hosted 当前版本与目标 Foundry 模型的兼容性。
明确数据驻留、网络出口、身份认证和日志保留策略。
从低风险开发场景开始，保留人工审查和回滚路径。
用质量、延迟、成本和权限测试共同决定是否扩大范围。
把模型部署与 GitLab 配置纳入可审计的基础设施流程。

对已经采用 Azure 并希望保留模型部署控制权的组织而言，这次扩展提供了一条更自然的落地路径；对其他团队而言，是否值得接入仍取决于自托管运维成本与数据控制收益之间的平衡。