Deployment with SVN slides – Dutch PHP Conference

The slides for my talk “PHP Deployment with Subversion” at the Dutch PHP Conference last weekend are now online, you can find them at http://www.slideshare.net/lornajane/php-deployment-with-svn/. If you have any questions or comments then either drop me a line or add a comment below.

Edit: I prepared a video of the nabaztag demo I did – you can find it over here on flickr – enjoy.

20 thoughts on “Deployment with SVN slides – Dutch PHP Conference”

Mike on June 18, 2008 at 13:07 said:

Hi Lorna,

Great slides. Wish I could have attended the talk. I’m working through a “safe” way to deploy production code using svn, so your slides are very timely for me :)

One issue I’m having a difficult time working through — and I’m hoping you can offer some feedback on — is the safest way to place the code on the production server that eliminates reads to half written files. I want to leverage svn here to handle updating the code (“svn up” is just so nice and easy). However, it’s not clear to me if “svn up” works in an atomic fashion as something like rsync would. To your best knowledge, does “svn up” work in an atomic fashion that would be amenable to pushing code the production server, or is this just a bad idea?

I suppose one also runs a risk of having an collision when running an “svn up” that would be detrimental to deployment.

in your slides you outline a few strategies here. I’m wondering what your recommended best practices are.

Thanks!

Mike
LornaJane on June 18, 2008 at 14:16 said:

Mike: I am not a fan of having subversion checkouts on live servers, for a couple of reasons. One is the risk that some of the .svn directory files get published and give more information out than intended. Another is the issue you mention, of the situation of having the files in an inconsistent state while the update is in progress.

My recommended practice is to deploy code by putting a complete new version of the code onto the web server, and then switching a symlink to point to it. This avoids both of the issues mentioned above and provides you with an easy rollback path because you can just point your symlink back at the old version if you need to.
Mike on June 18, 2008 at 14:50 said:

Thanks for the feedback Lorna. That sounds like a sound solution.

Do you have any experience with the svn switch method which you discussed here: http://lornajane.net/posts/2008/SVN-Deployment-and-a-New-Site ? Assuming that an SVN switch worked atomically on files (which I have no clue if at does), can you see any pitfalls with this approach?

Thanks again,

Mike
Christian roy on June 18, 2008 at 15:05 said:

Great slides LornaJane!

I could not attend your presentation/

In your slides you show two different ways of handling development. One where you propose that the trunk is what you use to push on production and one where you use a live branch and do development in the trunk (or feature branch that you then merge in the trunk). I am looking for opinions on advantages and disadvantages for both proposed solutions. Which one do you recommend and why?

Thank you very much.
LornaJane on June 18, 2008 at 15:10 said:

Mike: I don’t have any experience with Mark’s switch method – I am not comfortable with putting any meta data from the repository onto a live server so I haven’t done it this way myself. I think its a fairly good solution but it still won’t be atomic, so I’m not sure it will help in your situation.
LornaJane on June 18, 2008 at 15:19 said:

Christian: That is a good question and I think it mostly depends on the development process you are deploying from.

If your project is released in “versions” – where a single feature or a group of features are implemented in their entirety and the project is then released as a whole, then you would deploy from the trunk.

The live branch is useful where you would implement a single feature and then release only that one feature while other features are being developed, perhaps by other team members. In this scenario, each feature gets approved for release, and then merged to the live branch and deployed from there. This avoids the situation where developers can’t commit to the trunk until after a release has been made – my feeling is that developers should always be able to commit as often as they need to, without being influenced by external factors.
Rob... on June 19, 2008 at 11:32 said:

We work the other way and always deploy from the head of the trunk. All development work is done on branches that are merged to the trunk for deployment.

Regards,

Rob…
LornaJane on June 19, 2008 at 19:23 said:

Rob: That sounds like a good system, it only really breaks down if you have lots of branches all being merged into trunk at the one time. Personally I haven’t worked in a team big enough to reach that limitation so I normally deploy from trunk also.
- Rob... on June 19, 2008 at 21:05 said:
  
  In my experience the average client can’t cope with too many branches (i.e separate jobs) going live too close together!
  
  Rob…
