通过 CodeCatalyst Dev Environments 实现云开发环境 - 从 devfile 定义到分支隔离
Amazon CodeCatalyst 的 Dev Environments 通过 devfile 实现环境定义的标准化，并提供以分支为单位的隔离环境，大幅缩短开发者的入职时间。本文介绍与 VS Code 和 JetBrains 的 IDE 联动、计算规格的选项，以及通过环境自动停止进行的成本管理。
构建本地环境的课题与 Dev Environments 的定位
软件开发团队每次迎来新成员时都会面临的，是构建本地开发环境的成本。语言运行时的版本差异、操作系统特有的库依赖、数据库和缓存服务器的设置等，即使按照 README 中写的步骤进行，花费半天到一整天的情况也并不少见。这类初始设置所需的时间容易受到负责人的经验和机器状态的影响，从团队整体来看，会成为切实拖慢新成员上手的因素。CodeCatalyst 的 Dev Environments 是将这一问题转移到云端的方法。开发者的机器上只需准备 IDE 的客户端，编译 / 测试 / 调试全部在云上的计算实例中执行。由于不依赖本地机器的配置，无论是 M1 Mac 还是 Windows，都能在数分钟内启动相同的环境。GitHub Codespaces 也提供类似的云开发环境。但 CodeCatalyst 与 AWS 服务的集成很深，内置了 IAM 角色的自动授予以及与 CodeCatalyst 工作流的联动，这一点使其与众不同。另外，CodeCatalyst 已于 2025 年 11 月 7 日停止接受新客户，现有客户只能在现有空间中继续使用（截至 2026 年 8 月）。
通过 devfile 实现环境定义的标准化
承担 Dev Environments 核心作用的是 devfile。devfile 是由 CNCF（Cloud Native Computing Foundation）托管的开放规范，用 YAML 声明式地定义开发环境的容器镜像、端点、命令和卷。只需在存储库的根目录放置 devfile.yaml，启动时就会自动读取。例如，对于使用 Node.js 20 和 PostgreSQL 15 的项目，典型的构成是定义 2 个容器组件，并通过 postStart 命令执行 npm install 和迁移。由于环境定义作为代码进行版本管理，“在我的环境里明明能运行”这类问题会从结构上被消除。GitHub Codespaces 采用 devcontainer.json，而 CodeCatalyst 则采用 devfile 作为配置手段。devfile 可以在一个 YAML 中声明容器组件、端点和生命周期命令，因此即使是组合多个容器的开发环境，也可以在存储库一侧完整地定义。即使不编写 devfile，也可以使用默认镜像（基于 Amazon Linux 2023，内置主要语言运行时）启动，因此能够将引入的初始成本控制在较低水平。
IDE 联动与计算规格的选项
Dev Environments 支持 VS Code 和 JetBrains IDE（IntelliJ IDEA、PyCharm、GoLand 等）这 2 个系列。使用 VS Code 时，安装 AWS Toolkit 扩展，从命令面板启动 Dev Environment 后，就会通过 SSH 建立远程连接。由于可以直接使用本地的 VS Code，不需要更改快捷键和扩展功能的设置。在 JetBrains IDE 中，通过 JetBrains Gateway 进行连接，IDE 的后端在云端运行。计算规格提供从 2 vCPU / 4 GB 到 16 vCPU / 32 GB 的 4 个等级，大规模的 Gradle 构建或机器学习模型的本地测试则选择较高的规格。存储默认为 16 GB，最多可扩展到 64 GB。启动时间取决于计算规格和容器镜像的大小，但如果使用默认镜像，通常在 2-3 分钟内完成 IDE 连接。还提供了不在本地准备 IDE、直接从浏览器访问 Dev Environment 开始开发的选项。
以分支为单位的隔离环境带来的开发流程
Dev Environments 在实用上的优势在于，可以为每个分支瞬间创建独立的环境。在功能开发分支上工作时如果需要热修复，以往需要在本地执行 git stash、切换分支，并等待依赖项重新安装。在 Dev Environments 中，只需另外启动一个用于主分支的环境，就可以在 2 个环境完全隔离的状态下并行工作。每个环境都拥有独立的文件系统和进程空间，因此不会发生端口号冲突或全局安装的工具的版本冲突。环境的创建可以从 CodeCatalyst 控制台、CLI 或 IDE 插件执行，只需指定存储库和分支。不再需要的环境只要删除，计算成本就会立即停止。这种隔离模型对代码审查也很有效，会形成这样的工作流程：审查者从拉取请求的分支启动 Dev Environment，一边实际运行代码一边审查。
入职效率的提升与运维设计
Dev Environments 的引入效果表现得最为显著的是入职。只要在存储库中准备好 devfile，新成员在被邀请加入 CodeCatalyst 项目后，就能立即一键启动开发环境，并完成第一次提交。以往需要 1-2 天的环境构建缩短到 10 分钟以内，因此成员开始为团队生产力做出贡献的时间会提前。在运维方面，非活动环境的自动停止设置很重要。默认情况下，15 分钟没有操作环境就会停止，计算成本也随之停止产生。这个阈值可以在项目设置中更改。停止的环境在恢复后会还原文件系统的状态，因此工作的连续性得以保持。费用按计算的运行时间计费，所选的实例规格（从 dev.standard1.small 到 dev.standard1.xlarge 的 4 个等级）越大，每小时的单价也越高。具体的每小时单价请在 AWS 的 CodeCatalyst 价格页面确认（截至 2026 年 8 月）。免费套餐中包含每月 60 小时的 Dev Environment 使用额度，但如前所述，CodeCatalyst 已停止接受新客户，因此无法新获得这一免费额度。如果正在使用现有空间，可以在免费额度范围内满足个人开发或小规模团队的运营（截至 2026 年 8 月）。对于整个组织的成本管理，会利用空间级别的计算上限设置。
devfile 设计的最佳实践
devfile 的运用有几条指导原则。保持基础镜像的轻量。将只包含必要工具的自定义镜像托管在 ECR 中，并通过 devfile 的 image 字段引用。镜像超过 2 GB 时启动需要 5 分钟以上，因此通过多阶段构建削减不必要的层。让 postStart 命令具备幂等性。由于环境恢复时也会执行该命令，因此用 npm ci 这样进行全新安装的命令来防止不一致。机密信息通过 Dev Environment 的环境变量设置进行管理，不硬编码到 devfile 中。对于 AWS 服务的访问，会自动授予与空间关联的 IAM 角色，因此不需要手动设置访问密钥。如果建立起通过拉取请求接收环境构建反馈的运维方式，质量就会趋于稳定。
参考资料（AWS 官方）
本页的第一手信息来源是 AWS 官方网站及官方文档。最新的规格与价格请以下列官方页面为准。
如本页内容与官方文档不一致，请以官方文档为准。