DevOps 与云基础设施

DevOps 与 CI/CD

在每次变更进入生产环境之前对其进行检查的构建、测试和部署流水线。我们借助 AI 协助和专家审查搭建这些流水线，然后将其移交给您或继续为您运行。

沟通您的项目讨论您的 CI/CD 设置

从手动部署到受控发布

如果发布依赖于手动步骤、某个人的笔记本电脑或一个没人愿意碰的脚本，那么每次部署都是一种风险。我们构建的 CI/CD 流水线会测试每次变更，每次都以相同的方式部署，并随时准备好回滚路径。AI 代理帮助起草流水线配置、容器文件和基础设施代码，并读取失败的构建日志。DevOps 工程师审查每次变更，并决定如何对发布进行把关。它既适合新产品，也适合现有软件，包括用 AI 工具构建的应用。

AI 协助、工程师审查的 DevOps

AI 如何协助

  • 从您的代码仓库起草流水线定义、Dockerfile 和基础设施代码，供工程师审查。
  • 读取失败的构建、测试和部署日志，以给出可能的原因和修复建议。
  • 标记配置变更中的高风险设置，例如宽泛的权限、暴露的端口或未固定版本的基础镜像。
  • 根据实际构建的配置起草运行手册和设置文档。

我们的专家负责什么

  • 发布策略：哪些检查对部署进行把关、由谁批准生产发布以及回滚如何运作。
  • 在每次流水线和基础设施变更被合并或应用之前对其进行审查。
  • 密钥和生产访问权限：代理不会获得对实时系统的无限制访问权限。
  • 工具和平台的选择，包括何时使用 Kubernetes 带来的工作量会超过其价值。

一次变更，从提交到生产环境

这是 Web 产品的示意性发布路径；你的阶段、检查和审批人会与你共同商定。

  1. 提交

    一位开发者或 AI 编码代理推送一次变更；同一条流水线会为每一位作者启动。

    检查点: 代码评审在合并前获得批准

  2. 构建与测试

    应用被一次性构建为带版本号的制品，然后针对它运行单元测试、集成测试和端到端测试。

    检查点: 任何测试失败都会终止流水线

  3. 安全检查

    依赖项、密钥和容器镜像扫描，以及对诸如公开访问之类的高风险基础设施变更的检查。

    检查点: 严重的发现需要由工程师来决定

  4. 预演环境

    同一个制品在应用迁移后部署到预演环境；冒烟测试和 QA 检查在那里运行。

  5. 审批关卡

    一位指定的审批人审查测试结果、已知风险和回滚方案。

    检查点: 由一个人批准生产环境发布

  6. 逐步发布到生产环境

    发布先到达一小部分用户，然后扩展到所有人，同时监控错误和关键指标。

当出现故障时: 如果某项检查失败，变更会就此停止。如果在发布过程中错误上升，它会在任何人重试之前回滚到上一个版本。

您将获得什么

流水线、环境和发布控制

  • CI/CD 流水线

    在 GitHub Actions、GitLab CI、Jenkins 或您当前的工具中构建、测试和部署工作流，并配有必须在上生产前通过的测试和安全扫描。

  • 容器，在它们能发挥作用的地方

    用于保持环境一致的 Dockerfile 和 Docker Compose 设置。只有当您的服务确实需要时才使用 Kubernetes；通常一个托管平台就足够了。

  • 基础设施即代码

    纳入版本控制的 Terraform 或 Pulumi 定义，像应用代码一样接受审查，这样环境可以被重建，每次变更都可追溯。

  • 发布策略与回滚

    暂存环境、审批关卡、蓝绿或金丝雀发布以及功能开关，并在上线前测试好回滚路径。

  • 监控与可观测性

    使用 Prometheus、Grafana 或您云平台自带的监控等工具提供指标、日志和告警，并经过调优，使告警指向真正的问题。

  • 运行手册与移交

    提供文档、运行手册和培训，让您的团队能够运行这套设置，或者我们按照托管运营计划继续为您运行它。

谁会向我们寻求 CI/CD 工作

每次发布都像一件大事：变更不断堆积，检查只在有人想起时才运行，而撤销一次糟糕的部署意味着在压力下临时应变。

  • 仍然通过 SSH 或从托管面板手动部署的小团队
  • 现有流水线缓慢、不稳定或经常被跳过的工程负责人
  • 正在采用 AI 编码代理的团队，每次发布前有更多变更需要检查

典型的 CI/CD 需求

