[tschellenbach]

Yes, someone should build the one way to ship your app. No reason for everybody to be inventing this stuff over and over again.

Deploys are harder if you have a large codebase to ship. rSync works really well in those cases. It requires a bit of extra infrastructure, but is super fast.

[erikb]

Deployment is hard, system administration is hard. As a software developer you think there should be one way but there can't be one way. There never will be. If you want to make good software really spend some time learning the intricacies of packaging, deployment and sysadmin life. You make a lot of people happy by just knowing the problems, even if you can't apply the correct solution to each problem.

Come from the same island as you, trust me. But the more you learn about this the more you see how complex it is. You can't even say that one solution is better than the other (like apt vs yum). Each and every one of them has their pros and cons. And more often than not architectural decisions make it impossible to get both solutions into the same system working together.

rSync is not deploying. It's syncing files. But even if you have a 1:1 copy from your development computer on a server it still might not work because on that server package xyz is still in version 1.4.3b and not 1.4.3c. Deployment is getting it there AND getting it to work together nicely and maintainable with the other things that run on that computer/vm.

[mattbillenstein]

+1 rsync is pretty darn good at any scale -- I'm not sure why the simplest solution possible doesn't beat out docker as a suggestion in this thread.

I've been bundling libs and software into a single virtual environment like package that I distribute with rsync for a long time - it solves loads of problems, is easy to bootstrap a new system with, and incremental updates are super fast. Combine that with rsync distribution of your source and a good tool for automating all of it (ansible, salt, chef, puppet, et al) and you have a pretty fool-proof deployment system.

And a rollback is just a git revert and another push away -- no need to keep build artifacts lying around if you believe your build is deterministic.

[viraptor]

Rsync is good for simple things. But it will fail with more complicated apps:

- how do you know which version you're running right now?

- how do you deploy to two environments where different deps are needed?

- how do you tell when your included dependencies need security patches?

[mattbillenstein]

rsync isn't the complete system - you're going to need git (or another vcs) and some other tools of course.

#1 is git (dump and log the git head on a deploy) #2 don't do that - keep a single consistent environment #3 use the system openssl - monitor other software components for security updates -- you need to do this anyway in any of these systems.

[viraptor]

> #2 don't do that

I wish everyone to have easy deployments where environments, OS versions and everything else are always consistent. :)

> #3 monitor other software components for security updates -- you need to do this anyway in any of these systems.

Sure. But having multiple virtualenvs means you need to monitor all of them on all of deployed hosts. Having everything packaged separately means you can do audits much easier and without location-specific checks.

[stephenr]

They have. Every mainstream OS/Distro has a packaging system and an installer for those packages.

For server-side apps like this, that usually means a Deb or an RPM. These systems handle upgrades, rollbacks, dependencies, etc.

Just because some people decide that writing an RPM specfile or running dh_make is too hard to work out, doesn't mean that the solution doesn't exist.