Add rsync_direct deployment strategy

[shanedroid]

Adds a rsync_direct deployment strategy which is slightly faster than the default rsync because it skips the copy step from the ansistrano_shared_rsync_copy_path to ansistrano_release_path for #243

[ricardclau]

Sorry about the delay here... this is problematic as you cannot use the rollback role in this strategy. I am not against merging this but probably worth pointing that out in the README as well?

[shanedroid]

this is problematic as you cannot use the rollback role in this strategy. I am not against merging this but probably worth pointing that out in the README as well?

Why can't the rollback be used? We are using this now and have still used ansistrano.rollback with it. I thought that during a rollback the actual release dir is what is used not the shared?

https://github.com/ansistrano/rollback/blob/master/defaults/main.yml#L6

ansistrano/rollback#3 (comment)

[ricardclau]

Oh sorry, my bad, I was thinking you would rsync to the same folder all the time but with this approach you basically upload everything in every deployment as rsync always compares to nothing so of course rollback can be used. However, I cannot see how this can be faster than the current approach TBH.

The intermediate folder was designed so that the network transfer was always minimal as generally speaking you would not change many things in every deployment and this strategy is often used from development computers to servers and not from, say, a Jenkins server in a close network to the final server.

I am curious, have you actually benchmarked it? How many files approx are there in your repos? Some assets or mostly code? Maybe with the connections we have these days and considering most cloud drives are actually network drives (local, but still network) it might not be relevant anymore.

[shanedroid]

I have not personally benchmarked it - simply started using this method when we saw that it was marginally faster, primarily using this to deploy to EC2 in AWS, it made sense to just skip the extra local copy of files. Saw #243 so figured maybe others would use it too. For deployments where static assets got hosted along side any app src the time boost could start to get pretty substantial though. Can mention in README for clarity so people have a TLDR, when deciding which rsync strategy to use?

[ricardclau]

Yeah, perhaps adding some short TLDR would do so people can test both rsync approaches if interested.

Some EC2 instance types (looking at you, low end t3) have quite poor EBS performance and it these cases the extra copy can potentially make it slower in some codebases. Same could happen in shared hosts or other places where the drives are not having good performance.

At the end of the day, having options can't be bad :)

Thanks for your patience and waiting for some final tweaks!

[ricardclau]

Nice one! Thanks for your work! Merging and adding a new tag!