Microsoft Releases Aspire 13.5 With a Refreshed Dashboard and Workflow Improvements

{ "title_zh": "Aspire 13.5：从刷新仪表盘到更顺手的云原生开发工作流", "body_zh": "# Aspire 13.5：把本地分布式开发的细节放回仪表盘\n\nMicrosoft 发布 Aspire 13.5，重点不在于增加一个孤立的大功能，而在于持续打磨开发者每天都会碰到的工作流：查看资源状态、导入交互服务文件、跟踪长任务进度、进入资源终端，以及把部署配置推进到 Kubernetes 和 Azure。新版还刷新了仪表盘与 aspire.dev 首页，让 Aspire 的本地编排体验更完整。\n\n## 仪表盘开始承担更多操作\n\n在分布式应用中，仪表盘不应只是展示日志和健康状态的只读页面。Aspire 13.5 为资源增加了交互式终端能力，开发者可以直接在仪表盘中进入资源环境执行检查命令。例如，排查一个 Web API 到数据库的连接时，可以在对应资源的终端里运行健康检查、查看环境变量，或确认挂载目录是否存在。\n\n这类能力的价值在于减少上下文切换。开发者不必在浏览器、宿主机终端和容器 shell 之间来回寻找资源，也不必手工确认当前操作针对的是哪个实例。实际使用时仍应遵循最小权限原则：终端适合诊断和短期操作，生产环境的变更应继续通过审计过的部署流程完成。\n\n## Interaction Service 更适合真实的长任务\n\nInteraction Service 新增文件导入和进度对话框，覆盖了两种常见场景：用户需要把本地文件交给服务处理，以及服务需要在较长时间内反馈任务进展。相比让用户盯着一个没有变化的提交按钮，文件导入可以明确输入边界，进度对话框则能把“请求是否还活着”和“任务完成了多少”区分开。\n\n可以把它和后端任务接口组合起来。下面是一个可改造的最小 HTTP 轮询示例，假设服务返回 202 Accepted 和任务 ID，前端或交互层根据进度更新对话框：\n\npython\nfrom __future__ import annotations\n\nimport time\nfrom pathlib import Path\n\nimport requests\n\nBASE_URL = "http://localhost:5000"\nFILE = Path("./data/input.csv")\n\nwith FILE.open("rb") as stream:\n response = requests.post(\n f"{BASE_URL}/imports",\n files={"file": (FILE.name, stream, "text/csv")},\n timeout=30,\n )\nresponse.raise_for_status()\ntask_id = response.json()["taskId"]\n\nwhile True:\n status = requests.get(f"{BASE_URL}/imports/{task_id}", timeout=10)\n status.raise_for_status()\n payload = status.json()\n print(f\"进度: {payload['completed']}/{payload['total']}\")\n\n if payload["state"] in {"completed", "failed"}:\n if payload["state"] == "failed":\n raise RuntimeError(payload.get("error", "import failed"))\n break\n time.sleep(1)\n\n\n运行前把 BASE_URL、文件路径和接口字段替换成项目实际值。示例体现的是工作流契约，而不是 Aspire 13.5 强制规定的 API：导入接口负责接收文件并返回任务 ID，状态接口负责提供可展示的进度。生产实现还应加入文件大小限制、内容类型校验、取消任务、重试策略和权限检查。\n\n## 部署能力覆盖更多基础设施边界\n\nAspire 13.5 的部署改进包括 Kubernetes 持久卷，以及跨 scope 的 Azure 引用。两项变化都指向同一个问题：本地编排里的资源关系，不能在部署时突然变成手工拼接的基础设施清单。\n\n持久卷适合数据库、队列或需要保留中间结果的服务。应用迁移到 Kubernetes 后，容器重启不应意味着数据消失，因此部署描述需要清晰区分临时目录和持久化存储。可以这样实践一个最小的 Kubernetes 持久卷声明：\n\nyaml\napiVersion: v1\nkind: PersistentVolumeClaim\nmetadata:\n name: orders-data\nspec:\n accessModes:\n - ReadWriteOnce\n resources:\n requests:\n storage: 10Gi\n storageClassName: standard\n\n\n把这个声明接入 Aspire 的部署配置时，应根据集群实际情况调整 storageClassName、访问模式、容量和备份策略。PVC 只描述存储请求，不等同于完整的数据保护方案。数据库仍需要迁移管理、备份、恢复演练和敏感信息隔离。\n\n跨 scope Azure 引用则适用于资源被拆分到不同部署范围的场景，例如应用在一个 scope，托管数据库或密钥服务在另一个 scope。这里的关键是明确引用的生命周期、权限和部署顺序，避免开发环境中能解析的资源关系在目标订阅或资源组中失效。\n\n## 升级时应检查哪些事情\n\nAspire 13.5 的功能大多属于质量改进，但它们会触及开发、诊断和部署边界。升级可以按下面的顺序进行：\n\n1. 更新 Aspire 相关包和工具版本，确认团队使用的是同一套 SDK 与 CLI。\n2. 在仪表盘中验证资源终端的权限范围，避免把诊断入口误当成生产运维入口。\n3. 为 Interaction Service 的文件导入补充大小、类型、超时和失败状态测试。\n4. 在临时 Kubernetes 集群中验证 PVC 的绑定、重启后的数据可见性以及删除策略。\n5. 对跨 scope Azure 引用执行一次全新环境部署，检查身份权限和资源创建顺序。\n6. 将仪表盘刷新后的操作路径加入团队文档和故障排查流程。\n\nAspire 13.5 值得关注的地方，是它把“能运行”继续推进到“能观察、能操作、能部署”。如果团队已经使用 Aspire 管理多资源应用，升级的收益主要来自更少的手工诊断和更连续的部署体验；如果项目依赖复杂的持久化数据或跨 scope 云资源，则应先在隔离环境验证权限、存储和生命周期，再扩大升级范围。", "title_en": "Aspire 13.5 Makes Distributed App Workflows More Practical", "body_en": "# Aspire 13.5 Makes Distributed App Workflows More Practical\n\nMicrosoft has released Aspire 13.5 with a refreshed dashboard, an updated aspire.dev homepage, and several workflow improvements. The release focuses on the details developers handle every day: importing files into interactive services, showing progress for long-running operations, opening terminals for resources, and carrying more deployment intent into Kubernetes and Azure.\n\n## The Dashboard Becomes an Operating Surface\n\nA distributed-application dashboard should do more than show logs and health checks. In Aspire 13.5, resources can host an interactive terminal in the dashboard. That gives developers a direct place to inspect a running resource, verify environment details, check a mounted directory, or run a lightweight connectivity diagnostic.\n\nThe practical benefit is less context switching and less ambiguity about which instance is being inspected. Terminal access still needs sensible boundaries: it is useful for diagnosis and short-lived operations, while production changes should remain in an audited deployment workflow with appropriate permissions.\n\n## Better Interaction for File Imports and Long Jobs\n\nThe Interaction Service gains file imports and progress dialogs, covering two common application patterns. A user can provide a local file as an explicit input, while a long-running operation can report progress instead of leaving the interface in an indeterminate loading state.\n\nA small HTTP workflow can model the contract behind such an interaction. The following example assumes that the import endpoint returns 202 Accepted and a task ID. Adapt the URL and response fields to the service in your application:\n\npython\nfrom __future__ import annotations\n\nimport time\nfrom pathlib import Path\n\nimport requests\n\nBASE_URL = "http://localhost:5000"\nFILE = Path("./data/input.csv")\n\nwith FILE.open("rb") as stream:\n response = requests.post(\n f"{BASE_URL}/imports",\n files={"file": (FILE.name, stream, "text/csv")},\n timeout=30,\n )\nresponse.raise_for_status()\ntask_id = response.json()["taskId"]\n\nwhile True:\n status = requests.get(f"{BASE_URL}/imports/{task_id}", timeout=10)\n status.raise_for_status()\n payload = status.json()\n print(f\"Progress: {payload['completed']}/{payload['total']}\")\n\n if payload["state"] in {"completed", "failed"}:\n if payload["state"] == "failed":\n raise RuntimeError(payload.get("error", "import failed"))\n break\n time.sleep(1)\n\n\nBefore running it, change BASE_URL, the file path, and the response fields to match your service. The example describes a workflow contract, not an Aspire 13.5-required API: one endpoint accepts the file and creates a job, while another reports progress. A production implementation should also enforce file-size and content-type limits, authorization, cancellation, retries, and clear failure states.\n\n## Deployment Reaches Further Into Infrastructure\n\nAspire 13.5 adds Kubernetes persistent volumes and support for cross-scope Azure references. Both improvements address a common deployment gap: relationships that are explicit in local orchestration should not turn into manually assembled infrastructure when the application moves to a target environment.\n\nPersistent volumes are relevant for databases, queues, and services that retain intermediate results. A container restart should not implicitly erase application data. A minimal Kubernetes claim might look like this:\n\nyaml\napiVersion: v1\nkind: PersistentVolumeClaim\nmetadata:\n name: orders-data\nspec:\n accessModes:\n - ReadWriteOnce\n resources:\n requests:\n storage: 10Gi\n storageClassName: standard\n\n\nWhen connecting this to an Aspire deployment configuration, adjust the storage class, access mode, capacity, and retention policy for the target cluster. A PVC is a storage request, not a complete data-protection strategy. Database migrations, backups, restore tests, and secret isolation remain separate responsibilities.\n\nCross-scope Azure references help when an application and its managed dependencies are deployed in different scopes, such as separate resource groups or subscriptions. The important questions are lifecycle, identity permissions, and deployment order. A reference that resolves locally must also resolve in a clean target environment under the deployment identity.\n\n## A Practical Upgrade Checklist\n\nAlthough many changes in Aspire 13.5 are quality-of-life improvements, they touch development, diagnostics, and deployment boundaries. A staged upgrade is sensible:\n\n1. Update Aspire packages and tooling, and align the SDK and CLI versions across the team.\n2. Verify the permissions and exposure of dashboard terminals; do not treat a diagnostic entry point as a production operations console.\n3. Add tests for file size, content type, timeout behavior, and failure reporting in Interaction Service workflows.\n4. Validate PVC binding, data visibility after pod restarts, and deletion behavior in a temporary Kubernetes cluster.\n5. Perform a clean deployment for cross-scope Azure references and check identity permissions and resource ordering.\n6. Add the updated dashboard workflow to the team’s troubleshooting runbooks.\n\nAspire 13.5 is useful because it moves the experience from “the app runs” toward “the app can be inspected, operated, and deployed with fewer manual steps.” Teams already using Aspire for multi-resource applications are likely to benefit most from reduced diagnostic friction. Projects that depend on persistent data or cross-scope cloud resources should validate storage, identity, and lifecycle behavior in an isolated environment before making the upgrade broadly.\n", "seo_description_en": "Aspire 13.5 refreshes the dashboard and adds file imports, progress dialogs, resource terminals, Kubernetes volumes, and cross-scope Azure references." }