Deployment with SVN slides - Dutch PHP Conference
Wednesday, June 18. 2008
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
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.
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://www.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
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.
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.
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.
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…
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.
In my experience the average client can’t cope with too many branches (i.e separate jobs) going live too close together!
Rob…
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.
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.
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, 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
OK those slideshare links should work now, thanks to everyone who let me know they couldn’t access the content, you can now.
