What is the best practice for asp.net 3.5 build management for fast-changing line of business apps

I work with two other developers for a medium-sized company writing internal applications in asp.net. We have about 10 discrete web applications, about 5 class libraries, and probably two dozen assorted command line and WinForms apps. Management expects us to be able to roll out an application multiple times per day, as required by their business rules du jour.

We are currently (mostly) using Microsoft.Net 1.1 and SourceSafe. When we need to roll out a web app, we get latest from SourceSafe, rebuild, and then copy to the production web server. We are also in the habit of creating massive solution files with 5-10 projects so that everything gets rebuilt and copied to our "master" bin folder instead of opening up each project one by one to rebuild them.

I know there must be a better way to do this, and with Visual Studio 2010 and Microsoft.Net 4.0 being released in the coming months it seems like a good time to upgrade our environment. Does Microsoft have an official opinion/whitepaper on how to set things up? My biggest problem in the past was having a system that worked well with how quickly we're expected to push code into production.

As of note: my previous employer used it, but I wasn't involved in the setup or maintenance of the server, so that's why my answer is so terse.

Broam 2010-02-23 19:54:33

+1 CruiseControl.NET is great for these types of setups. i supported a few applications that needed to roll out daily updates. these automated everything. Switch SVN and work in trunk a release from branches. you'll thank yourself

used2could 2010-02-23 19:57:41

I have to admit, I'm a little confused on how CruiseControl works in an environment like this. It seems most appropriate when you're building a product that has discrete versions, rather than an amorphous blob of ever-changing code.

Donald Hughes 2010-02-23 20:55:45

For an example: I'm making changes to our CRM app. The changes require a few gui changes, a code-behind change, and a data access object change in a separate Data Object class library. What's the recommended process for making these changes? Do I open Visual Studio and work on the class library as an independent solution? Then when I check the code in, CruiseControl will rebuild it?

Donald Hughes 2010-02-23 20:56:04

@Donald: you would likely have a solution with all the parts that you need to work on together - the GUI and the class libraries, and the unit test projects. You'd make all your changes, then submit the changes. CruiseControl (or TFS) will then build all the changed code and run the automated tests. TFS can even be configured to reject your submission unless you've recently run the unit tests and had them succeed.

John Saunders 2010-02-23 20:59:16

So it's considered good form to have solutions like so? Solution 1 consists of Projects A, B, and C. Solution 2 consists of Projects D, B, and C. And the code is always rolled out from CruiseControl's build directory?

Donald Hughes 2010-02-23 21:29:07

What about TeamCity as an alternative to CruiseControl.Net? The free professional version would probably work well with just 3 developers. Also, is there a recommendation for which TDD and Code Coverage tools work best with Visual Studio 2008/2010? Preferably free, since Team System seems rather expensive.

Donald Hughes 2010-02-24 02:53:37

In fact, there's a new pricing structure for VS2010, so it may be much more affordable for small teams.

John Saunders 2010-02-23 20:08:38

Do you know where I can find this new pricing structure? I couldn't seem to find it on MSDN.

Donald Hughes 2010-02-23 20:59:30

This guide was what I was looking for, though I wish it had been less Team System focused.Our plan right now is to setup the following:Build Runner: MSBuild; CI: TeamCity; Testing: xUnit; Mocking: Moq; Code Coverage: PartCover.

Donald Hughes 2010-02-24 16:15:57

Good luck. Note, however, one advantage of TFS over individual products is that everything is kept in a data warehouse, from which useful reports can be had. Many are built-in. For instance, the "Quality Indicators" report which combines build success/failure rates with unit test success/failure rates, code coverage percentage, along with code churn rates. It gives you a nice chart of how these indicators are changing over time.

John Saunders 2010-02-24 16:22:31

ansaurus

tags:

views:

answers:

What is the best practice for asp.net 3.5 build management for fast-changing line of business apps

related questions