一键部署

这是什么

一键部署意味着你所描述的那个应用，从构建到在互联网上线，不需要你做任何配置。ybuild 编译前端、开通后端、连接数据库和认证，并把整套东西对外服务——托管在平台上、在你自己的域名上。没有要搭建的构建流水线，也没有要推送的另一个主机。

为什么重要

「在构建器里能用」和「客户可以用」之间的那道鸿沟，是大多数项目夭折的地方。即时部署，并且每次改动都重新部署，才是让一个业务系统真正运行起来、而不是永远卡在「进行中」的关键。上线必须是最轻松的那一步，而不是一堵墙。

在 ybuild 上怎么用

当你的应用准备好了，ybuild 一个动作就把整个全栈——前端、后端、数据库和认证——部署好，并在你的域名上上线服务。你之后做的每一次改动都以同样的方式重新部署，就地更新运行中的应用。你从不用碰构建配置、服务器，或任何外部托管账号。

「部署」到底做了什么，以及为什么它往往是最难的一步

「部署」听起来像是一个按钮，但在底层，它其实是一堆彼此独立的任务必须同时全部成功、你的应用才能在公网上响应一个真实请求的那一刻。对一个全栈业务应用来说，这意味着至少有六件不同的事情要按正确的顺序发生。

前端必须被编译并打包成经过优化的静态资源，从离你客户最近的边缘节点快速加载。后端——运行你业务逻辑和 API 的那部分——必须在真实的服务器上被开通并启动。数据库必须被创建、它的结构迁移必须被执行，这样你应用所依赖的那些表在第一个请求到达之前就已经存在。环境配置和密钥——连接字符串、API 密钥、各个服务用来找到彼此的地址——必须被正确注入，因为一个错误的值就足以让一个可用的应用变成一整页 500 错误。域名必须被绑定、TLS 必须被终止、流量必须被路由。最后，新版本必须以原子方式切换上线，这样任何客户都不会落在一个只更新了一半的应用上。

正是这个流程，让手动部署成了时间凭空消失的地方。每一步都在不同的工具里，每一步都有它自己悄无声息失败的方式，而这些失败往往要等到应用理应「已经上线」时才暴露出来。最经典的灾难，就是在你自己机器上跑得完美无缺的构建，到了生产环境却只返回一堆错误——只因为某个环境变量从没被设置，或者某个迁移没有运行。

ybuild 在一次运行里把这六件事全部做完，因为这个应用本来就是它构建的。它早就知道自己设计的数据库结构、后端暴露的路由、每个服务需要的密钥，以及你连接的域名——所以没有什么要手动配置，也没有什么会被悄悄配错。你点击部署；整个全栈系统就托管在 ybuild、在你自己的域名上运行起来，端到端全部接好。

自己搭一套部署流水线 vs. 在 ybuild 上直接拥有它

值得诚实地聊聊「自己动手」这条路，因为正是在这里，一个动作的价值才变得一目了然。

靠你自己，上线本身就是一个项目：挑选主机，把运行环境容器化或配置好，接一套 CI/CD 流水线让一次改动真的能到达生产环境，管理构建设置和每个环境各自的变量，按正确顺序运行数据库迁移，为迁移失败的情况写好回滚脚本，安排一次零停机切换让站点在更新时不会闪断，然后永远为每一层打补丁维护下去。这些没有一样是你客户为之而来的那个应用。它们只是那套必须完美无瑕运转、客户才能看到应用的机器。

关于这一点的研究出奇地清晰。DORA——谷歌长期运行的 DevOps 研究与评估项目——发现最高绩效的团队都有一项共同能力：他们能够「快速、安全、可持续地按需发布各种变更」，在任何时间推送到生产环境，包括正常工作时间内，而不打扰用户。正是这项能力，把顶尖交付团队和其他所有人区分开来。问题在于，按传统方式做，它要一支专门的平台或 DevOps 团队花上几个月来搭建和维护。