LornaJane on June 19, 2008 at 21:15 said:

Rob: How true! The comment I usually make is that the live branch model works for if you are the development team behind a large site which has lots of changes needed all the time, like one of the big news or portal sites.
Geoff on June 22, 2008 at 14:10 said:

Releasing from the trunk seems appropriate only if you are supporting a single “live” version. Our situation is somewhat different since we are subcontracted by another company. In addition to supporting (making bug fixes) for the real “live” system, we also support the next phase of development to go live (which is evaluated by the contractor). In addition to this, we are doing development for the next phase after that. On this basis we do all new development in the trunk, and fork off a separate branch for each of the release versions that we support.
LornaJane on June 29, 2008 at 17:12 said:

Geoff: I imagine that in a lot of situations, all the main branches and trunk will be deployed from in one way or another, whether the destination of the code is a staging platform, a development platform, or a live server.
Menno on July 17, 2008 at 09:54 said:

It seems the slideshare presentation is offline?
- Andreas on July 17, 2008 at 13:20 said:
  
  Also missing the slides. :-(
LornaJane on July 17, 2008 at 22:33 said:

Menno, Andreas: Slideshare are working on the problem – it should be fixed tomorrow but if you are desperate for the presentation then let me know and I’ll email it over
LornaJane on July 18, 2008 at 08:23 said:

OK those slideshare links should work now, thanks to everyone who let me know they couldn’t access the content, you can now.
Steve on May 15, 2009 at 21:51 said:

Hi Lorna,

I’m setting up a fresh svn repository for a new project and I’m trying to determine the best way to handle user-uploaded files. So far your slide have proved excellent guidance – this is all brand new to me.

My question is what is the best way to manage those files?

My idea was to run an svn export to a new release directory each time we update and re-point the symlink.. but since the export will not contain upload directory (excluding it from repository), have a script do an rsync from the current live directory to the new release directory just for the user upload directory (and any other non-svn directories for that matter).

Is there a better way you could recommend to manage this?

One concern is that the dev team will need local copies of this folder for at least some content.. if someone accidentally does not svn:ignore the directory and it gets committed .. throwing the rsync out of whack or some type of undesired results.

Since this is so new to me I’m afraid some pitfalls won’t be apparent to me… or that I’ll be over-paranoid!

Many thanks,
Steve
LornaJane on May 16, 2009 at 11:05 said:

Steve: I think you’ve identified a potential pitfall here, and you have a couple of options. When you set svn:ignore on the directory, that setting holds for everyone so nobody should be *able* to commit to that dir. Alternatively you could use a config setting to set the upload path and have these files stored outside of the checkout root – making it much harder for developers to commit these files accidentally. Either solution works, you are right to see this as a potential problem but I don’t think its a crisis. Let me know which one you choose and how it works out.
- Steve on May 27, 2009 at 16:14 said:
  
  Hi Lorna,
  
  Rather than playing the properties juggling game (svn:ignore), I restructured the site – here’s a basic diagram:
  …
  project
  > staging
  >> core (in version control)
  >>> library (php)
  >>> webroot
  >>>> private (app)
  >>>> public (images css js)
  >>>> index.php
  >> supplemental (not in version control)
  >>> logs
  >>> temp
  >>> uploads
  > production
  >> core (symlink points to release directory)
  >> core.release.1.0 (exported tag)
  >> core.release.2.0 (exported tag)
  >> supplemental (not in version control)
  >>> logs
  >>> temp
  >>> uploads
  …
  
  I have a postcommit hook updating a working copy in the staging core and for production, we create a tag and a script handles an export and symlink redirection.
  
  Each environment (prod, staging, devs) manages it’s own supplemental directory which as you can see contains user uploaded files. This upload directory is directly tied to the database so it makes sense for each environment to have both independent from each other.
  
  I will periodically do a db/upload sync from prod to staging to keep things looking almost the same but this directory structure is proving to be optimal for version control.
  
  Thanks again for steering me in the right direction :)
  
  – Steve
LornaJane on June 2, 2009 at 11:50 said:

Steve: Great solution, thanks so much for sharing!