初创公司的 CI/CD：在不破坏东西的情况下更快地交付

每周发货的初创公司的表现优于每月发货的初创公司。 CI/CD 是您每周交付而不部署错误的方式。 这是一个充满信心地快速行动的团队和一个快速行动并每隔周五就停止生产的团队之间的区别。

如果您正在运营一家拥有 2-10 名工程师的初创公司，并且您仍然通过 SSH-ing 到服务器或单击“合并”并祈祷进行部署，本指南将引导您完成所需的最低 CI/CD 设置。 配置需要一个下午的时间，免费套餐的费用为 0 美元/月，并且在用户第一次发现错误时就可以收回成本。

CI/CD 用简单的英语来说意味着什么

持续集成（CI）意味着每个代码更改都会自动测试。 当开发人员打开拉取请求时，服务器会根据新代码运行 linter、类型检查器和测试套件。 如果出现任何问题，PR 会得到一个红色的 X，并且在问题得到解决之前没有人会合并它。

持续部署 (CD)意味着每个通过的测试都会自动部署。 当代码合并到主分支时，系统会构建它，将其推送到暂存区，并可供审查。 只需单击一下即可进行生产部署，或者如果您信任您的测试套件，则可以自动进行。

就是这样。 CI 在 bug 到达您的主分支之前捕获它们。 CD 将经过验证的代码推送给您的用户，无需手动干预。 他们一起将“它在我的机器上运行”对话替换为“它通过了管道”。

为什么初创公司会跳过它（以及为什么这会让他们付出代价）

手动部署工作于2名工程师。 一个人编写代码，另一个人对其进行审查，有人在服务器上运行 git pull，并且该功能已上线。 感觉很快，因为反馈循环很短。

他们在 5 点就崩溃了。当五名工程师推送代码时，您会遇到合并冲突、功能之间未经测试的交互以及随机发生的部署。 当其他人正在部署时，有人进行合并。 服务器上周二的修补程序有未提交的更改。 没有人确定哪个版本正在生产中运行。

当你有 10 名工程师时，手动部署会导致每月 2-3 次生产事故。 每个事件都需要 2-4 小时的工程时间来诊断和修复。 这相当于每个月损失 4-12 个小时的高级工程师时间； 你用工资支付但产品价值为零的时间。

数学很简单。 高级工程师的费用为 75-150 美元/小时。 每月 12 小时的事件响应费用为 900 至 1,800 美元。 设置 CI/CD 需要一下午的时间，免费套餐的费用为每月 0 美元。 您可以在第一个月内收回设置时间。

最小可行的 CI/CD 管道

您不需要包含 200 个步骤的 45 分钟管道。 您需要进行五次检查，才能在 bug 进入生产环境之前捕获 90% 的 bug。

1. 每个 PR 上的 Lint

Linting 可以捕获样式问题、未使用的变量和常见错误。 具有标准配置（如 Airbnb 或 Next.js 预设）的 ESLint 需要 5-15 秒才能运行，并捕获否则会在代码审查中出现的问题。 这使您的审阅者能够专注于逻辑和架构，而不是格式化参数。

2. 对每个 PR 进行类型检查

如果您正在使用 TypeScript（您应该使用），请在每个拉取请求上运行 tsc --noEmit 。 这可以捕获编辑器可能错过的类型错误； 特别是您没有直接更改但取决于您修改的代码的文件中的错误。 CI 中发现的类型错误需要 2 分钟才能修复。 同样的错误在制作中被发现花费了2个小时。

3. 对每个 PR 运行测试

自动化测试验证您的代码是否执行了它应该执行的操作。 范围广泛的测试套件在 30-90 秒内运行，并捕获 linting 和类型检查遗漏的逻辑错误。 您不需要 100% 的覆盖率。 您需要对处理资金、用户数据和核心业务规则的代码路径进行测试。

4. 合并到 main 时自动部署到 staging

当 PR 通过所有检查并合并时，管道将构建应用程序并将其部署到临时环境。 这为您的团队提供了一个实时 URL，产品经理、设计师和客户可以在更改投入生产之前在其中查看更改。 不再有“您可以部署到暂存以便我可以测试它吗？” Slack 中的消息。

5.一键部署到生产

生产部署应该需要一个单独的深思熟虑的操作：单击按钮、运行命令或合并到生产分支。 关键词是商榷。 您希望有人决定“是的，这已经为用户准备好了”，但您不希望该人运行 15 个手动步骤来实现这一目标。

工具和成本

您不需要花钱来获得有效的 CI/CD 管道。 此列表中的每个工具都有一个免费套餐，涵盖早期初创公司。

GitHub 操作公共存储库免费，私人存储库每月包含 2,000 分钟。 对于一个由 5-8 名工程师组成的团队每周推送 20-30 个 PR 来说已经足够了。 您的 lint、类型检查和测试步骤作为每个拉取请求触发的工作流程运行。

韦尔塞尔每次推送时自动部署，为您提供每个 PR 的预览 URL，并开箱即用地处理临时和生产环境。 免费套餐涵盖大多数初创公司，直到它们达到大量流量为止。 如果您使用 Next.js、Astro 或任何前端框架进行构建，Vercel 是最快的 CD 路径。

铁路通过 GitHub 自动部署来处理后端服务、数据库和后台工作人员。 定价从 5 美元/月起，之后根据使用情况计费。 对于需要静态托管以外的功能的全栈应用程序来说，这是一个强大的选择。

