Check Deployment Status
Check whether a PR/commit is deployed to staging and production using the continuous-deployment MCP tools.
Usage
CODEBLOCK0
Key Concepts
PR Head Commit != Merge Commit
When a PR is merged via SubmitQueue, the merge commit on main is DIFFERENT from the PR's head commit. The continuous-deployment system tracks the merge commit, not the PR head.
Workflow:
- 1. Get PR metadata → extract head SHA
- Use
findServiceCommits with search text to find the actual merge commit on main - Use
getCommitDeploymentStatus with the merge commit hash
UP Deployment Stages
| Stage | Meaning |
|---|
| Build created | Binary built from commit |
| Deployed to staging |
Running on staging instances |
| Soaked | Staging soak period passed |
| Waited for deployment window | Outside deploy freeze windows |
|
Introduced to production |
Fully deployed to production — code is live |
"Introduced to production" = fully deployed. Not partial, not in-progress. The commit is running on all production instances.
Deployment Status Values
| Status | Meaning |
|---|
| INLINECODE2 | Commit is running in this environment |
| INLINECODE3 |
Deployment in progress |
| (empty) | Not deployed to this environment |
Step-by-Step Workflow
Step 1: Get PR Metadata
Use mcp__code-mcp__get_github_pull_request_metadata:
CODEBLOCK1
Extract: title, head SHA, merged status, base branch.
Step 2: Find Merge Commit
The PR head SHA won't be found in deployment system. Search for the merge commit:
Use mcp__continuous-deployment__continuousdeployment_findservicecommits:
CODEBLOCK2
The result includes the merge commit hash, serial number, and code review metadata linking back to the PR.
Step 3: Check Deployment Status
Use mcp__continuous-deployment__continuousdeployment_getcommitdeploymentstatus:
CODEBLOCK3
Returns deployment status per service per environment (staging, production, bits-test-sandbox).
MCP Tools Reference
continuous-deployment MCP
| Tool | Purpose |
|---|
| INLINECODE7 | Search commits by service name, author, text, date range |
| INLINECODE8 |
Get deployment status of a commit across all environments |
|
listServiceCommits | List recent commits for a service (with serial-based pagination) |
|
getCommitsInDeployment | List commits in a specific deployment task |
|
listCommitSegments | Get deployment segments for a service |
|
getConfigForService | Get continuous deployment config for a service |
code-mcp
| Tool | Purpose |
|---|
| INLINECODE13 | PR status, author, labels, SubmitQueue status |
| INLINECODE14 |
PR diff content |
|
get_github_pull_request_comments | PR comments |
UCS deployer MCP
| Tool | Purpose |
|---|
| INLINECODE16 | Rollout status for a specific deployment object |
| INLINECODE17 |
Read deploy state |
Service-Name Only Mode
If only a service name is provided (no PR/commit):
Use mcp__continuous-deployment__continuousdeployment_listservicecommits:
CODEBLOCK4
Then check deployment status for each returned commit using Step 3.
Common Patterns
Stacked PRs
For stacked PRs, each PR may affect different services. Check deployment per-service:
- - PRs changing
marketing-recommendations/ → check marketing-recommendations service - PRs changing
ads-insights/ → check ads-insights service
Repository URI
For go-code monorepo, always use: INLINECODE23
检查部署状态
使用持续部署MCP工具检查PR/提交是否已部署到预发布环境和生产环境。
使用方法
bash
/check-deployment-status # 检查GitHub PR的部署状态
/check-deployment-status # 检查特定提交的部署状态
/check-deployment-status # 列出最近提交及其部署状态
关键概念
PR头部提交 != 合并提交
当PR通过SubmitQueue合并时,主分支上的合并提交与PR的头部提交是不同的。持续部署系统追踪的是合并提交,而非PR头部。
工作流程:
- 1. 获取PR元数据 → 提取头部SHA
- 使用findServiceCommits及搜索文本查找主分支上的实际合并提交
- 使用合并提交哈希调用getCommitDeploymentStatus
UP部署阶段
| 阶段 | 含义 |
|---|
| 构建已创建 | 从提交构建的二进制文件 |
| 已部署到预发布环境 |
在预发布实例上运行 |
| 已浸泡 | 预发布浸泡期已过 |
| 等待部署窗口 | 在部署冻结窗口之外 |
|
已引入生产环境 |
已完全部署到生产环境 — 代码已上线 |
已引入生产环境 = 完全部署。 非部分部署,非进行中。该提交正在所有生产实例上运行。
部署状态值
| 状态 | 含义 |
|---|
| DEPLOYMENTSTATUSDEPLOYED | 提交正在此环境中运行 |
| DEPLOYMENTSTATUSDEPLOYING |
部署进行中 |
| (空) | 未部署到此环境 |
分步工作流程
步骤1:获取PR元数据
使用mcpcode-mcpgetgithubpullrequestmetadata:
org: uber-code
repo: go-code
number:
提取:标题、头部SHA、合并状态、基础分支。
步骤2:查找合并提交
PR头部SHA在部署系统中找不到。搜索合并提交:
使用mcpcontinuous-deploymentcontinuousdeployment_findservicecommits:
service_name: <服务名称>
filter: { searchtext: <来自PR标题的关键词>, commitedafter: 2026-02-25T00:00:00Z }
offset: 0
limit: 5
结果包含合并提交哈希、序列号以及链接回PR的代码审查元数据。
步骤3:检查部署状态
使用mcpcontinuous-deploymentcontinuousdeployment_getcommitdeploymentstatus:
hash: <合并提交哈希>
repository: gitolite@code.uber.internal:go-code
options: { scope: SCOPEALLSERVICES }
返回每个服务在每个环境(预发布、生产、bits-test-sandbox)中的部署状态。
MCP工具参考
持续部署MCP
| 工具 | 用途 |
|---|
| findServiceCommits | 按服务名称、作者、文本、日期范围搜索提交 |
| getCommitDeploymentStatus |
获取提交在所有环境中的部署状态 |
| listServiceCommits | 列出服务的最近提交(基于序列的分页) |
| getCommitsInDeployment | 列出特定部署任务中的提交 |
| listCommitSegments | 获取服务的部署分段 |
| getConfigForService | 获取服务的持续部署配置 |
code-mcp
| 工具 | 用途 |
|---|
| getgithubpullrequestmetadata | PR状态、作者、标签、SubmitQueue状态 |
| getgithubpullrequestdiff |
PR差异内容 |
| get
githubpull
requestcomments | PR评论 |
UCS部署器MCP
| 工具 | 用途 |
|---|
| ucsdeployerstatus | 特定部署对象的推出状态 |
| deploystatemanagerread |
读取部署状态 |
仅服务名称模式
如果只提供了服务名称(没有PR/提交):
使用mcpcontinuous-deploymentcontinuousdeployment_listservicecommits:
service_name: <服务名称>
offset: 0
limit: 5
然后使用步骤3检查每个返回提交的部署状态。
常见模式
堆叠PR
对于堆叠PR,每个PR可能影响不同的服务。按服务检查部署:
- - 修改marketing-recommendations/的PR → 检查marketing-recommendations服务
- 修改ads-insights/的PR → 检查ads-insights服务
仓库URI
对于go-code单仓库,始终使用:gitolite@code.uber.internal:go-code