Hi, On Wed, Mar 2, 2011 at 5:49 PM, Tomas Doran <[email protected]> wrote: > On 2 Mar 2011, at 17:27, Pedro Melo wrote: >> On Wed, Mar 2, 2011 at 5:24 PM, Tomas Doran <[email protected]> wrote: >>> Installing to production servers via rsync / unison is insane, as there >>> is >>> exactly no way of knowing what version the production server is on, with >>> what bugs... >> >> Of course you can. You can include a file .version at the root created >> with 'git describe --always' > .version before you rsync, and then >> include it on your test reports. >> >> Rsync is a valid deployment method, specially if you use a stage >> server where you make install you app. > > Ah, but then you're deploying a specific sha1 from git, rather than just > rsyncing a directory! > > And as you'll have a script to ensure that you have reset --hard MYSHA1 > (otherwise you are perfectly screwed just as I described), then you can put > the build parts in there...
Actually the complete workflow is to push to our production repo, and then run a script to publish a particular SHA1 to production. That will git pull in the stage server, create a release branch, and then run all the deploy scripts (minification of JS, CSS, and whatever is needed.). Everything is committed to the release branch and the new sha1 from that is the one actually used on production servers. Right now, thats a git reset to the release-sha1, and then a rsync to production servers. I'm actually considering git pull's directly from the production servers. Git is actually more effective than rsync, given that it can calculate pretty easily which files changed between versions. Having git workdirs in the production servers has the extra advantage of a easy way to revert bad releases, at least from the code perspective. Reverting DB schemas is much more interesting. Bye, -- Pedro Melo http://www.simplicidade.org/ xmpp:[email protected] mailto:[email protected] _______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