我们所界定范围的典型场景，而非客户案例研究。

  • 工程师已经不再等待的流水线

    每次提交都重新构建和测试整个代码仓库，于是工程师在结果出来之前就合并了。我们会按照变更内容拆分任务、缓存依赖，并保留完整测试套件作为发布前的必需检查。

  • 破坏部署的架构变更

    当数据库变更和依赖它的代码以错误的顺序发布时，发布就会失败。我们会将迁移作为其自身的、带把关的流水线步骤来运行，并规划向后兼容的变更，使回滚代码仍然可行。

  • CI 设置中的长期有效密钥

    部署凭证作为具有广泛生产访问权限的长期有效密钥存放在 CI 变量中。我们会将它们移入密钥管理器，在您的平台支持的地方使用短期有效凭证，并限制哪些任务可以读取每个凭证。

一次 DevOps 合作如何进行

  1. 01

    审查当前设置

    我们审查代码仓库、环境、部署步骤、访问权限和近期事故。AI 工具帮助梳理整个设置；工程师对其进行核实，并与您确定优先事项。

  2. 02

    设计发布路径

    流水线阶段、环境、发布策略、回滚计划和监控，规模与您的技术栈和团队相匹配。不做您不需要的编排。

  3. 03

    构建与演练

    我们以小的、经过审查的变更来实施，通过新流水线进行真实发布，并在切换前演练一次回滚。

  4. 04

    移交或运营

    为您的团队提供运行手册、文档和培训，或者按照约定的支持计划持续管理发布、监控和打补丁。

使用 AI 工具的两种方式

AI 协助处理基础设施代码和诊断。选择它可以在何处处理您的配置和日志。

不确定？我们会在界定范围时为您推荐一个。 比较 AI 交付选项

CI/CD 工作不包括的内容

  • 编写或扩展测试套件本身属于自动化测试。我们将你现有的测试连接起来，并让它们的失败阻止发布。
  • 全新的云架构、服务商迁移或网络重新设计属于云基础设施的范畴；本服务涵盖的是变更如何到达你运行的环境。
  • 事件响应和值班覆盖不属于流水线项目；它们在托管式 DevOps 与运维下单独约定。
  • 流水线扫描可以捕获代码、依赖项和镜像中的已知问题；但它们不能替代经过授权的渗透测试工作。

开发、设计、QA 和运营如何衔接

  • 开发工作流

    流水线遵循您团队的工作方式：分支规则、代码审查和预览环境，让工程师在变更合并前就能看到其效果。

  • 作为发布关卡的 QA

    自动化测试套件在每次变更时运行，QA 签核对重要发布进行把关。在任何人部署之前，测试结果和已知风险都是可见的。

  • 在真实构建上进行设计审查

    预览部署让设计师和利益相关方在发布前检查真实的页面和流程，而不是看截图。

  • 持续管理

    设置完成后，我们可以继续运行流水线和环境：发布、监控、打补丁和恢复测试，这些都在支持计划中约定。

常见问题

常见问题解答

我们需要 Kubernetes 吗？

通常不需要。许多产品在诸如 Vercel、Railway 或云容器服务这样的托管平台上运行良好，或者用单台服务器上的 Docker Compose 运行。当您运行许多服务、需要细粒度扩缩容或拥有运维它的技能时，Kubernetes 才有意义。我们推荐能满足您需求且日后可以扩展的最简单设置。

你们推荐哪种 CI/CD 工具？

通常是离您代码最近的那个：GitHub 仓库用 GitHub Actions，GitLab 用 GitLab CI。如果您的团队依赖 Jenkins 或其他工具，我们可以改进它而不是替换它。这个选择取决于您的代码仓库、安全要求以及由谁来维护流水线。

你们能改进或迁移我们现有的设置吗？

可以。我们保留有效的部分，修复无效的部分。对于迁移，我们会在可能的情况下让新旧路径并行运行，分阶段转移流量，并保留一条回滚路线直到新设置得到验证。欢迎用 AI 工具构建的应用；我们会先对它们进行审查。

我们的代码和配置在哪里由 AI 工具处理？

仅在您同意的工具和环境中，这在工作开始前就已确定。私有/本地 AI 工程使用托管在您控制的基础设施上或约定的隔离环境中的模型。Claude Code / OpenAI Codex 工程使用商业编码代理，并采用约定的账户和数据保留设置。无论哪种方式，我们都会让密钥和凭证处于 AI 工具无法读取的范围之外。

相关阅读

让发布成为常规，而非风险

告诉我们您今天是如何部署的。我们会建议首批值得做的变更，可以作为一个项目，也可以作为持续的托管运营。

沟通您的项目讨论您的流水线