The basic “cap deploy:cleanup” does its job well, but can leave traces behind.
I recently picked up that one of my servers in a Rails cluster had plenty more release directories than its peers, and they were very old. I was baffled, how does this happen when I run “cap deploy:cleanup” religiously after a release has stabilized… I decided to figure out why, and how to dodge it. Who knows how many other release directories are scattered around the network.
It seems that cap gets the directory contents of the “releases” directory from the first server in its internal list. It then uses that directory content to remove stale releases from all servers. This is a sane approach, but things do go wrong and releases will build up over time.
Running the task once for every host seems the quick solution without messing with cap itself.
$ cap deploy:cleanup HOSTS=10.0.0.1
This gives each individual host a fresh start. From here, lather, rinse, repeat.
Later