手动部署这件事，在站点还不大的时候看不出问题。你本地改完文件，用工具传到服务器，或者拉一下代码、跑一遍构建、重启服务，前后几分钟就完事。等站点长起来就不一样了：改动要同时落到几个文件，前端要打包，缓存要刷新，有时候还要先跑一遍检查。步骤一多，漏一步的概率就跟着上来了。漏掉的那一步在本地往往看不出来，只有等用户反馈或者第二天看数据才暴露，中间隔着一段毫不知情的空窗期。
更麻烦的是“人”这个变量。同一套部署流程，不同的人执行会有细微差别，同一个人在不同状态下的执行也会有差别——忙的时候跳过一个步骤，急的时候少跑一项检查。出事之后回头看，问题往往不在代码本身，而在“那次部署少做了某件事”。把流程交给机器执行，最大的价值不是快，是每次都一样。
这正是持续集成与持续部署这类平台要解决的问题。按GitHub官方文档的说明，它允许你自动化构建、测试和部署流水线：可以在代码推送时自动跑测试，也可以在合并之后自动部署到生产环境。触发条件和执行内容都写在一份配置文件里，跟着代码一起进仓库，改流程和改代码走同一条路。这也意味着流程可以和代码一起被审查、被回滚，谁在什么时候改了什么，记录是完整的，不像过去那样只存在于某个人的记忆里。
部署这件事，能自动就别靠手动
先说清楚它是怎么组织的。配置写成一份工作流文件，放在仓库根目录下一个固定的目录里，文件名可以任意起，但扩展名必须是yml或者yaml。官方特别提示了一件事：如果文件没放在那个约定的目录下，平台是发现不了这份工作流的。很多人第一次配完发现不生效，多半就是卡在这里。
一份工作流大致包含四部分。第一是名字，方便自己在列表里认出来；第二是触发条件，比如在某个分支被推送时、在某个合并请求被合入时，或者按时间定时执行；第三是一个或者多个任务，每个任务声明它跑在什么环境上；第四是任务里的步骤，步骤要么执行一条命令，要么引用一个现成的动作。这种结构的好处是边界清晰：任务之间默认相互独立、并发执行，步骤之间则按顺序走，搞清这层关系，写复杂流程时就不容易乱。
这套结构的好处是可组合。官方仓库里有一批预置模板，覆盖持续集成、部署、自动化、代码扫描、静态页面发布等常见场景，可以直接套用或者改。别人写好的动作也能直接引用，不用从零造轮子——比如检出代码、准备运行环境、上传构建产物，这些高频动作都有现成的。引用现成动作时要留意版本，最好把版本号写清楚，而不是用默认的最新版，否则上游哪天更新了行为，你的流程可能在某次推送后突然失败。
放到站长场景里，最常见的用法是自动发布。把站点源码放进仓库，写一份工作流：推送时先构建，构建成功再把产物同步到服务器或者对象存储，最后触发一次缓存刷新。之后你的发布动作就变成一次提交，剩下的交给流水线。原先需要记住的那串命令、需要人盯着的那几分钟，都不再依赖记性。
它还有一个隐性好处，是留下了记录。每次执行都会有一份日志，显示哪个步骤成功、哪个失败、失败在哪一行。这对排查很有用：上线之后发现页面不对，可以先看这次部署有没有异常的步骤，而不是凭印象猜“是不是刚才哪个命令没跑”。手动部署在这一环上是空白的，没人知道当时具体做了什么。这份记录在交接的时候尤其有价值，新接手的人不需要问平时怎么发版，翻一遍历史执行就能看明白整套流程。
要注意的边界有几条。第一，它跑在平台提供的运行环境上，这个环境是临时的、干净的，你本地装过什么它一概没有，依赖必须显式安装；第二，涉及密钥、服务器地址这类敏感信息，要用平台的加密变量保存，不要写死在配置文件里，因为仓库可能是公开的；第三，免费额度对个人和小团队通常够用，但执行频繁的项目要留意用量。
还有一条经验值得提前说：不要一上来就把生产发布全托管。先用它做只读的事，比如自动跑测试、自动检查死链、自动构建但不部署，跑一段时间确认稳定了，再把发布也接进去。这样出错时影响面小，你也能先摸清它的行为习惯。上线流程一旦自动化，回滚同样要预留手段，别把“想撤回来”当成例外。
自动部署真正的价值，不是省下那几分钟操作时间，而是把一套本来靠记忆和自觉维持的流程，变成一件确定的事。人会在忙的时候漏步骤，机器不会。当你不再需要为了发一次版本而紧张地核对清单，就可以把注意力放回到内容本身——这大概是把部署交出去之后最直接的收益。省下来的注意力用在选题、写作和回复用户上，长期看比多按几次部署按钮划算得多。
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
