[hedora]

Oh, but scp won’t update it atomically, so you should switch to a scheme that will. Then all you need to do is set cache policies correctly, coordinate with your CDN, and maybe do a staged rollout, just in case.

/s

Seriously though, rsync is your friend. :-)

[zimpenfish]

> Seriously though, rsync is your friend. :-)

Even rsync might not be atomic enough for some situations[1] since it'll update files as it goes rather than in one huge transaction at the end.

[1] I worked on the World Cup 2006 site for Yahoo! and we had this issue - solved with 'rsync --link-dest' and swapping symlinks.

[fctorial]

Write a script.

1. stop service 2. copy files 3. start service

[AstralStorm]

Now you have two problems, because for high availability you need a failover or better yet, shadow secondary service.

Hot patching wins, but needs good design to work in the first place.

[tonyedgecombe]

You just need to decide how appropriate that is for your situation.

As an industry I suspect we tend to over-engineer rather than under. There is a huge spectrum between my single person business with a brochure site and what Google or Apple needs. I'm willing to bet most programmers are working closer to the first than the second.

[zimpenfish]

> 1. stop service 2. copy files 3. start service

That assumes you can stop the service which, for many things (like the World Cup website), isn't really possible.

[zdragnar]

You know, I think I might have switched to rsync at one point- I haven't had the site in a few years now, so my memory is a bit hazy.

It was sufficiently small enough (no heavy media files) that I didn't mind if I left some unused files up there. Pretty much the only thing that I had to do was make a copy of the sqlite database each time just in case.

[tonyedgecombe]

--delete-after will delete files on the destination after everything else has synced so you can be sure you aren't linking to a non-existent asset.