缘起
记得上一次线上部署是3月29日，使用cap production deploy，没有什么问题，顺利部署。
今天跟新了几行代码，没动capistrano相关的部分，执行部署命令，居然直接abort异常退出了！百思不得其解。
报错如下：
(Backtrace restricted to imported tasks)
cap aborted!
Don't know how to build task 'start' (see --tasks)
Tasks: TOP => production
(See full trace by running task with --trace)
找原因
加上--trace看了一下，没找到明显的提示。
只好祭出google了。搜索一下关键字，看了几条结果，好像不搭边。再精确提炼一下关键字。
从报错中提取一行关键信息，Don't know how to build task 'start' (see --tasks)，去掉后面的(see --tasks)，因为原则上尽量不要给搜索引擎增加处理特殊符号的负担，再加上主题词capistrano, 因为主要是它的问题。
最终的搜索关键字如下：
capistrano Don't know how to build task 'start'
这样的话问题逻辑上就会被限定死。如果这样没有结果，搜索这条路子就至此了。
果然，看到第三条，还是stackoverflow，有人说了
Add install_plugin Capistrano::Puma into your Capfile after require 'capistrano/puma'.
capistrano3-puma moved to 3.0 a few days ago. This line is required for loading default puma tasks in this version.
See https://github.com/seuros/capistrano-puma#usage
解决方法
特别是再看到moved ... a few days ago时，心中一阵喜感，觉得有希望了。
试一下再Capfile中加入
install_plugin Capistrano::Puma
执行bundle后，再运行部署命令就正常了。
总结思考
-
搜索时关键字选取很重要。 尽量去除一些介词、连词、语气词，去除特殊符号。因为在后台处理时这些也是要先去掉的，加上以后反而会给搜索引擎增加负担，从而影响搜索结果，不如我们先人工过滤一遍。
-
如何避免类似事件？ 考虑真正的原因，本地相关代码都没动，唯一动的就是执行了几遍
bundle命令，如果gemfile中指定的目标是github，这样应该会把相关库一些最新代码同步下来，而配置没有自动同步下来，引发错误。引发此类问题的另外一个原因，可能由于删除了Gemfile.lock文件，再执行bundle命令，就会导致某些gem版本更新，或者由于这里gem中没有指定版本，或没有严格限制为某一版本，这样的话会是使用最新的。如果在gem明确不更新大版本的话，就不会引入breaking change。具体参考semantic versioning的用法。