Whats the best way to securely publish a site post build?

Question

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

Answer 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.

Answer 2

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).

Answer 3

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

Answer 4

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.

Answer 5

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.)

Answer 6

@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.

Answer 7

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.

Answer 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.

Answer 9

The workflow from FlySwat sounds a nice way of doing things - but I don't see exactly how it would work. If you just do an exact copy, then surely you will have undesired configurations, such as incorrect ip/names for databases. Or do you have all names etc the same, spread across 3 different servers, all referencing 'localhost'?

Either way - I am working from one server, and it would be nice if there was a clean way to promote from a test version to production, and have the config taken care of e.g. the db configs for the test environment don't get carried over to production. Any suggestions?

PS. I see this post is rather old - is it okay to resurrect this? It's very relevant to the question I'm asking.