Page 1 of 2

Deploying web applications and making updates

Posted: Sat Oct 20, 2007 5:47 am
by Luke
The company I work for is a marketing / design company first and foremost. Up until recently, the web development department of the company was a much smaller department. Before I started, there weren't any web apps that the company wrote from scratch. There is no real deployment / update strategy in place, so each project we work on ends up deploying / updating in a different way. This system, obviously is not very efficient. I'm just wondering how those of you who deploy and update websites in a high-traffic environment efficiently. What tools do you use to release "versions" of your software? How do you keep everything organized?

Basically I'm just looking for any advice you guys can give me on optimizing our deployment and update process. Thanks! :D

Posted: Sat Oct 20, 2007 7:51 am
by neophyte
You'll want to set up a Subversion server. While subversion can be used any many different ways, there is a "typical" set up. There are lots of places on the web you can read about it. I'm accustom to the tags/trunk/branches set up. My personal projects on my lappy use a local subversion repository. Its very nice way to work once you get it started because you can always roll back to previously commited versions of files. You never lose code -- which never happens. :D

Deployment is easy. With you production files marked you can just "svn update" or "svn copy" to production.

Posted: Sat Oct 20, 2007 12:44 pm
by alex.barylski
Nopt sure what you mean by deploying, but upgrades (in most places I've worked) never changed the Interface just the implementation, so simply overwriting the existing codebase would do the trick.

If interface changed, then that would typically require purchasing a new version of the software and we would provide upgrade tools to transfer over the DB tables, etc...

We didn't use SVN for deployment, just development. Once the application reached a point of completion it went through a month or of QA and testing at which point it was packaged into Zip, etc and uploaded to web site for download.

Are you after a fully automated update system like Windows has? That's tricky with open source technologies like PHP because users can change the source on you which woulod potentially break the upgrade.

Posted: Sat Oct 20, 2007 2:36 pm
by Chris Corbyn
I've done it a handful of different ways with SVN alone. A simple 'svn up', or better 'svn export' does the trick, but if you need to run some post-deployment routines (restarting some services, clearing caches etc) then it's less helpful.

My new place does it heaps differently -- they build RPM packages.

Posted: Sat Oct 20, 2007 6:40 pm
by neophyte
RPM packages? That's wild. I suppose you can script you database changes, cache flushing file syncs and what not.

Posted: Mon Oct 22, 2007 4:40 am
by Maugrim_The_Reaper
Phing (PHP). Or Ant (Java) or Capistrano (Ruby).

I think it depends on how deployment should be organised. The more complex the set of deployment tasks, and the more time they take, the more likely you really need to use a good build tool. Phing (or one of the non-PHP others) is extremely easy to learn and use. I'm rolling it out to my new open source projects so I can generate tarballs and PEAR packages with a single Phing command. Something which isn't really complicated - it's just annoying to have to do it manually ;). You can see an example build file (more complex than usual since PEAR has special directory placement needs and package.xml generation) for PHPSpec over at:
http://phpspec.googlecode.com/svn/trunk/build/build.xml

For deployment, it's all about the automation. You can script a set of tasks to perform, test the Phing process as you need (since it's automated it always repeats the same steps without intervention), and then roll out the same process as needed. I think it's a lot cleaner than subversion export (or any manual tasking) - you can create backups, export from svn, copy/move/replace, execute post-install scripts, run any system command, etc.

As for deployment strategy, I like symlinks or text replacement. I prefer applications to only have a handful of actual files in the web root with everything else included from there. Deployment is just moving the new files to a new directory (not the same as the older version) and updating symlinks/include references as needed. I keep Phing on hand with a rollback task if needed to evade a complete meltdown in case something bad happens despite any testing. Phing scripts everything.

Posted: Mon Oct 22, 2007 9:04 am
by georgeoc
Hi all,

Sorry to butt in, but I'm trying to get my head around this too at the moment. I've been considering Phing, and would like to get it set up to make deployment easier.

