A New PHP Development Environment
We’ve been threatening to overhaul our entire PHP development environment for some time, but it has always been something we have managed to put off for as long as possible. With Dreamweaver lagging further and further behind our requirements and the projects that we are dealing with at work getting more complex we have finally managed to take the plunge and get started on this.
I’ve found that locating really basic information on this has been surprisingly difficult, so have decided to blow the dust off my old blog and put down some notes on what we’re up to. Hopeful someone else out there might find it useful, or better still offer some tips on how we can improve it further. Read on for more details.
Current Set-up
We currently have 5 developers working in one building and occasional bits of work being done elsewhere (usually on my laptop). We have historically used Dreamweaver with various extensions (most notably Interakt products). Files have been stored on central NAS drives, which we’ve worked on across the LAN and uploaded to either a staging location online or the live location as required.
Issues
The above sort of works, but it is not ideal. With us all working in an open plan space it is not too difficult to ask whether someone else is working on a file before editing it, but that can get annoying. More importantly though the projects we deal with are getting larger and more complex and it was becoming apparent that some form of version control was going to be required.
More pressing though has been a growing disappointment with the once great Dreamweaver. With the extensions that were previously available via Interakt (now also bought by Adobe) it was possible to do some quite useful dynamic site creation with it, but the shortfalls in it’s capabilities have been becoming more apparent for a while. Most annoyingly though is that the upgrade path on the dynamic extensions is appalling for those working on multiple sites. Upgrading to later versions of the software would literally make us unable to use any of the work-flow improvements on projects that were developed under older versions. So, we added a new IDE to the list of requirements.
The final issue that we really wanted to address was speed of development. Dreamweaver in particular is a bit of a dog when it comes to uploads which can really slow down work on a project. More importantly though, the process of developing on a remotely hosted webserver is inherently inefficient. Because of this, we added local server development to our list of requirements.
The choices that we have made
It has taken a surprisingly long time to decide on the combination of tools that we are going to be using. Every choice that we wanted to make seemed to lead us around in circles looking at options for other tools. In the end though, we decided on the following:
- Zend Framework
We chose Zend for our framework. We’re not doing much with it at the moment, but we liked the approach taken and the stability and longevity it seemed to offer. Importantly it seemed a lot more flexible and forgiving than other frameworks that we looked at which is going to be important during the learning process. We’re a busy organisation and simply don’t have the time to stop work and learn so will be bringing things in slowly, which Zend seems to be well set up for as it doesn’t appear to force much on you. - Zend Studio for Eclipse
Once we decided on Zend Framework this choice was fairly simple, although in truth each influenced the other. Zend Studio for Eclipse is very different to what we are used to working with, but seems to be starting to make some sense. - Subversion
Reading around it seemed to be an obvious choice for version control. As a bonus Zend Studio for Eclipse integrates well with it. - Xampp Lite
For the local server aspect. Quick, easy, painless, stable.
Our Set-up
Each developer’s system will now be running Zend Studio for Eclipse and have a local server run via Xampp. All these systems run Windows. We additionally have set up an old Ubuntu box to operate both as a Subversion server and local testing server. Our NAS drives will eventually be used for backup and storage of miscellaneous (non project) files.
How it is meant to work
This is the bit that I struggled to find much information on, so no doubt it could be improved. I am hoping that, over time, it will be:
- Each website project will be store in it’s own subversion repository on the Ubuntu box. The repository will store not only the web files, but all files relating to that project.
- When one of us works on a project we will check it out of the repository and develop and test locally. Once changes are stable we will check it back in to subversion.
- At key points we will export the subversion version of the project to the Ubuntu webserver for pre-live testing
- If OK this will be uploaded to either the live or a staging server online for the client to view as appropriate to the project
Outstanding issues
At the moment setting up a new project is looking fairly slow. We are considering creating some batch scripts to do much of the work (adding host file entries, adding virtualhosts to the various apache set-ups etc) in order to speed this up.
Databases are not really being looked after too well at the moment. The likely solution is that, when developing locally, we will use a shared development database on the Ubuntu system to minimise issues that this could create. We’re looking for a way to possibly automatically export change logs from this to the subversion repository, but have not come across anything yet.
Because we have been looking at this environment change in small bursts between projects, we have not even started to look at Zend Framework yet, which is going to be the largest part of this whole project. The plan is to have shared ZF libraries on each of our live servers and either a shared local library for it or separate libraries on each development system (most likely due to this being faster).
Hi Mat,
A couple of tips which might save you some pain:
* Make sure your ZF code any additional code (e.g. PEAR libraries) lives in subversion too, and is checked out when you check out the client’s website. There’s nothing worse than code working in dev but not on live because of a shared piece of code that wasn’t upgraded in both environments at the same time!
* Tag your releases (svn copy trunk tags/) for future reference. Handy for looking at bugs, and for rebuilding live servers when hard drives fail.
All the best,
Stu
Interesting tip regarding shared libraries.
We had planned (not necessarily decided) to take a different approach. Because most of the projects that we work on are also hosted with us, we have shared the libraries at server level. The idea was that everyone would then be using the same version - meaning that we just have to ensure our dev versions match that.
You have me thinking now whether that it a good approach or not.
Planning on tagging as suggested. Still getting used to subversion at the moment though.
Thanks for the pointers.