The best tools available for implementing Joel Test in .Net_问答_开发者

I need help in setting up the development environment for .Net based projects.

I am currently working in an organization with a 'sole' developer开发者_如何学运维 (me). We develop and maintain the software in-house. We are currently using Visual Studio and manual upload of files -each time for test/production (with making changes in the source code each time!). I've read about the advantages of the 'Joel Test' and was impressed by it's benefits - if followed properly.

My question is

1) Is it too much to implement a partial or complete capabilities where only a single developer is involved.

2) For each of the steps - what are the best tools available? For example - Q.1: Do you use source control? - I want to know which tool is good/best for implementing (1) in my scenario. and so-on for other Points also.

Other Information:

I am looking for solutions which are being used in the industry nowadays., and I am looking for commercial as well as free solutions - as long as they are stable and have a good use-base.

The current setup is like this

IIS-Production, SQL Server-Production

IIS-test,SQL Server-Test

developer machine - with Visual Studio Installed

Any help is greatly appreciated - I am looking for a standard and good solution so that it becomes easy for future developers working there. Thanks!!

Obviously, any answer to these questions will be subjective, and reflect the experiences, bias, etc of the answerer. With that being said, here is my not so short answer:

1) It is not too much to implement. Perhaps you don't have to score 12, but you should definitely be using source control at a minimum.

2) The best tools available? That's like asking me, "What's the best car?" Not only are these things subjective, but the best tools vary by the situation.

(1) Anyhow, I like perforce as a source control system, and I like it a lot. I also like mercurial (hg) and git. I have not really used Team Server, but if you are all Microsoft, that might not be a bad choice either. (I said might).

(2) Can you make a build in one step? You should be able to make a build in one step. msbuild along with some python, bat, nant, or something should get you going. The best tool is the one you know best. My choice would depend on how robust you want it. I like python.

(3) Do you make daily builds? Do you make daily check-ins would really be the question? Why not build every check-in? How big of a system are we talking, and how long does step (2) take?

(4) Do you have a bug database? I would hope you are keeping track of bugs in some way other than a notepad. I like Jira, among others.

(5) Do you fix bugs before writing new code? You should do this. I do.

(6) Do you have an up-to-date schedule? It seems like a logical thing to have. You could use Microsoft Schedule, or any of 100 other neater tools out there.

(7) Do you have a spec? If you're building something bigger than a few days work, it's probably worth writing down what you are building first. These things are pretty obvious, are they not? Try Visio.

(8) Do programmer(s) have quiet working conditions? I prefer music while working, but if quiet is desired, it should be available.

(9) Do you use the best tools money can buy? I find many of the best tools are free, but ymmv, and obviously the job at hand dictates the best tool.

(10) Do you have testers? If you don't now, I would hope you would.

(11) Do new candidates write code during their interview? This seems like good practice.

(12) Do you do hallway usability testing? I suppose this one depends on the product you are making, but it probably can't hurt.

Only a handful of these Joel Tests really require tools, and hopefully I've given you my biased and subjective answers on that.

Well, Joel Test is definitely intended for a larger software development organizations than yours.
So don't forget to use common sense before trying to achieve 12 on it (this advice stands for any organization size, though :-) ).

For a sole developer I would recommend the following.

Source control system is a must. Otherwise you would quickly get yourself in a mess like 'I guess, this bug was introduced two weeks ago when I added a function over there...'.
Subversion is a good choice for a start. Git and Perforce are also good candidates (the latter one costs money, though they offer a free license for 2 users). I wouldn't recommend Microsoft tools here.
Task (bug/feature) database is also a must, because you want to know where you are going and to track the progress. If there're just one or two people involved, a fully-fledged issue tracking system is not necessary. It is nice to have one, but for most practical purposes an Excel spredsheet will be fine.
You could try Jira (afair, they offer free licenses for organisations with <10 developers) or Trac.
Writing a spec before coding. This might be not obvious, but specs are useful. It makes you think through many details of your future implementation far before you get to actually implement it, and thus saves you from spending lots of time going in a wrong direction. Additionally, a good spec would be helpful for your customer, your successor in a project and so on.
Consistent deployment procedure. Don't upload a code from your development configuration to production. It is very easy to forget about some important change you just made, or some debug code yor added, or some uncommitted files and so on. Make a rule that every change goes to source control first, then it is rebuilt from source countrol and tested, after that it is deployed to production.
If your project is small, using a build server might be an overkill, so a simple batch file, or Powershell script, or Nant script will do. In either case, make sure that there is as liitle difference as possible between the build process your dev configuration and the automated build (to avoid 'it works on my machine' syndrome).
Good build servers to try are CruiseControl.Net (FOSS) and TeamCity (free for small projects).
Automated testing. Manual testing, if done properly, is expensive it terms of man-hours spent. Manual testing performed by a developer and/or a customer is usually not done properly and thus not very useful. Automated testing is not easy either, but in a long run it could save you from a lot of headache. Unit testing is a minimum you need for a small project, system testing is harder to do, so probably a few automated (or even manual) sanity checks before and after deployment will do. MSTest or NUnit are good unit testing frameworks.

Daily build per se won't give you much. It is a good tool to catch inconsistencies introduced by different people working on different parts of the project, but for a small single-developer project it won't give you much.

Best tools money can buy are expensive and (assuming you aren't going to use pirated software) could be unaffordable for a small company. Quite often you could get almost the same for free.
If you are choosing between different Visual Studio editions, pay attention to unit testing functionality - MSTest itself and code coverage support. Other differences, afair, are practically insignificant (though you could use NUnit and NCover that are free).
If you can afford it, Resharper is a very worthwhile investment, imho.