At the moment I have a SVN repository set up for my application (m2f), which has a PEAR installation in the /includes directory. I would like to change this and remove PEAR from the SVN repository, as it adds so many complications and overheads for SVN operations.

I think the best way to go would be to have PEAR checked in in a different part of the repository, and for deployments to combine the two. So I'd keep the application at SVN path /m2f and the PEAR files at path /PEAR, and a deployment would do a m2f checkout and a PEAR checkout, and copy the PEAR files to m2f/includes/PEAR.

The reason for checking in PEAR at all is so all the devs and beta testers can use the same PEAR installation, otherwise I would just add my local copy to a deployment. For my own development work, I would symlink m2f/includes/PEAR to my SVN working copy of the PEAR repository.

How does that sound? Is that recommended practice? Thanks for any comments, or links to guidance or tutorials on the subject.

Posted: Mon Oct 22, 2007 9:29 am
by Maugrim_The_Reaper
Sounds like a workable solution - I assume the PEAR deployment is to prevent any PEAR-specific errors in feedback? In general I'd prefer updating directly from PEAR, but hey - if it works and has a reason ;).

I keep a subversion repository primarily for non-versioned code, or specific un-tagged code I need to reference. I just have to keep it updated or it's too easy otherwise to fall out of date. A task like yours is why I suggested Phing - you can just write a build.xml file describing each step of packaging/deployment and get rid of any manual tasking that's sucking up your time. Phing integrates with VersionControl_SVN from PEAR to handle exporting code - from there it can copy and move files and do other preparatory tasks as needed.

Mainly I'd just be worried about updating PEAR regularly - ;).

Posted: Mon Oct 22, 2007 12:55 pm
by Luke
phing looks perfect. I actually have heard of it before, but have never used it. I just installed it. I will have to play around with it. Any good resources for learning it? (other than their docs ;) )

Posted: Mon Oct 22, 2007 2:52 pm
by georgeoc
I'm just discovering it myself. It's fantastically powerful, and I found that the manual is all I've needed for reference so far. Good luck!

Posted: Mon Oct 22, 2007 3:23 pm
by Maugrim_The_Reaper
The docs :). There's much else needed - just list the task to be performed and follow the tasks defined in the Docs. If you can't find a specific task you need, you can create a custom task in PHP which plugs in. Also Phing can run console commands as needed (and if PHP/Apache has access). For example, Travis Swicegood maintains some pretty useful PEAR related code at domain51.com and I use his d51PearPkg2Task in PHPSpec to generate a package.xml file before I exec the "pear package" command.

Code: Select all

<taskdef classname="phing.tasks.ext.d51PearPkg2Task" name="d51pearpkg2" />
Custom tasks are not all that difficult to write in PHP. You could use Travis' extension as a more complex example since it has quite a large API being implemented. Otherwise, it's a task tag and the params which are sent to a normal PHP object for processing.

Posted: Mon Oct 22, 2007 3:32 pm
by Luke
you guys are right. I was able to accomplish what I wanted (for a specific project) already. Phing rules! :-D

Posted: Mon Oct 22, 2007 4:02 pm
by Maugrim_The_Reaper
If only I got paid for referrals...;)

Posted: Mon Oct 22, 2007 4:14 pm
by Luke
Actually it works great in linux, but on Windows, the svn export craps out, unfortunately. I get no error. It says it worked fine, but then I look in the build folder and there is nothing in it. :(

Posted: Tue Oct 23, 2007 3:14 am
by Maugrim_The_Reaper
If I were to guess the error is being concealed - VersionControl_SVN was written a few years ago so it's probably using the legacy PEAR ErrorStack which is irritating.

What version of VersionControl_SVN is installed? The last update (few and far between) was 0.3.1alpha last September. The last was back in 2004. As a result it's QA is "dodgy" ;).

Notably, I don't use it on Windows - I'll try to however. If there's a problem I'll try to figure it out. Can you see if a checkout task rather than an export makes any difference?

Also are you using the latest Phing RC? I know some svn bug was fixed during 2.3.0.