Web Development Environment Setup

[tuttle425]

I have been looking around the web and forums for a while for the best way to set up a development office. I havent really found many specifics.

I am with a new company is just starting to really take their development services seriously. We've added a couple developers and designers in the last month. I am trying to figure out a the best way to set up our environment.

We have a couple dedicated virtual servers with Media Temple. Currently, we develop everything under a subdomain of a domain we set up for development. When the site is ready to go live we move the site to its own domain. I cant believe this is the best way to go about things. So, what do you guys suggest as a setup? Software, versioning, etc. We have the ability to setup a test server in house and then push out changes to the production server but not really sure if that is needed.

We do mainly Wordpress development.

Any advice, links to articles, etc is appreciated.

If this should be posted in another area, please let me know.

Thanks

[ilurn]

I would also like to know this answer.
Thank you

[svidgen]

First, see my response to this thread: http://www.webdeveloper.com/forum/showthread.php?p=1144867#post1144867

Now, as a member of a client organization dealing with larger development firms, I've found that, while there is no single way to do things, there are some patterns to follow:

Use subversion or CVS. Simple -- just make sure your project is under some version control somewhere. So far, I have yet to encounter anyone using anything other than subversion.

Multiple working copies. You'll have multiple functioning copies of the application, each of which gets updated on a different schedule, and each of which will have different levels of reliability and testing needs. So, you may end up with "layers" like this:

Dev
Lives on: the actual development machine(s): you and your co-developers' local PCs, macbooks, etc.
Updated: constantly -- every time code is changed.
Reliability: consider these copies highly unreliable -- they should have their own data sets.

Alpha
Lives on: a publicly accessible server, possibly password protected to protect IP, which may or may not live on the production server
Updated: often -- daily, weekly, or whenever you accomplish something and are reasonably sure it's stable
reliability: pretty low -- it uses its own dataset, which may even have a lot of lingering structures from past explorations and tests

Beta/Staging
Lives on: a publicly accessible server, which may or may not be the alpha and/or production server
Updated: whenever the project on alpha reaches a state that is ready for final QA before going to production
reliability: pretty good -- beta environments can sometimes even share data with production, depending on whether there are outstanding schema updates to make to the production dataset

Production/Live
Self explanatory -- the public application.

Now, some firms will break down alpha, beta, or staging environments even further. Some developers will simply have one beta environment that serves most or all non-production needs. And how you lay these all out on hardware is really up to you. If you're working on a multi-core machine and ensure that your database connections are configured safely and correctly, you generally don't have to worry about your dev/alpha/staging copies affecting live. And if everything is on the same hardware, it can make turning your alpha into beta and beta into staging and staging into production really snappy.

In terms of the virtual hosting setup -- I tend to prefer giving each stage its own hostname:
local.sitename.com : local hosts entry -> 127.0.0.1
alpha.sitename.com : local OR actual DNS entry -> alpha server
beta.sitename.com : actual DNS entry -> beta server, could be same as alpha or beta
staging.sitename.com : actual DNS entry -> probably same as live server
www.sitename.com : actual DNS entry -> live server ... obviously.

And the application needs to be smart enough to "know" which host it's working under, refer to files correctly, and use the right data resources. For me, I have found that this is best done placing a localconfig file on each environment that lives outside the repository or "project" (if using an IDE), that will not be overwritten on accident, and serves to rewrite a set of default values. (so the site functions as the LIVE site in the absence of that file -- so when you package up the app and hand it off, you don't have to worry about forgetting to include some file that doesn't exist in your project)

... is that at all helpful? Sorry for the rambling.