Setting Up Development Environments?

[ohdang888]

Hey guys,

 

I've got my first beta testers on board, and now I need to setup a development environment as I can clearly no longer develop on the live site.

 

What do you find is the best way to do this?

 

currently I have my public_html directory structured like this:

 

public_html/

    site/

    app/

    api/

 

Would be it best to just create a beta_site/ folder, and beta_app/ folders, and then when those are ready, just transfer the files over?

 

How do you setup your development environments and methods?

 

Thanks!

[kicken]

Setup the site on a new sub domain and configure your server to point that domain to a different public_html folder.  Then just copy the contents verbatim to the new folder, and make whatever config changes you might need (like, db credentials).

 

[ohdang888]

Ya, that seems to be straightforward.

 

When you transfer files back to live, do you use rsync?

[scootstah]

It depends how in-depth you want to get.

 

If you want it to be really simple you can differentiate the live site from the development ("beta") site using two virtual hosts under Apache. You could use a subdomain (like beta.example.com) to access the development portion. You could then use version control to push updates to the live site.

 

On the other end of spectrum it is common to have multiple servers for the whole process. Typically there is two separate servers: a development server, and the live production server. Sometimes a staging server is thrown in the middle as well. Note that you don't necessarily need three entire servers for this; you could run all of this off of one dedicated server or VPS. However, ideally, the production server should be a separate entity; that way you can fiddle with things on the server and never worry about bringing down the site.

 

So to break the role of those three types of servers down, it is roughly like this:

- Development server: all of the development occurs here, from start to finish and anything in between.

- Staging server: this server should match the production server as closely as possible. Its purpose is to test the site out as if it were the production site. Most likely the development server will have a more development-friendly setup - more packages, more extensions, more bleeding-edge software versions, etc - so therefore what works on the development server might not actually work on the production server, and you don't want to push an update that breaks the production server because that just makes a big mess.

- Production server: this is the server running the live website. You should avoid touching this server as much as you possibly can, because the last thing you want to do is break the live site. That means absolutely no untested changes or direct file modification.

 

As with the first setup, it is good practice to use version control to push updates to the live production server. This way, even with all of the precautions if an update happens to break something you can quickly and easily revert it - plus there are other benefits like logs and such.

 

Hope that helps.

[The Little Guy]

We use git.

 

The live site doesn't have git on it yet, but our beta one does. We are building a new phpsnips, and we have our beta on beta.phpsnips.com which has git, then we also have a personal copy of the website so we can run it on our personal computers too, then when we like what we have done we commit our changes to the beta. Once the beta is all complete, we will add git to the live site, and download the repository to the live site. This process will take less than 30 seconds. Once the live is the same as the beta we can work on our beta and push to the remote repository hundreds of times, then once there is a new feature ready to go live we will pull from the remote again on the live site and the new stuff will be live almost instantly!

 

git is a fun and useful tool you should look into if you don't use it.

[gizmola]

I second the use of Git. If you can afford to, spend a few bucks on a private github account, or you can setup your own remote repo if you're so inclined. 

 

Then you can take advantage of its features to handle the deployment of your code to production.  Best practice would be:

 

You tag a particular version of your development app using the tagging convention of your liking.  Something like "v1.00.builddate" is my particular preference.

 

In git this is very easy to do, although you want to create an "annotated" tag, as described here. 

 

You can then push the tag to the remote repo:

 

git push --tags

 

Then your deployment script for production literally involves something as simple as this:

 

cd /path/to/prod/dir
git checkout master
git pull
git checkout 

 

This typically takes a few seconds at most to run.