Whats the best way to securely publish a site post

问题:

So, in your experience, whats the best way? Is there a secure way that's also scriptable/triggerable in a build automation tool?

Edit: I should mention this is windows/.net and I'll be deploying to iis6

回答1:

For some projects I use Capistrano to push out to live. It is built on top of ruby and makes deploy script writing super easy and uses ssh.

On other projects I have a tiny deploy app that uses bash to do an svn export to a temporary directory and then rsync it over to the live server. You can make rsync use ssh.

I greatly prefer the Capistrano method, even if your project isn't in ruby/rails.

回答2:

This seems like the sort of thing that could be done easily with SFTP. Take a look at PuTTY (psftp and pscp) or WinSCP for Windows, or rsync and OpenSSH for Unixes.

回答3:

@Neall, I'd add a set -e on the second line, because you don't want the live site being replaced if the rsync fails for any reason. set -e causes the script to exit if any of its commands fail.

Edit: The set -e should be the first thing in the script, right after #!/bin/bash.

回答4:

Make a copy of your live site directory, use rsync to update that copy with your latest version, then rename the live and updated directories so that the updated version is now live.

In bash:

#!/bin/bash

set -e
cp -R /var/livesite /var/newversion
rsync user@devserver:/var/readytogolive /var/newversion
mv /var/livesite /var/oldlivesite
mv /var/newversion /var/livesite

Viola!

Edit: @Ted Percival - That's a good idea. I didn't even know about "set -e". Updated script. Edit: updated again at Ted's suggestion (although I think it would still work if somehow the cp command failed, and if cp fails you probably have more serious problems.)

回答5:

I'll second the recommendation for Capistrano, though if you're looking for a GUI-based solution you could try the Webistrano front end. Clean, ssh-based, sane deployment and rollback semantics and easy scripting and extensibility via ruby.

回答6:

You could always write a small client/server app that encrypts at the source, pushes the files, and then decrypts at the destination. That's a little bit of work, but probably a trivial amount. And it's scriptable as long as your automation tool supports executing something in the file system (which I think all do).

The only downside is that you may not be able to get meaningful error messages on failure in your integration environment without a bit more work on your part (though depending on your setup, this could be as simple as sending error messages to stdout).

回答7:

hm, around here we use a staging "server" for testing purposes on the live environment (actually, its an apache virtual host on the production server) and araxis merge (a really smart line-by-line file comparison tool) to sync development and staging.

once its tested, just; replace the files on the production webroot :)

/mp

回答8:

On a freelance job I did, we set up three seperate enviroments.

• A Dev server, that ran continues builds using CruiseControl. Any check-in would trigger a build. QA Testing was done here.
• A Test Server, that user acceptance testing was done on.
• Production.

The workflow was as followed:

1. Developer checks in changes to SourceControl.
2. CruiseControl builds and deploys the build to Dev.
3. Dev is QA'ed
4. After passing QA, a robocopy script is ran that deploys the Dev build to Test.
5. Test is UAT'ed
6. After Test passes, a robocopy script is ran that deploys Test to PRD.