[callumacrae]

rsync
git
scp

[Lemon]

There's probably a million ways, depending on how you complex you want to get. Most simple:
- Just SFTP into the htdocs directory in the first place and put the files there instead. This would save having to do the SSH part of the process.
- Partly similar to the above, change the http server's root directory to the folder you are currently SFTPing the files to.

A lot of IDEs have the option to upload to the server automatically, either on save or when you want to publish, meaning the above options can be made into one click options

More complex:
- If you are using Git, you could setup a repo on the server as a remote to your local repository. Then have a post receive hook that checks out the latest commit of a certain branch to the htdocs directory. Then, to publish the latest code, you'd do something like

git push live

on your local machine. Edit: Here's a tutorial for this method

[Wyatt]

rep to both thanks guys, git is exactly what i wanted but i couldnt find a tut

[Daniel15]

Git is often overkill, unless you're already using it for your project. I'd just use rsync

I'm on my phone but can't check, but I think the syntax I normally use is

rsync -avz --progress /home/filesyouwanttocopy username@server:/var/www/whatever

[callumacrae]

Git <3!

[Ruku]

Git is not a deployment tool, guys. Versioning shouldn't be the production server's issue, and you definitely don't need all those prior revisions cluttering up its disk. Doing a Git push is convenient from a devops perspective, but storing history in production really isn't optimal.

[Lemon]

I partly agree; however, for the scale of projects most of us work on, Git is both something we know and a satisfactory stand in for a full on deployment system. From what I've seen around here, our personal projects generally don't have massive code bases, have maybe one or two servers and don't have much in the way of pre-deployment unit testing; in this position I would be hesitant to setup a deployment system that is more complicated than the code is. However, obviously for a larger site where all the above are not the case, I clearly wouldn't expect Git to be a choice for deployment as there are other tools that make code testing and distribution easier.

Whilst I would usually suggest learning the absolutely correct way first time around, in this case it makes very little sense to spend time setting up or building a deployment path when Git acts a reasonable, albeit not perfect, stand in. Going the fully correct way raises the question: at what point do you stop trying to emulate a large scale (and finance) site and accept that the tools that you already know, such as Git, work well enough for what you're trying to achieve? Do we decide that pushing to a live server is no good and have to fork out for another? Do we decide that we must have staging servers to test stuff out? All of these things cost time and potentially money, both of which small projects have little of. I'd much rather chuck things at a Git remote until I can be sure the project is going to work out; the staging and other servers can then be what you can strive for as they become a necessity.

Therefore it's all about reaching a balance between learning how to build a solid deployment system and actually having enough time to spend on your product. As your site grows, the deployment is relatively easy to replace, but a bad code-base is a lot harder; so I'd prefer to spend time getting the code right than the deployment.

[Daniel15]

rsync is just as easy to use as Git for deployment. Actually it's even easier since you don't need to worry about all the Git stuff. rsync is simply a very efficient method to copy files (it only copies the segments that have actually changed). Nothing more.

[Lemon]

Daniel15, on 12 February 2012 - 09:22 PM, said:

rsync is just as easy to use as Git for deployment. Actually it's even easier since you don't need to worry about all the Git stuff. rsync is simply a very efficient method to copy files (it only copies the segments that have actually changed). Nothing more.

Last time I tried Rsync for deployment to an EC2 instance it kept giving an error (to do with connection I think. Ports were open on security group), which is a shame because I have it working perfectly for linked hourly local backups. I'll give it a another go sometime soon anyway, perhaps I'll have more luck with something non-AWS.

[Daniel15]

Hmm... rsync just uses SSH so it should work fine on AWS.

[Ruku]

Lemon, on 12 February 2012 - 09:46 PM, said:

Last time I tried Rsync for deployment to an EC2 instance it kept giving an error (to do with connection I think. Ports were open on security group), which is a shame because I have it working perfectly for linked hourly local backups. I'll give it a another go sometime soon anyway, perhaps I'll have more luck with something non-AWS.

You need to install rsync on the machine you're SSHing into, as well as the one you're running the tool from. The documentation is useless at clarifying that, but you'll get I/O errors if it's not installed on both client and server.

As for scalability, I don't think that even comes into it; it's just good practice and ease of administration and upkeep. Git has its place within any iterative development -> testing -> deployment cycle, but it's essentially a versioning tool. It's impossible to know whether your apps will ever make it big, so you might as well be prepared for whatever comes. I've been caught out in the past...

[gibbonweb]

Ruku, on 13 February 2012 - 03:51 PM, said:

You need to install rsync on the machine you're SSHing into, as well as the one you're running the tool from. The documentation is useless at clarifying that, but you'll get I/O errors if it's not installed on both client and server.

*cough*

man rsync
[... bunch of lines ...]
SETUP
       [...]

       Note  that  rsync  must be installed on both the source and destination
       machines.

wha?