Getting from point A to B (the right way)

October 11, 2007 12:59 PM

I've got the skills and knowledge, mostly, but I'd like to get a better workflow with PHP/MySQL development.

Right now, this is my process:

- Design DB schemas in phpMyAdmin
- Code PHP using jEdit, using the FTP plugin to directly open and save files to a Dreamhost server.
- Use CodeIgniter as a general framework.
- Occasionally do manual backups of all my sites.

This is the workflow I use for moderate web app development as well as client sites. Now, this works, actually quite well right now. But I'm thinking that directly editing files using a FTP client, on live sites, isn't as robust as I'd like. I get server timeouts every once in a while, and there's no versioning set up for my development projects.

I'm interested in how a one-man-shop like myself would use SVN, or perhaps another web host (I'm on the queue for SliceHost, and Pair Light sort of caught my eye... if anyone has suggestions in that area, they are certainly welcome) to improve his/her workflow. I especially don't understand svn at this scale. The SVN copy is inactive on the web... I checkout and checkin files? Also, would most people like me have a development atmosphere on their main desktop (LAMP, etc), or a separate development server, or a shared development server?

Essentially, I'd like to put in a little time and effort to optimize the work that I'm doing right now. Thanks for any help on any of these points.

posted by tmcw to computers & internet (15 answers total)

Where right now do you do your development when a site is active? On a subdomain or on your desktop? Or another server? How do you then integrate your changes? What if you mess up and overwrite or delete a file?

Basically, subversion makes it easy to have your development work done in another location, and it keeps a log of all of your changes so that you never lose a bit of source code or a binary file because they're all logged on your subversion server and you can just step back. Also, if you're working on your desktop, you can make seriously large changes like removing whole subdirectories without fear that you're going to mess up a live site user's experience.

Using something like Trac will allow your customers to submit bug reports, and then you can fix the bug and denote when it was fixed and what revision so that if a revision breaks a site, you can just roll it back.
posted by SpecialK at 1:11 PM on October 11, 2007

what operating system do you use?
posted by phil at 1:11 PM on October 11, 2007

sorry missed LAMP
posted by phil at 1:12 PM on October 11, 2007

First of all, Thou Shalt Not edit live code. The fact that I'm doing that one terminal over is irrelevant. Definitely host a basic development server locally, it speeds the development process enormously.

As for version control, it may or may not be overkill, but getting into the habit of commiting changes and keeping production in a known state will make transitioning to bigger sites vastly easier. SVN is popular, but it has its own set of issues, and might certainly be too big/too complicated to be worth it to you. I've used darcs which is entirely distributed, but I don't know if it's well supported outside Linux. I've heard good things about Mercurial but never used it.

One thing that is difficult to arrange if you're not running your own server is to maintain a development environment that's as close to your production one as is feasible, especially if you have multiple clients in their own environments. It's very easy to forget that this host is running an ancient version of mysql, that one has a low memory_limit, etc.
posted by Skorgu at 1:16 PM on October 11, 2007

Take a look at this:

http://www.eclipse.org/pdt/

