views:

285

answers:

4

Hi All,

As part of my overall development practices review I'm looking at how best to streamline and automate our ASP.net web development practices.

At the moment, our process goes something like this:

1.) Designer builds frontend as static HTML/CSS on a network share. This gets tweaked until signed off. (e.g. http://myserver/acmesite_design) 2.) Once signed off, developer takes over and copies over frontend html/css to a new directory on the same server (e.g. http://myserver/acmesite_development) 3.) Multiple developers work on local copy until project is complete. 4.) Developer publishes code to an external publicly accessible server for a client to review/signoff. 5.) Edits made locally based on feedback. 6.) Republish to external server. 7.) Signoff 8.) Developer publishes to live public server

What goes wrong? Lots of things!

1.) Version Control - this is obviously a must and is being introduced 2.) Configuration errors - many many times, there are environment specific paths and variables (such as DB names, image upload directories, web server paths etc. etc.) which incorrectly get copied from local to staging to live etc. etc. with very embarressing results.

I'm pretty confident I've got no.1 under control. What about configuration management? Does anyone have any advice as to how best to manage an applications structure within asp.net apps to minimise these kinds of problems?

Thanks in advance.

Ed

A: 

One thing that really helps is making sure you keep your paths relative where you can and centralise them where you can't, so when I've been working with ASP.Net I have tended to use web.config to store any configuration and path related data that can't be found programmatically. It is quite possible to find information like your current application path programmatically through the Request object - it's worth looking in some detail over what the environment makes available to you.

glenatron
A: 

One way to make sure you don't end up on something that is dependent on the path name is having a continuous integration server executing your test suite against your application. Each time this happens you create a random filepath. As soon as someone introduces a dependency on the filepath it will fail.

Jilles
+1  A: 

I found that using SVN, NAnt and NUnit with Cruise Control.net solves a lot of the issues you describe. I think it works well for small groups and it's all free. Just need to learn how to use them.

CruiseControl.net helps you put together builds and continuous integration.

Use NAnt or MSBuild to do different environment builds (DEV, TEST, PROD, etc).

http://confluence.public.thoughtworks.org/display/CCNET/Welcome+to+CruiseControl.NET

metanaito
+1  A: 

You got the most important part right. Use version control. Subversion is a good choice.

I usually store configuration along with the site; i.e. when coding a PHP-based site I have a file named config.php-dist. If you want the site to work at all you'll have to copy + edit in all the required parameters (this avoids storing passwords in version control). The -dist file should have reasonable defaults.

Upload directories should be relative if possible; actually all directories should be relative. I'm not experienced in ASP.net, but if it's anything like PHP the current directory is always the directory of the file being requested. If you channel all requests through a single file (i.e. index.asp), then this can even be found programmatically. Or you could find it programmatically by using the equivalent of dirname(____FILE____) in your configuration file.

I also recommend installing IIS (or whatever webserver you are using) on all development workstations (including the designers). Makes life easier as noone can step on each others toes. What one has to do is simply add test hosts to the hosts file (\windows\system32\drivers\etc\hosts iirc) in addition to adding a site to the local IIS. This plays well with version control (checkout, add site to IIS and hosts-file, edit edit edit commit).