我正在运行Capifony部署。但是，我注意到Capifony的内置命令正在针对之前的版本运行，而我的自定义命令正确地针对当前版本。
例如，如果我运行cap -d staging deploy，我会看到一些命令输出（添加了换行符）：
--> Updating Composer.......................................
Preparing to execute command: "sh -c 'cd /home/myproj/releases/20130924144349 &&
php composer.phar self-update'"
Execute ([Yes], No, Abort) ? |y|
你会看到这是指我之前的版本 - 从2013年开始。
我还看到有关这个新版本文件夹的命令（从2014年开始）：
--> Running migrations......................................
Preparing to execute command: "/home/myproj/releases/20140219150009/
app/console doctrine:migrations:migrate --no-interaction"
Execute ([Yes], No, Abort) ? |y|
在我的命令中，我使用#{release_path}变量，而在查看Capifony的代码时，它使用的是#{latest_release}。但显然我无法改变Capifony的代码。
This issue against Capistrano谈论类似的事情，但我不认为它真的有帮助，因为我再也无法改变Capifony的代码。
如果我删除了服务器上的releases文件夹，我遇到了类似的问题 - #{latest_release}没有任何值，因此会尝试执行以下操作：文件夹/app/cache（因为代码类似于mkdir -p #{latest_release}/app/cache）。
（假设我没有删除current符号链接和release文件夹，我看到的具体错误是它无法复制供应商：cp: cannot copy a directory, /home/myproj/current/vendor, into itself。但是，这只是更大问题的症状 - 如果它认为新版本实际上是前一版本，那就解释了为什么current也指向那里！）
有什么想法吗？我很高兴提供我的deploy.rb或staging.rb（我正在使用多级扩展）的摘录，但不仅仅想要丢弃整个内容，所以让我知道你是什么有兴趣！感谢
答案 0 :(得分：0)
我终于到了这个底部！
我在部署之前设置了一个步骤：
before "deploy", "maintenance:enable"
此维护步骤（正确）在现有站点上设置维护模式（在上面的例子中，我的2013年）。
但是，维护任务是使用latest_release变量引用以前的版本。由于步骤在部署之前运行，latest_release确实参考了2013版本。但是，一旦使用了latest_release，就会为其余的部署运行设置其值 - 因此它仍然设置为2013版本！
因此我通过更改维护代码解决了这个问题，因此它没有使用latest_release变量。我使用current_release代替（似乎没有这种副作用）。但是，另一种方法是定义自己的变量，其变量的值与latest_release的变量相同：
set :prev_release, exists?(:deploy_timestamped) ? release_path : current_release
我通过查看Capistrano代码了解了latest_release是如何设置的。在我的环境中，我可以通过bundle show capistrano找到它（因为它是用bundler安装的），但是其他设置的方法会有所不同。
虽然我的问题的原因非常具体，但我的方法可能有助于其他人：我在Capifony instructions之后创建了一个完全普遍的部署，并逐渐添加了旧部署的功能，直到它崩溃！