You should be able to do all development right in the IDE instead of having it on the server. I use this with the Subclipse plugin to check code into subversion (note I'm using RadRails for RoR development but kind of the same thing)

This way I do all my development in the IDE on my laptop, and only update the site to deploy updates.
posted by bitdamaged at 1:17 PM on October 11, 2007 [2 favorites]

I should note the IDE will usually be running a server for you for local testing.

There's no reason to be using a production server instead of your own locally hosted LAMP instance. I also use the MySQL GUI tools these days instead of PHPMyAdmin
posted by bitdamaged at 1:19 PM on October 11, 2007

re: phil, I use XP currently on my laptop, mostly because Linux still sucks on this particular laptop.
posted by tmcw at 1:21 PM on October 11, 2007

There's no reason to be using a production server instead of your own locally hosted LAMP instance.

Well, sort of. I need a really good way to sync changes between my copy and the live copy, production-specific files (config, etc) and mine. If there's a good way to do that, I haven't found it yet.
posted by tmcw at 1:28 PM on October 11, 2007

I need a really good way to sync changes between my copy and the live copy, production-specific files (config, etc) and mine.

I'm not sure I understand what this means.

But I just check everything into subversion and run an update on my live site when I need to roll out new features or bugfixes.

I can then just have subversion ignore local config files so they don't get copied over. Also generally I use a known file structure where usually relative paths in my config do the trick.
posted by bitdamaged at 2:02 PM on October 11, 2007

If you haven't yet, check out the Zend Studio IDE. It works with cvs quite nicely; I don't know if svn works as well, but I suspect it might. If you really want to edit live code, just mount the live servers such that your machine can access the live machine directly via the filesystem. I do this by mounting over sshfs on my Ubuntu boxes, and using SFTP drive when I'm on my Windows box.
posted by cgg at 2:10 PM on October 11, 2007

I think you're asking more a process question more than a 'tools' question, so here's my process.

You need to use LAMP or XAMPP, or install your own, and have your a local development server. I'm a one-man shop as well, and have my 2 XP boxes - my laptop which is where I do coding, and a PC server in the closet which has the SVN server running on it. I check out files from SVN to my local apache instance, and do my work there. When I get it to where I like things, I check them in to SVN.

To get the files to the live host, I do a SVN export of the branch to a temp directory, then just use Filezilla to ftp the whole complete directory structure to my hosted server. Note that it's important to do the export, not the checkout, so that way the .svn files don't go up to the server.

As far as development process with PHP config files, I'm guessing you mean such as db.inc or similar files which manage configuration options which will be vary from a local host or remote. My solution for that is to include both configurations in the .inc file, and then conditionally use one or the other based on some semaphore such as the server IP or a file that you put only on the development server, not the production server. Those config files are then checked in, and then the application can determine the configuration. This sure beats manually cracking open a file and changing the DB server name or pwd each time you make a change.

That being said, once you implement a process like this, be ready for "regression" errors, where you fix something tiny in the live code, and forget to put it back into SVN, then with the next code drop, that fix is lost. Be disciplined in reflecting every change back to the repository.
posted by TuffAustin at 2:28 PM on October 11, 2007 [1 favorite]

If your laptop is relatively recent it might have hardware support for virtualization (Intel Core Duo chips do, for example). If so, it's worth looking in to using VMWare or Parallels to run a virtual linux server locally on your machine. You'll need a fair amount of RAM for this as well - 2 GB minimum probably.

I do this and it's fantastic as a development tool. I've got an Ubuntu virtual server which means I can install pretty much anything I want to with an apt-get - then I mount it to my "real" laptop over Samba so I can edit files with a local text editor. Best of both worlds.

I can't recommend using source control enough - it's not that tricky to get started with and it means you'll never be afraid of changing code again (since you can always roll back). I'd go for Subversion - newer systems are more trendy, but for a single person getting started with version control subversion will probably be easiest to pick up. This book should help: http://www.pragprog.com/titles/svn2
posted by simonw at 2:30 PM on October 11, 2007

The way I've been working recently is somewhat quick-and-dirty, but it works for me and I'm the only person coding the site so there are no issues with other developers.

I have dev.sitename.com and www.sitename.com, which are different directories on a remote web server.

I edit live code, but only ever on dev, unless something's gone terribly wrong.

When everything on dev is running fine and/or the client has signed off on it, I use rsync to sychronise the two directories. After I back up www.

In order to make this easier, I have all these rsync commands saved as shortcuts:

• wwwtodev -- so I can be sure the dev server matches the live one before I start changing stuff (because the client uploads their own graphics)
• wwwbackup -- copy it all to a backup folder, just in case
• devbackup -- ditto, no pun intended

And all of those commands have a "dry run" version, with the -n flag, to see what's going to happen, which can alert you to problems.

I also have dual databases, on the dev and live site, and an if clause at the top of all the code which says "if we're running on the dev server, $database = 'dev_database', if not, $database = 'database'".

Works, as they say, for me.

Having said all that, if someone can see a fatal flaw in my procedures, let me know.
posted by AmbroseChapel at 6:29 PM on October 11, 2007

Seconding setting up a local dev server. You will be able to make 3 changes and refresh in the time it currently takes you to try out 1 idea and FTP the changes over.

A version control system is also one of those things that once you adopt into your workflow, you'll wonder how you lived without it. You wonder what you've done all day? Just do a 'diff' and see the day's changes. Want to completely remove that new feature that turned out to not be so cool after all? Just pull out the old version. That said, you're project has to be complicated for revision control. Otherwise there is some overhead.

I push content to staging and production servers with rsync over ssh. it's awesome. the command line is a bit of a beast, so i usually have a one-line shell script in my project like:


#!/bin/sh
# -n = test
rsync -avz \
--exclude "SiteConfig.php" \
--exclude ".DS_Store" \
-e ssh ./ [e-mail]:public_html/


As for the different configurations - you basically need to have a different config file for dev, staging and production. Then you copy the appropriate file to be your config file. (And you never transfer that config file, so you don't overwrite the local config.) So as you can see in the above shell script, the config file is "SiteConfig.php". My production config would be something like "SiteConfig.php.production", which would just be copied to "SiteConfig.php" during install. Also, writing a little install script is also a good idea. (e.g. to create a temp directory, change permissions, copy the correct config script, etc.)
posted by kamelhoecker at 8:57 PM on October 11, 2007 [1 favorite]

Re: everyone. I'm not using WAMP, Eclipse PDT, Subclipse, and SVN on my Dreamhost account to develop my application. No deployment strategy yet, because I haven't done it yet, but everything is great right now on the development side. Thanks for all the help.
posted by tmcw at 11:46 AM on October 15, 2007