: Can you recommend ways to manage code deployment to a Linux based web server? I've always used a very simple bash script to deploy code. I'm moving away from using subversion to Mercurial but

@Welton855

In addition to the excellent suggestions in the other answers, you may want to consider whether it is important to you to do an atomic update.

On my FreeBSD server, I accomplish this through two mechanisms:


Versioning all of my static resources. (E.g. static.example.com/images/logo.1.png or static.example.com/style/main.3.css ). This allows me to svn update the static site directly prior to updating the dynamic site, without worrying about users seeing new files in old pages.
Versioning the entire dynamic website. In my case, I have my document root pointing to a symbolic link. My strategy is to get the new version of production in place and then with a single command push it live. .g. something like this:

cp -Rp site1.com.1 site1.com.2 (or svn checkout)

svn update site1.com.2 (may need an svn switch first)

ln -sf site1.com.2 site1.com (atomically move changes to production)


This ensures that none of my users end up seeing a half-baked page. They'll either see the old version if it's still in their cache, or the new one.

This strategy only works well if you aren't mixing user-uploaded content with your dynamic site.

Vote Up Vote Down

@Rivera981

I use Mercurial to manage everything, including my static HTML pages. It makes life really, really easy for me.

Benefits include


All the perks version control offers (rollbacks, milestone tags, etc)
Being able to clone your site in a hurry
You always have a working local backup / copy
Easy to keep in sync if you tend to make changes en situ (in place, on the server)
Most shared hosts (if your dealing with one) don't mind installing it


Disclaimer, I wrote the tutorial. Yes, the kind of VCS you use does matter, to a degree. For instance, I would not use something in this scenario where I could not commit locally and make one big push / update. That just forces me to lump too many potentially problematic changes into one commitment.

I could do it with Subversion, and I'm not knocking SVN at all. I just think Mercurial is a far better tool for the problem you are trying to solve.

Its my opinion that you should not have to 'work around' your tools unless you have no other choice. Doing so sort of defeats the purpose of having them, and you do have a choice :)

Vote Up Vote Down

@Murphy175

Isn't the whole point of using version control that you don't need to concern yourself with backing up the site before pushing out an update?

If it's done correctly, an svn update (or equivalent) should be enough, and if it's a mistake then roll it back to a previous commit? That's what we do anyhow. Commit all the changes, svn update the staging server, if it's all OK then svn update the live server.

Vote Up Vote Down

@Jessie594

We use ant's scp task, with the modified selector. That means you just update the files that have changed since the previous upload. Unfortunately, the modified selector seems to be designed only for personal use, not sharing with team members. The cache.properties file has path names to the user's working directory in it. We wrote a bunch of ant targets to massage the cache.properties file into a format that can be shared between developers and then massaged back into the format that ant needs. The format also varies between a Windows environment and a GNU/Linux environment.

Vote Up Vote Down