Fly.io将 Docker 容器部署到靠近用户的服务器。 它非常适合需要跨区域低延迟的 API 和服务。 免费套餐包括 3 个共享虚拟机和 160GB 出站传输。

测试什么以及跳过什么

测试一切都会让你的管道变慢。 不进行任何测试就没有安全网。 正确答案位于中间。

测试你的业务逻辑。如果您的应用程序计算定价、验证用户输入、处理付款或应用折扣规则，请为这些功能编写测试。 这些是错误导致金钱损失的代码路径。

测试您的 API 端点。发送请求，检查响应状态和正文。 这可以捕获单元测试遗漏的路由错误、中间件错误和序列化问题。

跳过 UI 像素测试。不要测试按钮距其容器顶部是否为 16 像素。 每次您更改布局并捕获零真正的错误时，这些测试都会中断。

跳过框架内部。不要测试状态改变时 React 是否重新渲染。 React 团队已经对此进行了测试。 测试您的代码对渲染输出的作用。

部署信心阶梯

管道中的每个步骤都增加了代码可以安全部署的信心。 将其视为一个梯子，每个梯级捕获不同类别的错误。

皮棉捕获格式问题和常见错误。类型检查捕获不匹配的数据形状和空引用错误。单元测试捕捉损坏的业务逻辑。集成测试捕获组件和服务之间中断的交互。分期预览捕获自动化测试遗漏的视觉回归和用户体验问题。生产是最后一步，真实用户与经过验证的代码进行交互。

大多数初创公司都需要前五级。 您可以尽早跳过集成测试，并在系统变得足够复杂以证明其合理性时添加它们。 但 lint、类型、单元测试和暂存预览从第一天起就是不可协商的。

预览部署改变了团队审查代码的方式

每个 PR 都会有一个实时 URL。 不是 Slack 线程中的屏幕截图。 不是屏幕录制。 应用程序的实时交互式版本，其中包含在真实服务器上运行的建议更改。

产品经理点击该功能并在 PR 上留下评论。 设计师在自己的屏幕上检查间距和版式。 客户无需等待演示电话即可实时查看进度。 这将反馈周期从几天缩短到几小时。

Vercel 和 Netlify 开箱即用地执行此操作。 每次推送到 PR 分支都会生成一个唯一的预览 URL，该预览 URL 在您推送新提交时会自动更新。 除了连接 GitHub 存储库之外，无需进行任何配置。

在 Savi，预览部署消除了“它在我的机器上看起来不同”的对话。 利益相关者在代码最终运行的同一环境中审查功能。 如果它可以在预览 URL 上运行，那么它就可以在生产环境中运行。

拖慢团队速度的常见错误

测试一切。25 分钟的流程会降低开发人员的速度。 工程师避免打开 PR，因为反馈循环太慢。 将 lint、类型和单元测试的管道时间控制在 3 分钟以内。 如果需要更长的时间，则说明您测试过多或测试范围不明确。

什么都不测试。没有测试就意味着没有安全网。 当然，你会更快地发送错误，但你也会花早上的时间来修复前一天晚上发送的内容。 从涵盖核心业务逻辑的 10-20 个测试开始，然后从那里开始发展。

没有暂存环境。直接从 PR 部署到生产意味着每次合并都是一场赌博。 暂存为您提供了在镜像生产环境中发现问题的最后一次机会。 Vercel 免费套餐的费用为 0 美元，Railway 的费用为每月 5-20 美元。

周五下午 5 点部署。这是一个文化问题，而不是技术问题。 如果有什么东西坏了，没有人会来修理它。 您的用户在周末处理损坏的产品，而您的团队在周一早上进行损害控制。 设定团队规则：周五下午 3 点后不进行生产部署。 更好的是，周五根本不部署任何生产。

Savi 如何设置每个项目

我们将 CI/CD 配置为每个构建的一部分，而不是事后的想法。 以下是每个 Savi 项目在第一天就附带的内容。

CI 的 GitHub 操作。每个 PR 都会触发一个运行 ESLint、TypeScript 类型检查和测试套件的工作流程。 如果任何步骤失败，则无法合并 PR。 分支保护规则强制执行这一点，因此没有人可以绕过管道，甚至项目负责人也不能绕过。

CD 的 Vercel 或 Railway。前端应用程序部署到 Vercel，并在每个 PR 上自动预览 URL，并在合并到主程序时部署生产。 后端服务以相同的触发模式部署到 Railway。 如果部署未通过运行状况检查，两个平台都会处理回滚。

预览部署在每个 PR 上。客户和利益相关者可以获得每个功能分支的实时 URL。 他们在浏览器中进行审查，对 PR 留下反馈，并在代码投入生产之前进行批准。 这用直接交互取代了演示通话和屏幕录制。

自动类型检查和 linting。我们运行严格的 TypeScript，没有隐含的 any 和 ESLint，其规则经过调整以捕获真正的错误，而不是样式偏好。 这些检查会增加 15-30 秒的时间，甚至在人工审阅者查看代码之前就捕获了 60-70% 的问题。

此设置需要在项目开始时配置一个下午。 它在产品的整个生命周期内自动运行。 投资回报率是通过永远不会进入生产的错误、永远不会出错的部署以及用于功能而不是救火的工程时间来衡量的。

常见问题