2

First, my (simplified) problem in a nutshell:

My release cycle at work is, each release we currently perform a full copy/deploy of the web application. Simply put, we generate a tarball, SCP it to the production server, and install it. Simple as that. The technology stack is LAMP, so there is no code compilation steps at this time.

The problem is, this tarball is getting large, and we need to deploy this tarball to many servers. While, this is a very reliable process, the overhead and time to perform this deploy adds up.

What I want to do is perform delta/patch releases for this LAMP web application that does not require the full tarball deploy.

I am using SVN for my VCS, and I do not want my deployed applications to be SVN working copies. I have experimented with using patch (linux CLI tool) and patch files, but this has holes in the process. For instance, patching the same file more than once, there is dev/ops overhead to track which file(s) were patched, from what versions to what versions, on the production site (which quickly gets complicated when multiple sequential patches are performed).

Ultimately, I need a reliable method to do a delta/patch release for a LAMP web application, that does not require a SVN working copy on the production webserver.

How do others solve this problem? Do you simply use rsync with a delete option, and avoid patch files?

HopelessN00b
  • 53,795
  • 33
  • 135
  • 209
chadl
  • 95
  • 1
  • 1
  • 6

2 Answers2

1

I'd use rsync to deploy from an svn export of the HEAD of the repository to update your application servers. Rsync is battle-tested, proven, and ready to go w/o any work on your part. Depending on how many servers you need to deploy to you could look at mrsync if the file sizes started getting really large and you wanted to quickly deploy to a large number of machines via multicast (probably overkill for your needs unless you have a lot of servers or a lot of data in a given delta, but certainly an option).

Evan Anderson
  • 141,881
  • 20
  • 196
  • 331
  • Thanks Evan. And thanks for editing my question with a more appropriate link to StackOverflow. I appreciate it. And of course, thanks for your suggestion to use rsync. I have been debating back and forth just which methods and tools are most appropriate and how to architect the deploy. I think rsync will definitely be a part of my solution. I presume you would not perform an rsync on a live vhost, but you would take it offline while performing the rsync update? – chadl Mar 15 '12 at 08:03
  • @chadl: If I were looking for atomic updates to the application servers while they're "live" I'd rsync an export of the HEAD revision of my repository over a copy of the running production code and, once the rsync was complete, unlink the production directory, rename the newly-rsync'd directory, and bounce the application server process(es). There would be a very small window of downtime while the application server recycled. Ideally you wouldn't even need to recycle the application server, but that would depend on how it would handle having files unlinked out from under it. – Evan Anderson Mar 15 '12 at 08:36
1

I do not want my deployed applications to be SVN working copies

But can you agree just use SVN on production and have WC outside webroot? In this case you can update WC on demand (less traffic) and export WC to web-space

Lazy Badger
  • 3,137
  • 15
  • 13
  • this is a good suggestion. I suppose the next problem with that would be: 1) what codeline would this working copy be using? .../tags/current_release ??? 2) if not a fixed working copy, then what is a 'good' strategy for managing/switching the working copies in the release process? – chadl Mar 15 '12 at 07:52
  • oh, and thank you very much for your suggestion so far. I'm interested to hear what other thoughts are out there before I go close this off. – chadl Mar 15 '12 at 07:55
  • @chadl - **my mainline** is always trunk, thus - I have permanent relation for WC-Repo on "deploy server". If you want switchable WC, you can use, f.e. svn:someproperty of predefined object in order to extract it after svn up and svn switch+svn up again. Or write keywords for post-commit deploy-hook in commit message – Lazy Badger Mar 15 '12 at 08:08
  • thanks very much for your input on this. very helpful in triggering some brain storming. and it's always helpful to validate designs and ideas. :) – chadl Mar 15 '12 at 08:18
  • Thanks for your help Lazy Badger. I am awarding the answer to Evan as I felt both your answers were very good, but his was first and his offered more with the rsync suggestion. Thanks! – chadl Mar 15 '12 at 18:51