Posted 12 February 2012 - 02:54 PM (#1)
Posted 12 February 2012 - 03:12 PM (#3)
- 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
- 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 liveon your local machine. Edit: Here's a tutorial for this method
Posted 12 February 2012 - 04:09 PM (#5)
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
Posted 12 February 2012 - 06:15 PM (#7)
Posted 12 February 2012 - 07:14 PM (#8)
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.
Posted 12 February 2012 - 09:22 PM (#9)
Posted 12 February 2012 - 09:46 PM (#10)
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.
Posted 12 February 2012 - 10:20 PM (#11)
Posted 13 February 2012 - 03:51 PM (#12)
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...
Posted 13 February 2012 - 05:29 PM (#13)
man rsync [... bunch of lines ...] SETUP [...] Note that rsync must be installed on both the source and destination machines.
my wife has a new DIY/decorations/floristry blog, wanna take a look? (stay tuned for English translations...)