Search code examples
asp.netintranet

How to setup an ASP.NET development environment?

I am a intranet web developer for a fairly large company and we are finally getting our webpage servers upgraded to Windows Server 2008. Previously we were stuck on Windows Server 2000 and did not have access to run anything except for ASP Classic.

We are going to be moving to ASP.NET development and using Visual Studio 2010 Professional. There are only going to be two developers working on this site for the foreseeable future. I'm curious how to setup our development environment to allow us to work on this site.

Currently our site consists of: online forms, a blog, photo galleries, information resources, ect..

We are getting three new servers running Windows Server 2008. They are going to be configured each with a dedicated role. Development, QA and Production.

I am completely clueless as to how we should develop given our environment. Here are a few scenarios I thought of but I'm sure that there are other options.

  1. Work on the files that are housed on the development server.
  2. Test completed updates on Development Server
  3. Publish to QA and repeat testing
  4. Publish to production and test again

Or

  1. Develop on our local machines (If we do this how do we handle pulling any files needed if we are updating something?)
  2. Publish changes to development
  3. Complete steps 2-4 listed above

Thanks in advance to anyone that can help me here. I really want to jump into this the right way so we don't create any bad habits that we will have to break later.

Solution

  • In our company, we use your second option (develop on local machines first, and then deploy/copy to servers for further testing). To handle retreiving the source files, we use Team Foundation Server (which was free with our MSDN subscriptions) for source control - I highly recommend some type of source control system for any dev shop: helps when you've accidentally deleted files, overwritten code, made changes you regret to an algorithm, etc.

    The reason we do this, is that even though we don't have a lot of developers working on the same app at the same time, we've had issues in the past where one dev will overwrite another's work, thinking that it wouldn't affect the other person, yet erased hours of work (and this has happened multiple times in the past, with apps that are worked on by only two people). Also, you (the developer) have complete control over the environment, so you don't have to worry about admins making changes that break your code while you're trying to figure out another issue (e.g., they reset IIS unannounced in dev).