Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I may potentially have some work to implement new features to a client's existing web application. (I didn't write the original app).

I've never made an app that wasn't written from scratch, and I'm worried about integrating the new features without disrupting the service for too long (or at all).

I don't think the client has an existing code repository set up.

I was thinking that my development process should take the following path:

  • Create an SVN repository and store all the current code in there, including (or making them if needed) SQL files that would be needed to create the current database structure.
  • Get the client's app functioning as it is on a test server with mock-data in the test-server's database.
  • Work as far as possible in cycles to write the code for one feature at a time and then migrate this across to the live app. This is the bit that I'm most unsure about. There will be a short period of time when I'll be uploading some new files and users will most likely experience usability problems (crashes). Should I just display a "working on the server" page while I'm doing this? How would I do that?
  • Also, it seems to me that adding one feature at a time may cause problems, because some of them expect other features to be there to work properly. I suppose the answer to this is to only add a collection of features that can exsit as a stand alone module.
  • Obviously I'd be testing the new code to the max before I migrated it across.

I'd be grateful for any pointers or gotchas, or comments on what I've written above. I really want this to run smoothly for my client (and for me!)


share|improve this question
I'm not sure I understand the question. How else could one possibly proceed? You seem to have covered all the bases. What more do you need to know? Could you list any specific worries or questions you have? – S.Lott Jul 21 '11 at 12:56
"I've never made an app that wasn't written from scratch" - Funny, most people suffer from the opposite problem. – maple_shaft Jul 21 '11 at 13:06
Hi. I did actually list a couple of specific questions above about exactly how one should migrate the code across / display a server down message. Also, It deoesn't seem at all obvious to me that this is the only way to proceed. This is the first time I've had to do this and the purpose of the question is to make sure that I'm not overlooking anything. – Joe Jul 21 '11 at 13:07
@Joe - I would add each major feature. I would consider this a Milestone and request feedback from your client. You indicate some features are linked. In that case add them all at once. What you don't want to do is work against the live website. The simple solution to "how do I migrate" is to simple request the website be disabled for the time being. It sounds like you might have to do that, since you certainly have added new features to program you designed, you already know how to do that. – Ramhound Jul 21 '11 at 13:09
@Ramhound - OK. I can think of about three milestones that will work in that way and not create any conflicts. Cheers for that. – Joe Jul 21 '11 at 13:15
up vote 4 down vote accepted

Your basic work flow sounds entirely sensible. Particularly getting code under revision control and making sure you can recreate the app and database from that source.

I would suggest not updating the live site while it's running. Depending on how the site works you probably have two other options;

  1. Set a new version of the site up on a different IP address and migrate the DNS when you have tested that it works. This only works if there is no user-created dynamic content, ie. if the database doesn't change as a result of user actions, or if you can disable those actions temporarily. This can work well for complete redesigns or static sites as it allows the client to have a play with the website and even beta test with a small group before rolling out. It is likely to suck with any user-driven website unless you can leave the database schema unchanged.

  2. Take the site off-line briefly while you update. Generally I would set up a maintenance site as a separate site and then simultaneously take down the main site and bring up the maintenance site on the same domain. You can then bring up the new website on a different ip or port and test it on the production server. Once you are happy it works you can take down the maintenance site and bring back up the production site.

If you want to minimise disruption you can easily determine from the server logs when the least disruptive time to do this work is. Of course that might be 4am in your local time, in which case it's a negotiation between you and the client as to when you do the updates.

I agree with @Ramhound's comment. Group the features into milestones that are self contained and atomic and release them independently. Try to balance the risks and downtime of updating the production server against the risks of rolling out huge changes in one go. Milestones during the process can also provide a convenient point to invoice the client for that section of work, and demonstrate to the client that you are making progress.

I would also recommend before deploying to the production server that you test the deployment.

  • Duplicate the production server (including database contents if possible) on to the test server.

  • Perform the update on the test server exactly as you intend to on the production server, including any data migration steps.

  • Test the test server version as you would on the production server.

Once you are happy that this works correctly you can then deploy to the production server. I find this, slightly paranoid, approach helpful to catch any last minute issues with missing packages or problems which only occur with data in the production server database.

Good luck, you sound like you're thinking carefully about it all so I'm sure you'll do fine.

share|improve this answer
Thank you so much for your very helpful answer. That's exactly what I wanted to know. I will definitely test the deployment. I hadn't thought of doing that at all. Anything that minimises the risk of bringing down the site is worth doing and I'm sure I'll learn loads just by going through the process a couple of times. Brilliant. Cheers Luke. – Joe Jul 21 '11 at 14:41

Automated integration testing is your FRIEND.

Go look up Selenium, which is an automated web site testing application. Set up a complete suite of tests that thoroughly exercises the CURRENT functionality of the site. Then, periodically as you develop, run your tests and satisfy yourself that your changes haven't broken anything.

Also (as has been mentioned) do this on a staging server, not the live production server. And use version control--I generally recommend git, as its branching abilities lend themselves perfectly to this sort of development process.

share|improve this answer

Your Answer


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

Not the answer you're looking for? Browse other questions tagged or ask your own question.