Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

share|improve this question

migrated from stackoverflow.com Sep 9 '11 at 17:46

This question came from our site for professional and enthusiast programmers.

    
Perhaps this should be posted as a community wiki. –  Joel Alejandro Sep 9 '11 at 16:34
    
I wouldn't call it a duplicate, but see stackoverflow.com/questions/6687292/… Basically, you should be using version control with a separate development environment. –  Michael Sep 9 '11 at 16:34
    
git, svn, mercurial, cvs ... what else you need? –  ajreal Sep 9 '11 at 16:35

5 Answers 5

  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.
share|improve this answer
    
Can you please give me some names too please. and 1 up for you answers. thanks –  Anush Sep 9 '11 at 16:43
1  
@Anush - Added some references. –  Joel Alejandro Sep 9 '11 at 16:45
  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.

share|improve this answer

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.

share|improve this answer

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.
share|improve this answer
  1. You can use SVN
  2. No. A sub domain
  3. Project Management
share|improve this answer
    
Can you please give me some names too please. and 1 up for you answers. thanks –  Anush Sep 9 '11 at 16:43
2  
google.com/… –  genesis Sep 9 '11 at 16:44

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.