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

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.

share|improve this question

closed as too broad by GlenH7, psr, Ixrec, durron597, Robert Harvey Jun 27 '15 at 22:46

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

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.

share|improve this answer

Firstly, I would suggest creating a repository in [source control software of your choice] to track changes, this gives much more than a backup if you're going to be modifying several files, and is a good practice for pretty much every occasion. Include with this SQL scripts to create the database schema (something many web projects seem to neglect in source control).

I would then suggest you create a list of the changes/new features that are desired. Work on one at a time, roll out the changes and ask at least two of the people requesting changes for feedback. Depending on how good they are about it, you should be able to get into a cycle where your work on feature A, commit it, work on feature B, commit that and then have the feedback ready for feature A.

share|improve this answer

As others have said you really need to get the source code in to a repository of some form.

I would also suggest that you need a staging environment; I.e. a copy of the entire system that is not used by live users. This might be a lot of effort, but it is an investment well worth making, it will then let you test your changes with no risk to the live system.

Larger products and team will have multiple staging environments, especially an isolated one for the test team. It sounds like you can get away with one for now.

share|improve this answer

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