I may potentially have some work to implement new features to a client\'s existi

Question

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!)

Cheers

Explanation / Answer

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;

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.

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.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.