newbie to 'proper' php project management

Question

I've created a lot of PHP projects in the past based on quick 'make a change, upload it' development methodology.

I'm beginning a long (6-8 months estimate) project to provide a fairly full featured hosted web application. Over the last few weeks I've been looking into the best way to 'project manage' this (my actual code is fine). The application will have an initial release, providing basic functionality and a further release providing advanced functionality. I've never used SVN, Trac, Bug Tracking, Staging Servers or Deployment Tools so this is all pretty new to me.

Based on what I've learnt over the past week, here is what I'm looking at having.

4 x VPS with 128mb RAM (256 burstable) and 10gb HDD space.

Configured in the following configuration

1. tools.ops.ourdomain.co.uk - server hosting SVN, Trac, and secure file storage for uploads and DNS (where the nameservers for point)
2. development.ops.ourdomain.co.uk - development environment to work on trunk version of software. Automatically updated htdocs folder on SVN commit
3. staging.ops.ourdomain.co.uk - where 'potential releases' are deployed for testing.
4. production.ops.ourdomain.co.uk - production server where 'final releases' are deployed.

Does this make sense? Should I drop my development server down to my local machine? Does it make sense to put the DNS on the tools server or not?

Secondly, what's the best development methodology for a single developer? I was going to plan out all the features first of all eg "Authenticate a user", "Logout a user" and then create them as trac tickets. The actual 'how' and 'where' could then be worked out when I come to the task in question. Would it make more sense to plan out all the class methods (and general files) and then create tickets for these?

Thanks in advance.

Answer 1

If you can change it without too much cost, double or quadruple the RAM. I have a 256 MB (fixed) "workbench" VPS and have had trouble running Trac/Python, Apache2, one or two PHP applications, and a remote desktop connection at the same time (the box would just refuse to do anything and claim "out of memory"). This was a Windows Server 2003 VPS, Linux is probably a little more frugal overall but more RAM won't hurt.

As for the planning, I'm not sure whether Trac tickets are the way to go for the first steps and basic development. They're great for handling single issues, ideas and features but for the big picture (functional requirements, drafts on what is going to be solved how, feature lists), you may be better of with just an office document, UML diagrams, or whatever you use to collect ideas and build a structure with.

Answer 2

Here's some tips some loosely based on agile methods, which should be pretty good for one man teams, as they don't have much overhead compared to usefulness.

• Make a deployment script - a single command you can run to deploy the app. This way you can easily repeat the steps you do to deploy the app. This reduces chances of making a small mistake or forgetting a step when deploying to production or staging
• I've found developing on my own PC is usually fastest for me. No network delays when working, familiarity with the OS and tools. In the end what matters is personal preference.
• It would be a good idea to have a staging environment, preferably on same hardware/software as the final production environment. This will allow you to confirm everything works OK there, and can allow clients to test drive the changes.
• Try doing periodical releases, similar to Scrum sprints. Choose what features you want to complete for the next release. This makes it easier to concentrate on the most important features as you know what you need to do, and also makes it easier to display progress (Ok this release features A, B and C). Only choose new features for the current release if you finish the ones you chose. Tag each release in source control.
• For the above, you may wish to use Trac to keep track of features, as you said. What tool or approach you use doesn't matter, as long as you have some kind of map or document about what you're doing.
• If you are familiar with unit testing, you may want to consider using Test Driven Development. If not, it might be a good idea to start learning about unit tests

And last but not least, make a schedule and stick to it. Otherwise your project may end up taking considerably longer than expected.

I hope at least some of these help you avoid some mistakes I've made earlier in my career =)