Historically I\'ve been able to get away with making small changes to an in-hous

Question

Historically I've been able to get away with making small changes to an in-house helpdesk system riding on a LAMP stack and just making a backup prior to editing.

This has no user acceptance / testing phase and I work on the live .php files directly.

However now the requirement has arisen that will require a bit more coding done, and I'm obviously not particularly happy about making these changes without a framework to support me.

What would the best way forward be? I could just make another backup I suppose.

Explanation / Answer

What you have been doing can be dangerous, but you've been able to get away with it because the target audience of the site was so small and understanding. The best analogy I can think of is walking a high wire without a net. You might be good at it, but all it takes is one bad fall to end your career (at least with that client). At the very least you want to separate your development environment from your deployed environment.

Definitely make a backup of your site before beginning. If you don't have it already, I highly recommend some form of version control. It's an effective way to do fine-grained backups, and keep the right version of the software where you need it. For your particular environment, you may want to look at Mercurial or Git (distributed version control). The advantage is that you can import your existing code on the server, and then pull a copy of it to another machine where you can start work. When you are done with the changes, you can push those changes back to the server. When you update the repository on the server, everything is up to date. If you need to go back in time, just use the tool to get to an older version.

You'll need to back up your database and restore it in your development environment. Ideally you'll be starting with a fresh database and adding just those features you need, but in this case I'm fairly confident you may not have current scripts to set up a starting database properly. Configure your local development environment to work with your local copy of the database. You'll need to create test data if this is not a trivial improvement, and that way your users won't yell at you for creating the fake data.

As you work, commit often to your local repository--but don't push to the server until you are complete with the nontrivial task. That makes it easier to experiment, but if you don't like the way your experiment went, you can reset back to a point you did like without having to redo everything. Once you are happy with everything you can push it to the server and update the local repository there.

Bottom line is that once you've made this separation, you can add a separate test or preview instance of the application at will so people can bang on it without messing up the production install.

Related Questions

Navigate

• Browse (All)
• Browse H
• Subjects

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