Approaches to updating and adding features to PHP websites

Question

I would like to know how people approach with developing their websites that are in production.

For example:-

1. How do you manage versions, etc.
2. Also, do you create a subdirectory within the production server and work there or do you use any other environment and roll the updates there
3. Do you have any special management software where you keep notes, tips, deadlines, etc.

I am asking this because I have a website which I would like to add new features to. But that website is in production. So, what are your suggestions on how you would update your websites and add new features?

I use PHP with Apache on CentOS

Answer 1

1. As far as I'm concerned, versioning can be used for anything. I'm comfortable with SVN.
2. It's preferable to work in separated environments (development / production).
3. There's a wide range of tools for software management. You could check some bug trackers (BlueBug, VersionOne, Trac, etc.), todo-lists (ToDoList, todo.ly, etc.), you name it.

Answer 2

1. I use git, creating a branch for each new feature or bug fix, testing on that branch and then merging it into master only once that branch has been successfully deployed to all production webservers. I generally refer to things by the git SHA when working with the deployment so I make sure I get a specific code version. If I were to refer to the branch instead of the git SHA, I would always be getting the latest code that has been checked into that branch.

2. I do all the development on my laptop (OS X), test in a VM that is a mirror of the production machines (linux) and deploy to the production web servers in a staged manner, watching for new errors or problems as I deploy to each web server. Basically I take one machine out of the load balancer, checkout the appropriate git SHA on that machine, very no problems, then roll out to the rest of the servers. If there's an issue, I just checkout master, otherwise I merge the branch/SHA into master.

3. I use JIRA (it's nearly free for small teams), putting a git SHA into each ticket and letting that ticket be the authoritative source for a bug.

You can replace git with most other revision control systems but I prefer git for it's power and flexibility.

Answer 3

This is a BIG subject with a lot of personal opinion and taste involved.

1) Use version control. There is a lot to choose from here but the more common ones you'll bump into are Subversion (SVN) and Git. I would very much recommend staying away from SUbversion and go for Git, which is what most of the newer open source projects use nowadays.

GitHub has a very good introduction to Git. While you're there - sign up for an account!

2) Keep your environments separate from each other. I recommend having one local site where you do your development and one production which you do not touch unless to deploy a new version. Inbetween you can also have a development machine to test your code or show it off to your client.

I would look into editing your hosts file for this. Personally I use local.example.com for my local machine, dev.example.com for the development environment and www.example.com for production.

3) Again - GitHub provides a very good issue tracker. I could also recommend having a look at Unfuddle and AgileZen. I also hear good things about Sifter App and Lighthouse but I have not tried them myself.

Answer 4

That is a broad question. I tend to work as follows:

1. Dev on my laptop, which duplicates completely my production LAMP
2. before starting a 'feature' release, i code-branch for the new feature, in case i have to push an emergency bug fix on the current trunk (in production)
3. I have a staging LAMP that is an exact duplicate of my production server. Before pushing to production, i push to stage and do some functional and non-functional tests there;
4. I keep three sym links on production servers, 'current' , 'previous' , 'next', each pointing to a directory named SVN_TAG_NUMBER;
5. When I push, I actually create the new SVN_TAG_NUMBER directory that embeds the code and configuration files, etc... so the switchover is basically just to change my current/previous/next sym links (very fast);
6. Before flipping the sym links, i do a quick test with the 'next' (the new feature in your case). I can do this with the help of mod_rewrite : i have a virtual host that points to next, so i can 'go live' privately on the new build. If all pans out, i flip the sym links.

Answer 5

1. You can use SVN
2. No. A sub domain
3. Project Management

Answer 6

You can use any version control system you’re comfortable with; Git, SVN and Mercurial are the more popular. And I suggest that you create a subdomain (‘dev.product.com’ for example) so you can easily deploy, test and rollback changes if you need to without concerns from users. If you’ll plan to use Git, you can add a post-commit hook to the server so it will upload changed files to webserver right after commit. Or if you didn’t have experience with Git, you can just create a cron job to be called periodically and update your files at webserver if new commit arrived.