Static Code Analysis on Visual Studio .NET 2005
I've always been very intrigued with the idea of Static Code Analysis, or checking to make sure you follow the design rules on your code. This is built in to Visual Studio .NET 2005, within the Project Settings on the “Code Analysis” tab.
Once you have a project of any size and then turn this on, you may find thousands of violations, some of these may be helpful, but most will probably not be. One way to start distinguishing between the helpful items and items that may be considered “too-picky” would be to turn this on in your project before you write your first line of code. As you add code you will see which items get flagged with warnings and if they are considered “too-picky” or there isn’t anything you can do about this, you can just turn that item off.
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:
- 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.
- The person responsible for closing the work item should be notified via email
- At some point we need to figure out scheduling
- The developer works on the work item
- Checks in the source code
- This kicks off a build
- An RSS Item is created by the build process, included within this RSS Item is the Work Items completed since the last build.
- Once the manager decides it's time to deploy the changes, they promote the changes to the staging or user acceptance environment
- 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.
- 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:
- Fully moving to TFS to manage all of this
- 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
Viewing Debug Messages with a Very Small Foot Print
Recently I needed to get and HttpModule working within a .NET application on a remote machine. As it always goes, it was working on my local machine, I'm sure you know what that is like.
I didn't want to install VS.NET or the .NET SDK on the remote machine to view debug messages since this was a production box. I then remembered a company called SysInternals develops a lot of very cool software so I went to there site and found there DebugView application.
This was exactly what I was looking for, with this in place, within about 30 seconds I figured out what was going on and was able to move on to my next task.
If you haven't checked them out I highly recommend it!
I've worked on projects at both extremes and I'm not sure what the answer is yet on this question. I've worked on projects where as soon as we started producing "almost" workable code we moved it to the testers to start writing bugs. I've also worked on projects where the expectation was the application was "perfect" (well you know as perfect as software gets before it is tested).
I think there needs to be a happy medium between those two extremes...
Testing To Early
If you start testing to early you will waste the testers time, and you'll wind up with a huge number of bugs that you will be chasing instead of adding new functionality. This also puts a burden on the PM in that they need to estimate and prioritize, probably not a good use of anyone's time early on the project.
Waiting for the project to be "Perfect"
This also doesn't make sense from a couple of different perspectives, first the person developing the application generally won't find the obscure bugs as quickly as someone that didn't develop it. Also, it would be a shame to develop the "perfect" application only to realize that the functionality really didn't match what was expected.
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.
I really like this quote from "Verizon" I think it would be a great tag line for my company but Verizon might not like it too much.
So what does it mean to make progress every day? On a software development effort progress can be measured in two distinct areas:
- Progress building your software product
- Progress adding features/functionality to that software that helps achieves the business goals.
Chances are your company wants to focus on the second of these two points, since they are not generally in the business of writing software for the sake of writing software. This doesn't however say that the first item is not important. Actually the efficient coder knows that building a solid foundation early on in the project will pay huge dividends once work begins on the actually functional requirements of the system.
Let's look at an analogy of Race Cars. The object of building a race car is to be able to go fast and complete/win races. However to do this there are a number of factors that contribute to the ability to go fast and complete/win the race. Going fast there really needs to combine performance, safety, measurement and control.
With most software development efforts, man-hours is the most significant expense in building a system, also time to market with respect to your competitors may also be an important factor. Therefore it seems obvious but the quicker you build your system, the better off you will be. Stating that however there is a real difference between speed and progress, if you are going real fast in the wrong direction or quickly building a system that is ripe with defects you may be going real fast but not making much progress.
To make real progress you need the right people, process and technology as well as management that understands that when development effort begins a significant effort will be in place to work on a foundation that may not have many visibile deliverables beyound the development team. Then once the visible deliverables start to be created, they will come at a very rapid pace and of a higher level of quality.
Either I've got my mind into building the race car (building the tools and the infrastructure) or racing the car (building the actual application). Working on these two different areas require a different mind-set and what I've found is if I spend a greater amount of time building an efficient race car, the faster it will go once I start the race. The down side here is that if the car was built to race on an off-road course, but it needs to be ran on a paved oval course, I've probably wasted a lot of time and won't have a car that will perform very well.
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:
- First the Team Foundation Server source control repository is checked to see if any files are updated.
- If files are updated, then CruiseControl automatically gets all the files from the source control repository.
- MSBuild kicks off and builds the class libraries and web site.
- NUnit tests are ran against the class library
- MSBuild kicks off a Web Deployment Project to update the staging server and change the connection string keys in the web.config file.
- 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
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?
Upgrading from Beta 3 refresh of TFS to RTM, was as painful as I expected (but probably my own fault). With great hopes, I downloaded the Team Foundation Server Upgrade Package and faithfully followed the steps within the document.
The first thing I learned when applying the update was the Beta 3 Refresh of TFS was incorrectly installed. I purchased a server off of ebay to have a dedicated machine running this software, however when I installed SharePoint services, I missed the step to install it with the "Server Farm" option. This created a named instances of SQL Server independent of the SQL install hosting TFS. When the TFSUpgrade utility attempted to apply the updates to the SharePoint databases, it failed since the upgrade was looking in the default instances. I moved the databases from the SharePoint instance to the default instance, and I think that was the cause of most of the problems.
To make a long painful story short here are the next steps I did to complete the effort...
- Ensure I had backups of all the databases involved (before and after I ran the TFS Upgrade Utility).
- Uninstall Beta3 refresh of TFS
- Attempted to install the RTM version, got SharePoint errors (stmadm.exe did not return zero)
- Attempted new settings in SharePoint for "Default Config" db, as well as the "Content DBs" for virtual servers.
- Uninstalled SharePoint, reinstalled with Server Farm option selected (this allows for TFS to manage the database configuration).
- Attempted to install RTM version again, got similar SharePoint errors.
- After trying different combinations, looking at the data within the STS databases, after about 4 hours I decided to just rebuild the box install TFS from scratch.
- This went well, everything worked as expected and within about 1.5 hours I went from a formatted hard-drive to an up and running TFS server (probably would have been quicker, but this is an older PIII Xeon @ 1.1GHz)
- For the moment of truth...I restored the backups of all my databases...DOH, when I rebuilt the box, I had thought hmmm, it was named SLNETPSQL3 before, let's name it SLNETTFS this time...big mistake!!! After I restored, all the data referenced the name of the original server SLNETPSQL3, I probably spent about an hour or two attempting to figure out how to change everything over, but no luck...
- Decided to just go ahead and rebuild it one more time, this time with the original server name. Again about 1.5 hours later I had a fresh install of TFS with everything working just fine. I made a copy fo the original DB's.
- Next I attempted to restore the original DB's, at soon as I did this, I couldn't connect to TFS with any of the users. So at at this point, I had about 20 hours into the upgrade and needed to get some work done to pay the bills, so I decided to just restore the databases from the fresh copy that I knew worked.
- I was in business, then I just restored the versions of my production TFSIntegration db to a different name, copied the tables tbl_projects, tbl_security_projects & tbl_security_objects for those projects into my new database.
- At that point, my projects came on line.
- I restored the TFSVersionControl database and all my source history got restored YIPPPPPEEEEE!!! (I had off-line backups of the source, but it was nice to be able to keep the source history)
- Next I had thought, ok let's get the work items in there...no luck here, there is data in the TFSIntegration database that needed to be tied to the data within the work items db, so this did not restore to work with my new version of the projects in the TFSIntegration DB.
- I tried for about a couple of hours to manually import the tables, but ran in to some F-Key violations that stemmed form the work items not being created for the projects (I think I know what I need to do to restore these, but again need to get some real work done to pay the bills, probably do another post when I get this completed.
Anyway - things are all well, I have a couple of legacy TFS projects that are limping along but useable non-the-less.
Has any one else had similar experiences?
*Note - Although my experience documented here wasn't too "pleasant" it is probably due to my lack of my prior knowledge on TFS configuration and architecture and learning on the fly. This was an excellent learning experience and the more I learn about the capabilities of this product, the more I like it!
|