I’ve been working on the open source web service that we make available to our clients, trying to get some caching into the application to improve performance. It got me to thinking: what would be the best way to get our clients to install this application.
By best way, I do not mean easiest way. The easiest way is to say “here’s the tarball, extract it and install it in place”. That’s currently the method we use for distribution. I must admit that I have been negligent in updating recent builds on the site. The real solution here is to create an automated build system that I can use to package up newer versions of the code and put them up on the web site.
Others have suggested that I should examine the use of Pear as a way to distribute this PHP application. That’s fine, but the next time they update it would overwrite any changes they made to things like display templates. So I guess the current method is the best…
Tags: blog experiment, Deployment, PHP
Another option is to use PEAR then use the include_path for files that need to be modified. You end up with base/ and custom/. Tell the client to copy anything out of base/ that they want to modify, then you’re set. Just make sure you never package anything in the custom/ directory.
With my clients I’ve started using ‘git push’ to deploy to the servers. On the server I have the working copy in a “production branch”. I ssh in and check for local modifications, and then do a ‘git merge master’ if there are none. If there is local modifications I check what’s going to be updated ‘git diff master’ and if nothing conflicts I can just merge. If they’ve edited some of the same files I have, I can usually just stash their changes and then pop the stash after a merge.
It doesn’t sound simple, but it keeps me on top of every change and lets me know if they’re editing something I should change in the source.
That and database migrations have made my job a *lot* easier.