ybuild 把这一整套栈压缩成一个动作，于是一个单打独斗的创始人或一支小团队，就能获得顶尖团队级别的部署能力，却不需要顶尖团队的人手。你用一段提示词描述这个应用，它被构建成一个运行中的全栈系统，然后一键上线——托管在 ybuild、在你自己的域名上。当你改动什么——一个新字段、一个新页面、一个新价格——它以同样的方式重新部署，就地更新线上版本。没有导出，没有 zip 压缩包，没有第二个要登录的主机，也没有一条你必须自己维护的流水线。那套机器是平台的问题；应用、数据和域名是你的。

上线的那些坑，以及持续部署对一门真实生意意味着什么

有几个边界情况几乎绊倒了每一个手动部署的人，而值得知道的是 ybuild 把它们都吸收掉了。第一次上线就坏掉——本地能跑、生产环境却挂——几乎总是因为缺了一个环境变量，或者一个迁移从没运行过；因为 ybuild 把后端、数据库和配置从它构建的那个应用里一起开通出来，两个世界之间根本没有可供这类问题藏身的缝隙。破坏性迁移——一次结构变更悄悄删掉一列、连带带走真实客户数据——正是那种 ybuild 替你打理、而不是留给你在半夜手写 SQL 脚本去冒险的错误。而停机窗口——一次天真的部署在切换版本时让站点停摆的那几分钟——被就地更新取代，于是运行中的应用在整个变更过程中持续对外服务。

更深的那个坑是心理上的。当部署既可怕又要手动，人们就会把改动攒成一批、很少发布，这让每次发布都更大、更冒险、更痛苦——恰恰和有效的做法相反。DORA 在这里的发现虽然反直觉却证据充分：小而频繁的部署，比稀少而庞大的部署更安全。以小批量发布能「减少部署痛苦」、降低变更失败率，并让团队在几分钟而非几天内从问题中恢复。频繁发布不是冒险的选择；它才是可靠的那个。

对一门运行中的生意来说，这改变了「发布」的感觉。一位客户要求在预订表单上加一个字段，你在定价页上发现一个错别字，一场促销需要在周末前上线——有了一键重新部署，这每一件都能在几分钟内上线到你的域名上，而订单还在不断进来、客户还保持登录状态。你不再为了一次让人害怕的「大更新」而囤积改动，而是一发现问题就立刻去修。部署不再是一堵你要绷紧神经去面对的墙，而变成一件你几乎不会去想的小事——而这，正是一个运行中、被托管的业务系统本该有的感觉。

常见问题

我需要配置服务器或主机才能让应用上线吗？

不需要。没有任何东西要配置——ybuild 一步就替你部署整个技术栈。它编译前端、开通后端、连接数据库和认证，并把应用托管在 ybuild、在你自己的域名上对外服务。你从不用挑选主机、搭建流水线，也不用碰任何构建配置。

我点击部署时，到底发生了什么？

在一次运行里，ybuild 构建并优化前端、启动后端、创建数据库并运行它的迁移、注入每个服务所需的配置和密钥、为你的域名绑定 SSL，然后干净利落地切换到新版本。因为应用是 ybuild 构建的，它早就知道每一个部件——所以没有什么要你去接线，也没有什么会被悄悄配错。

从提示词到一个上线的应用，能有多快？

很快——上线是一个动作，而不是一个单独的项目。一旦应用从你的提示词被构建出来，一键就能部署整个全栈系统，并把它托管在 ybuild、在你自己的域名上对外服务。在「它能用」和「客户可以用」之间，没有 CI/CD 搭建，也没有主机账号横在中间。

我推送更新时，应用会不会宕机？

不会。你做的每一次改动都会就地重新部署，在没有维护窗口的情况下更新运行中的版本。订单在整个变更过程中持续进来，客户也保持登录状态。正是这一点，让你可以一发现就放心地推送小修复，而不必为一次冒险的「大更新」而囤积它们。

如果新版本出了问题怎么办？

你绝不会被一个坏掉的部署困住。因为 ybuild 托管你的应用并保留你的版本历史，你可以一键回滚到上一个可用版本，你域名上的线上站点会在片刻之间重新提供那个好的构建。小而频繁的部署，加上即时回滚，正是让你能持续改进一门运行中的生意、而不必在每次编辑时拿它去赌博的原因。