开发平台辅助能力
开发平台辅助能力用于管理应用的外部数据连接、环境、运行容器和版本：
- 数据源管理
- 环境管理
- 容器运行支撑
- 版本治理与版本发布
适用任务
它们解决的不是“某个业务页面怎么做”，而是：
- 团队怎么接入平台外部数据
- 同一个应用怎么在不同环境里运行
- 开发态和运行态容器怎么被统一管理
- 平台资产怎么被版本化、回溯和发布
如果你正在从“做功能”走向“长期协作和持续交付”，这组能力就会开始变得重要。
四类能力分别做什么
数据源管理
当前平台把数据源分成两层：
- 平台级数据源
- 应用级数据源绑定
平台级数据源适合统一维护外部数据库连接定义；应用级数据源则负责把某个应用里的数据站点映射到平台数据源上。
从当前实现看，这组能力已经支持：
- 平台数据源的增删改查
- 应用级数据源分配
- JDBC 类型数据源元数据读取
- 表和字段元数据探查
如果你的目标是让应用稳定接入外部数据库，而不是在代码里手写连接参数，应该优先看这组能力。
环境管理
环境管理解决的是“同一个应用当前运行在什么语义环境下”。
当前平台已经内建了固定环境集合：
devtestuatprod
它的价值不在于环境数量，而在于让数据源、容器、发布动作和团队协作都能围绕一致的环境语义展开。
如果团队已经开始区分开发、测试、验收和生产，这组能力就值得尽早纳入流程。
容器运行支撑
容器能力解决的是“应用怎么被拉起、重启、更新和观察状态”。
当前容器支撑已经覆盖：
- 容器创建和删除
- 启动、停止、暂停、重启
- 基座镜像拉取和镜像更新
- 端口分配
- 运行状态查询
- 容器状态事件回传
这说明平台并不只是产出配置和包，还已经具备一套开发平台视角的容器运行支撑能力。
版本治理与版本发布
版本治理解决的是“平台里的开发资产如何被追踪、提交、标记和导出”。
当前这组能力已经建立在 Git/VCS 抽象之上，并支持：
- 文件读写、移动、删除、锁定
- 当前文件状态识别
- 最近变更记录查看
- 应用版本列表和版本详情
- 创建版本
- 导出指定版本
- 导出应用时可选择包含未提交内容和 Git 仓库信息
如果你的团队已经开始关心“当前改了什么、准备发哪个版本、怎么回看最近变更”，这组能力就非常关键。
一张简单判断表
| 当前问题 | 优先能力 |
|---|---|
| 外部数据库怎么统一接入和分配 | 数据源管理 |
| 同一应用在不同阶段怎么区分运行语义 | 环境管理 |
| 应用怎么被快速拉起、重启和换镜像 | 容器运行支撑 |
| 当前改动怎么沉淀成可回溯版本 | 版本治理与版本发布 |
常见组合方式
组合一：环境 + 数据源
适合多环境下的数据接入治理。
环境负责确定当前语义上下文，数据源负责把连接和数据站点映射进去。这种组合比在多个地方手填连接参数更稳。
组合二：环境 + 容器
适合开发、测试、验收阶段的运行控制。
环境给出运行边界，容器负责把应用实际拉起来，并提供状态和控制入口。
组合三：版本治理 + 版本发布
适合团队协作、版本冻结和发布回看。
版本治理负责沉淀日常改动，版本发布负责把某个时间点明确标记出来，方便后续导出、回滚和问题比对。
组合四：数据源 + 环境 + 容器 + 版本
这是最接近真实交付链路的一组组合。
它的意义在于把“外部连接”“运行载体”“环境语义”“版本边界”放到统一平台能力里治理，而不是散落到脚本、聊天记录和人工约定里。
什么时候优先留在平台辅助能力里
- 你们的目标是让团队协作更稳，而不是立刻自建一整套外部平台
- 你们需要统一数据源、环境和运行约定
- 你们需要让应用版本和近期变更在平台里可见
- 你们需要开发态或交付态的容器控制能力
这时优先复用平台现成能力，通常比自己临时拼流程更省成本。
什么时候还需要外部体系补位
- 需要更大规模的企业级流水线编排
- 需要超出当前平台范围的基础设施统一治理
- 需要覆盖更多外部制品库、制品签名或组织级发布规则
这时更合适的做法通常不是替换平台能力，而是让平台能力和外部 DevOps 体系协同。
选择规则
如果你现在要解决的是“团队如何在平台里稳定开发和交付”，先看这组辅助能力。
如果你现在要解决的是“整个企业基础设施怎么统一治理”，再考虑更外层的平台和流程。