If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Web Development Environment Setup

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.

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.

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)

Your reply was quite comprehensive and was close to what I am looking for. Can you please help me a little further to implement this setup in combination of windows and linux environment.
My current setup is like
1. I have development environment setup on my local windows machine with version control (subversion).
2. I upload files with some FTP client OR built-in FTP support of netbeans to Remote Server.

Now to transform this in to wonderful system you proposed...

I want to continue coding on my local environment but I want to test it on remote server (which can have subversion repository also) by creating a test subdomain. Once my test results are satisfactory then I can move code/files to production environment which is of course on same remote server.

For me confusion arises about...

1. How can I upload local files to remote test repository without FTP.
2. What will be the best way of setting up repository on Remote Server so I can easily commit changes from test environment to live environment.

The dev/alpha/beta/live instances I'm referring to above aren't tied to different repos. They're all just site instances. I called them working copies from a PHP dev's perspective, since your WC usually "is" a functioning site instance. If you're working with a compiled language, like C#, the site instances are just builds that you FTP/SFTP out (or copy over the network, or to your inetpub folder, or whatever).

In terms of a repository, you should only have one per application or project. And you need to follow whatever other "best" practices suit your needs. If you're a solo developer, you just need to ensure you always have a branch you can recreate the live site from -- everything else is up to you. If you're working in a group, same thing, except you need to ensure folks know which branch to be working on at any given time for any given "feature" or bug. Etc.

Where that repository lives is up to you. I've actually gotten out of the business of managing subversion installs and just gone with a hosted solution (http://repositoryhosting.com/). But, you don't FTP to or from a repository. You perform updates, commits, etc. All it does it keep track of your code revisions.

But, once you're ready for a client (or the world) to see the fruits of your labor, you can just publish the app by whatever means you normally do. (You CAN use subversion to help with this, but that's not necessary, and it's not the big point here.)

Thank you very much for your reply. I am sorry if I wasn't clear enough with my problem. Right now, I am a bit confused to how to integrate subversion in my processes.

My website is in PHP/Mysql. All I want is a way I can continue coding in my local environment (yes, currently I am the solo developer) and then by some mean (definitely not FTP) upload updates to the test area of the remote server. Once testing is done deploy it to the live site.

Is it possible to make repository with 3 instances dev/test/prod on the remote server? What is the best practice to access dev version to create/update the code. I am using netbeans IDE.

You create a single repository. It's primary purpose is to track and backup revisions of your working copy. If you want to also use it to assist in publishing the code, you can do that. But, it depends entirely on your publishing model.

When I develop PHP, I work directly out of the docroot on my development machine. I exclude files with credentials from the repository. I perform regular svn commits, etc.

When it comes time to publish to machine X, I ssh into machine X, CD to the docroot for the site, and perform an svn update to grab the latest changes. (This works with PHP b/c your working copy can be the same as your published, running copy.) I then FTP or edit credentials files separately.

If you're not working directly from a local docroot, and you instead work from a "project" directory and hit a "publish" button, you may have two repositories, if you want to avoid FTPing anything. One repo to version the actual project code. And another to version the builds (the docroot).