TeamCity 2026.1.1 是一个纯 bugfix 版本，没有新功能，但如果你在生产环境跑 TeamCity，里面修的几个问题很可能正在悄悄影响你的构建流水线——尤其是 S3 artifact 上传失败和 .NET 构建找不到兼容 agent 这两条，直接导致构建结果丢失或排队卡死。
四个最值得关注的修复
1. S3 Bucket 上传失败
构建产物上传到 S3 一直是 TeamCity 云存储集成的主流用法。此前的版本在某些配置场景下上传会直接失败，错误信息不够明显，排查时很容易误以为是权限或网络问题。2026.1.1 修复了底层上传逻辑，如果你当前有 artifact 存储到 S3 的配置，升级后应立即验证上传是否恢复正常。
2. Agent 备用 IP 地址被忽略
TeamCity 构建 agent 注册时会上报主 IP 和备用 IP。旧版本在调度连接时只走主 IP，备用 IP 被完全忽略。这意味着当主 IP 不可达（比如跨网段、VPN 切换后），agent 本应通过备用 IP 仍然可达，但实际上会变成"失联"。多网段部署的团队受影响最大。
3. Rake 插件损坏
Ruby 项目用 Rake 插件跑构建的团队会遇到插件加载失败，构建直接报错。这个修复恢复了 Rake 插件的正常加载路径。
4. .NET 构建的 "Exists" Agent 要求匹配失败
TeamCity 支持用 Exists 类型的 agent requirement 检查某个文件或工具是否存在于 agent 上，用来筛选兼容 agent。旧版本中 .NET 构建如果设置了 Exists requirement，即使 agent 上确实存在目标文件，匹配逻辑也会判定不兼容，导致构建永远找不到可运行 agent，一直排队。
升级实操：Docker 部署下的快速更新
如果你用 Docker 运行 TeamCity Server，升级到 2026.1.1 只需要切换镜像标签并重启。下面是一个可以直接复制改造的 docker-compose.yml 示例：
version: "3.8"
services:
teamcity-server:
image: jetbrains/teamcity-server:2026.1.1
ports:
- "8111:8111"
volumes:
- teamcity-data:/data/teamcity
- teamcity-logs:/opt/teamcity/logs
environment:
- TEAMCITY_SERVER_MEM_OPTS=-Xmx2g -XX:MaxMetaspaceSize=512m
restart: unless-stopped
teamcity-agent-1:
image: jetbrains/teamcity-agent:2026.1.1
environment:
- SERVER_URL=http://teamcity-server:8111
- AGENT_NAME=agent-dotnet-linux
volumes:
- agent-1-work:/opt/buildagent/work
- agent-1-temp:/opt/buildagent/temp
depends_on:
- teamcity-server
restart: unless-stopped
volumes:
teamcity-data:
teamcity-logs:
agent-1-work:
agent-1-temp:
升级步骤：
# 1. 拉取新镜像
docker compose pull
# 2. 停止当前服务
docker compose down
# 3. 启动新版本（数据卷会自动挂载，无需迁移）
docker compose up -d
# 4. 等待 Server 启动完成后，打开 http://localhost:8111
# 首次进入会看到数据库升级提示，点击确认即可
注意：升级前确保
teamcity-data卷的备份已完成。TeamCity 的数据目录包含构建历史、配置和用户信息，虽然 bugfix 版本通常不涉及数据库 schema 变更，但留一份备份是最低成本的安全网。
升级后的验证清单
升级完成后，不要只看 Server 页面能打开就完事，建议按以下清单逐项确认：
| 检查项 | 验证方式 |
|---|---|
| S3 artifact 上传 | 手动触发一个使用 S3 存储的构建，检查 artifact 是否成功出现在 S3 bucket 中 |
| Agent 备用 IP | 在 Agent 页面查看注册信息，确认备用 IP 显示正确；尝试从备用 IP 网段触发构建 |
| Rake 构建 | 触发一个 Ruby/Rake 构建配置，确认插件加载和任务执行正常 |
| .NET Exists requirement | 找到设置了 Exists requirement 的 .NET 构建配置，确认兼容 agent 被正确匹配并分配 |
| 构建历史完整性 | 浏览近期构建记录，确认 artifact 和日志没有丢失 |
其中 S3 上传和 .NET agent 匹配这两项，如果之前受 bug 影响，升级后修复效果会非常直观——原本失败的构建会直接恢复正常运行。
谁应该尽快升级
- 使用 S3 存储构建产物的团队：上传失败意味着 artifact 丢失，影响下游部署和回滚能力。
- 跨网段部署 agent 的团队：备用 IP 修复直接提升 agent 可用性。
- 有 .NET + Exists requirement 的团队：构建排队卡死的问题在升级后立即消失。
- Ruby/Rake 项目：插件损坏是硬性阻断，没有 workaround。
如果你的 TeamCity 环境没有碰到上述任何一个问题，bugfix 版本的升级优先级可以稍低，但建议在下一次常规维护窗口中一并完成——20 多个性能和稳定性修复累积起来，对长期运行的健康度有帮助。