VS.NET 2008 & VS.NET 2005 Solution Files

I recently made the move to Beta 2 for my main project and so-far-so-good, I haven't made the move to the 3.5 framework yet, I probably will as soon as I get the RTM later this month.  I'm being a bit cautious and not installing and beta components on my build server so I did a little research and found this article on information for working with your projects in both VS.NET 2008 and VS.NET 2005 concurrently.

http://west-wind.com/weblog/posts/122975.aspx

Basically just make a copy of your solution file, then change the "Format Version" and "# Visual Studio"

ProjectName_2005.sln

ProjectName_2008.sln

From what I can tell so far, the actual project files just aren't a problem.

-ec

Comparing Microsoft Team Foundation Server and Collection of Open Source Tools

Over the past few months I've been formalizing my deployment process through the use of configuration management tools.  I have what I know feel is a nice environment for doing continuous integration builds, a file is checked the file in, and out pops a build.  Using branching in the TFS Source Control allows for promoting changes from a development to staging as this happens the continuous integration environment picks up that change to the staging branch and deploys the new build to our User Acceptance environment.

Now what I want to do is associate work items completed with the actual builds, since Software Logistics has minimal support staff, this needs to be automated as much as possible.  Basically the flow of a work item should be as follows:

1. End User/Manager enters a bug/task, for the sake of this work flow, let's say this automatically gets assigned to the person responsible for closing the work item.
2. The person responsible for closing the work item should be notified via email
3. At some point we need to figure out scheduling
4. The developer works on the work item
5. Checks in the source code
6. This kicks off a build
7. An RSS Item is created by the build process, included within this RSS Item is the Work Items completed since the last build.
8. Once the manager decides it's time to deploy the changes, they promote the changes to the staging or user acceptance environment
9. This kicks off an additional build, we know the last time the build took place so now we want to associate work items with this build.  This should also be in the form of an RSS entry the client can subscribe to.
10. Included in this RSS entry is the build that can be applied to the production enviornment. 

For now, I've pretty much settled on using the Version Control software that is built in to TFS and Visual Studio 2005 for my IDE, everything else is up in the air.  In addition, this environment should be peiced together with as little new custom projects as possible. 

The two alternatives for putting this environment together are:

1. Fully moving to TFS to manage all of this
2. Peice together a build environment that leverages open source tools.

Microsoft Team Foundation Server Environment

What is really nice about this is that it is an all encompassing solution. 

The following features are built in:

• Work Item Tracking (very customizable)
• Source Control
• MS Build Server

How can you tell how efficient your software development/migration process is?

It might be interesting to develop a set of metrics that capture the amount of time and steps involved with doing certain common activitives on a development effort.  A simple but I think effective measurement might be what is involved with adding a data-driven, context sensitive drop down list to a WinForm or WebForm.  This would involve steps similar to the following:

• Adding the data source to populate the drop down
• Adding the field to be controlled to the data base
• Getting the source from your source control repository
• Modifying the data transfer objects to get the selected value between the database and the control
• Modify the user interface to add the control
• Checking in the changes
• Add some sort of help documentation
• Develop any required tests
• Migration to the three typical environments (Dev, Stage, Prod) for both the application code and database objects.

Come to think of it if this process was captured (even without any metrics) it would go a long ways for developer documentation.

My continous integration environment is coming along nicely.  I currently have five projects integrated...3 web sites, 1 VB Outlook Addin Application and 1 Compact Frameworks Application.  The most advanced project I have in place is a web site that uses the following script:

To summarize:

1. First the Team Foundation Server source control repository is checked to see if any files are updated.
2. If files are updated, then CruiseControl automatically gets all the files from the source control repository.
3. MSBuild kicks off and builds the class libraries and web site.
4. NUnit tests are ran against the class library
5. MSBuild kicks off a Web Deployment Project to update the staging server and change the connection string keys in the web.config file.
6. Last but not least functional test are kicked off through a NUnit test that executes WATIR test scripts

This is working excellent!

Over the last couple of days, I completed a first version of a Continous Integration environment.  If you are not familar with what Continous Integration is, I would recommend an excellent podcast from Scott Hanelman.

I have a dedicated build machine setup that will be hosting two environments for performing build & tests, I'm going to test

• Built In build server from Team Foundation Server
• CruiseControl.NET a product from ThoughtWorks

I had installed the Build Component with TFS a while ago, configured it to run builds and this seemed pretty cool, but haven't spent too much time on this.

The CruiseControl.NET environment I created is fairly basic, but I was able to get it up and running within about an hour.  Here is a summary of what is currently in place.

• CruiseControl.NET runs as a service and is configured with ccnet.config file.
• Within ccnet.config, I created a project that looks at source code within my TFS repository.
• When I check a file in to the TFS repository for the project I created, it get's all the source code under the node specified in the ccnet.config, then runs a task to kick off a build with MSBuild.
• A small application can be installed on our development machine that runs in the tray that allows you to check the status of builds, it also gives you notifications of when builds are completed or they break.
• In addition there is a web based dashboard that will give me a report of the latest builds.

I'm extremely excitied about using additional features that will allow for unit testing and functional testing as well as deployment.  I'm going to compare the Microsoft TFS offerring with the CruiseControl option.  In theory, if I build these both around the the MSBuild tool, I should be able to have similar build processes in both environments.

What experiences have you had with continuous integration or similar technologies?