Shackrock
Shackrock

Reputation: 4701

PHP MySQL and Proper Development / Staging before sending to Production Server

I've just gotten my production site up and running. I have a lot more work to do, and I'm realizing the need now for a development server before pushing changing live onto the production site (with users) - obviously...

This thread (and a lot more on Stack) describe me: Best/Better/Optimal way to setup a Staging/Development server

Anyhow... Reading these threads is outright confusing at times, with all of the thrown around terminology, and my smaller CentOS/Apache knowledge.

My goal is to:

  1. Make some changes to files as needed.
  2. Test the changes on the same server, to ensure settings are identical.
  3. If all is ok, I can now save a version of this somewhere, perhaps locally is enough for now (Bazaar seems like a possibility?)
  4. Finally, replace all of the changed files via SSH or SFTP or something...

My worries are:

I'd love somebody to either link to a great guide for what I'm thinking about (that leaves nothing to imagination I'd hope) - or some kind of suggestion/etc... I'm running in circles trying out different SVN's and progarms to manager them, etc...

I'm the only one developing, and just want a repeatable, trust-worthy solution that can work for me without making my life too miserable trying to get it set up (and keep it set up).

Thanks much.

Upvotes: 4

Views: 1286

Answers (4)

Shackrock
Shackrock

Reputation: 4701

Thank you everyone for the tips/hints/etc...

I've finally found the perfect solution for my needs, SpringLoops... http://www.springloops.com/v2/

It manages my SVN (which I use Tortoise SVN with) - and will actually deploy the changes onto my two sites: staging and production.

I highly recommend it, it's working wonderfully so far.

Thanks!

Upvotes: 1

Michael Berkowski
Michael Berkowski

Reputation: 270599

If you have the ability to create a staging subdomain on the production server, here is how I would (and do) handle it:

Develop on your development machine, storing your code in a VCS. I use subversion, but you may find another you prefer. After making changes, you check in your code.

On your production server, you create a subdomain in an Apache VirtualHost which is identical to, but isolated from your production VirtualHost. Checkout your code from the VCS to the staging subdomain area. After making changes, you then run an update from your VCS, which pulls only changed files down. Staging and production share the same data set, or you may have a separate database for each.

The reason for using a subdomain instead of just a different directory is that it enables you to use the same DocumentRoot for both staging and production. It's also easy to identify where you are if you use something like staging.example.com.

When you're certain everything works as it's supposed to you can run a VCS update on the production side to bring the code up to date.

It is important to be sure that you have instructed Apache to forbid access to the VCS metadata directories (.svn, .git, whatever).

Addendum

To forbid access to .svn directories use a rewrite rule like:

RewriteEngine on
RewriteRule .*\.svn/.* - [F]

This will send a 403 on them. You could also redirect them to the homepage to make it less obvious they're even present.

Upvotes: 3

Dan Grossman
Dan Grossman

Reputation: 52372

You need a version control system, like Subversion, Git or Mercurial.

When you change files, you commit those changes to a repository. This keeps track of all the changes you've made and lets you undo them if it turns out you did something stupid. It also lets you restore files you accidentally delete or lose.

On top of that, it makes deploying updates as simple as typing 'git update' or 'svn update' on the production server. Only the files that changed get transferred and put in place.

You will get this advice no matter how many times the question is re-asked. You need version control.

Upvotes: 0

Scott C Wilson
Scott C Wilson

Reputation: 20016

In terms of worry #1, remember that even StackOverflow periodically goes down for maintenance when people are using it. Just provide a good mechanism for you to switch the site to maintenance mode (and back out) and you'll be fine.

Upvotes: 1

Related Questions