Having a properly structured project—or more properly, solution—is absolutely vital to ensuring a development initiative’s success. In a pinch, a developer needs to be able to pull the solution from source control, force a restore of the database and any other external dependencies, make minor and appropriate configuration changes and have a building, functional solution. There are alot of nuances to making this work in practice, but the essence of keeping things manageable can be expressed in three rather simple, yet meaty, rules.
Always use some sort of source control.
There are a number of source control solutions available to cover nearly any development situation from the lone hobbyist to huge geographically distributed teams. Exactly which one you use should be driven by your requirements and infrastructure. But developing without a source control system in place is irresponsible to your clients or employers or just yourself. You don’t even have to get involved with managing the system yourself—hosted SVN solutions are available for a few dollars a month. And several sites offer free, public source control systems for open source projects.
Why is this source control system such a cruical component? Because every software solution needs one, and only one true source. Otherwise, when that hard drive, supplied by the lowest bidder, dies a horrible clanking death, you will be challenged to restore the status quo ante mortem.
If it is an integral part of the project, it is in source control.
It used to be common wisdom that binaries do not belong in source control. The argument against this revolved around the fact that binaries are comparatively huge and cannot be differenced so it was expensive and made little sense to store them in a controlled sense. Neither of those facts are false, but if the operational goal of using source control is to provide one true source for everything you need for to make It fly, then those binaries should be in source control. Things this would include are items like 3rd party libraries (including unit testing frameworks), databases, art files and especially technical documentation. If someone needs to do emergency maintenance while I am sitting beach-side in Dubai, I really would prefer not to be disturbed.
One very interesting tangential question here is “should a database drop be included in this system?” My general answer is a resounding yes, with an understanding that this could be logistically impossible due to the size or sensitivity of these files. If that is not the case, all efforts should be made to attach a sample database to the source-controlled solution in order to ensure that a developer is dealing with a one-stop shop.
Redeployment to a virgin environment must be a minimum fuss operation.
How many times have you received a project which, even if it builds on the first attempt, requires hours of tweaking and futzing with configuration files, system settings and database details to make it actually work? This should never happen.
In a perfect world, you should be able to get the solution from source control, run a script and everything should just work. This scenario is often a bit hopeful for many complex applications. But redeployment should be a simple, repeatable operation at worst. This means that there should be a database creation and/or restoration script, including appropriate code to re-wire users and roles. And it also means that any estoric system settings dependencies shall be scripted.
I intentionally avoided giving specific recommendations here as exactly what to do really depends on the nature of your project and your environment. This is not to say one cannot learn from concrete examples. For that, I would start with SubText, the .NET blogging package, as it is very, very well organized in general. Furthermore, the project in many way resembles a custom long-lived, medium scale web application. The kinds of things most of you probably are working on. Enjoy, and keep those solutions well-managed.