By Michael Flanakin @ 4:51 AM :: 2630 Views :: .NET, Development, Configuration Mgmt, Tools/Utilities, PowerShell :: Digg it!

It's amazing what sticks and what doesn't. Back in Aug 2004, I caught wind of UpdateVersion, a tool Matt Griffith wrote to update version numbers in AssemblyInfo files. The tool is pretty simplistic, but provides an absolute benefit. Every couple of months, I get asked for a copy of the changes I made... despite the fact that they've been available online for years. Nonetheless, it's about time I created a project on CodePlex for the utility. At this point, I don't really expect to make any changes to it, but I will if someone sees value in it. If I were to make any changes, I'd probably go ahead and convert it to .NET 3.5 and possibly even add a PowerShell cmdlet.

By Michael Flanakin @ 3:32 AM :: 2744 Views :: .NET, Java, Development, Architecture, Patterns & Practices, Configuration Mgmt, Open Source/Standards :: Digg it!

In early December, I asked myself whether I'd rather go to Mix or SD West this year. I haven't been to either, but have wanted to go to Mix since its inception. After some thought, I've decided to go to SD West. The main reason for that is because I feel like it'll have better content given my focus. The first year of Mix was all about the web and the second year was a mixed designer+developer event, but still heavily rooted in the web world. I definitely feel at home with that mix, but things seem to be changing again. This year, it sounds like there's going to be even more focus on designer content, so I'll let Mix shake itself out one more year and check out SD West. I look forward to it.

By Michael Flanakin @ 5:26 PM :: 2329 Views :: .NET, Java, Development, Configuration Mgmt, Microsoft :: Digg it!

It's been a while since I've complained about version numbers, but Rocky Lhotka's  latest post about his versioning scheme for CSLA has sparked another bout. What Rocky is doing is retarded. He's dumbing down version numbers for those who fine versioning difficult. When .NET was first released, this is something I knew was coming. Look at Java, where developers deal with a dozen different frameworks and tools just to work on their project and guess what... they're all different version numbers! Hell, even the desktop and server frameworks are different. Ok, so the latter is a tad ridiculous, but the former makes complete sense. Every tool should have its own version number which accurately depicts its version. Major version numbers only change when there's a major change in the code -- typically a breaking change. Sure, this might include .NET 2.0 vs 3.0, but it doesn't have to. Don't blame Microsoft's stupid version numbers on yours. If your users don't understand proper versioning, why the hell are you listening to them!?

I still have to say .NET 3.0 isn't necessarily wrong. WPF was a major change that should've been introduced as a major upgrade. I'd say that all four parts of .NET 3.0 are major updates. The real problem I see with .NET 3.0 has nothing to do with the version number, but the lack of any other improvements, which would've further justified the version number. Honestly, I would've been fine with 2.1 or 3.0. The real butcher of a job Microsoft did on version numbers was 3.5. What the hell was that!? There were no, nor were there ever planned to be any intermediate versions. Again, I'd have been fine with 2.2 or 3.1, but 3.5 was just stupid. I had hoped this wouldn't turn out to be the next version, but no such luck.

On the lighter side of things, the big improvement for Silverlight will now be Silverlight 2.0. I imagine this had something to do with the .NET 3.x version issues. Either way, it's nice to see.

By Michael Flanakin @ 7:00 AM :: 3685 Views :: Development, Configuration Mgmt, Open Source/Standards :: Digg it!

Shelving was a heavily touted feature for TFS when it was first released in early 2006. Microsoft seemed to try to sell it as a new concept, but I argued it was simply an adjustment to an old concept: branching. I will say it's probably a good thing Microsoft put so much into selling the idea. Without it, I don't think most developers would know about such a capability. Then again, there seem to be a lot of developers who still don't know about it. Anyway, back to my point... After playing with shelving in TFS, I'm getting mildly annoyed with it. I guess the reason I say that is because I want it to be treated more like a branch. I believe in the concept of committing logical changesets, meaning I make small changes and commit them individually. Perhaps I take this to an extreme, but I want each change to be tracked independent of any others. When I shelf code, it's usually a sizable change. I'd like to be able to shelf the first change and then incrementally update the shelf with my changes as I go along. I'd also like the ability for others to commit to my shelves, which speaks to the collaborative nature of shelves. This is all a given when you use Svn shelving (aka branching); I just wish TFS was up to it.

By Michael Flanakin @ 5:25 PM :: 2166 Views :: Development, Configuration Mgmt :: Digg it!

I've used about half a dozen or so bug and issue tracking systems over the years and, with that, have come to favor specific setups. The main configuration I'm referring to includes work item status, resolution, priority, and severity. When I first dug into TFS, this was something I looked at and didn't like all that much. With the ability to customize work item templates, tho, I wasn't too concerned. Given that not too many people who work with TFS seem to have much experience with other, more mature bug tracking systems, I figured I'd share my thoughts.

Work item status in TFS is limited to active, resolved, and closed, by default. Without some sort of reason or sub-state, this just isn't enough. I want to say sub-states are probably how most people get around this, but I'd argue that full states are better. This is obviously an individual preference, tho, and only really comes into play when you look at reporting. The statuses I prefer are as follows: unconfirmed, new, assigned, in progress, awaiting info, reopened, resolved, verified, and closed. As with the rest of what I'll cover, anyone with Bugzilla experience will recognize some of these values. Bugs are created as "unconfirmed" and are moved to the "new" status after being triaged. By default, TFS includes a triage property, but I feel this is better covered by status. Again, just my opinion and it comes more into play with reporting. I prefer bugs to remain unassigned by default and then have the status changed to "assigned" when it's actually been assigned to someone. "In progress" and "awaiting info" are gimmes. Once completed, the bug should change from "in progress" to "resolved." When this happens, a resolution needs to be specified to indicate what actually happened. Resolutions are pretty standard: fixed, invalid, won't fix, duplicate, unable to reproduce. I'm thinking there are more resolutions, but this is all I can think of off the top of my head. Once tested, the bug is changed to the "verified" state and ultimately to "closed" once it has been deployed.

Priority and severity go hand-in-hand. All-too-often, I see teams trying to calculate what bugs should be in a certain release by priority alone. While this is a great start, I don't think it's the only factor. Let's just start with priorities, tho. Personally, I like to have at least 5 priorities because it gives you a bit more flexibility than 3 or 4, which seems to be fairly common. That's just a start, tho. I had a conversation with a co-worker, Allan Askar, last week about putting some meaning behind these numbers. We haven't put this to use, but I'm pretty confident that it should make prioritizations across the team much clearer. The key here is that priority is based on the iteration a work item is assigned to. If not assigned to a specific iteration, the work item's priority indicates when the work item should be implemented: 1's in 2 weeks, 2's in a month, 3's in 2 months, 4's in 4 months, and 5's in 6 months. The idea is every wok item would be assigned to the backlog and given a priority based on its importance at that time. During release planning, every item on the backlog would be evaluated to update it's priority and determine whether it should be included in the upcoming release. If an item is included in the release, then priority loses its time-based meaning and picks up a relative priority that simply indicates what order it should be worked on, as you would typically expect. In smaller chunks, we felt the abstract nature of relative priority was adequate; however, a larger group, like the backlog needs more meaning and should work much better. I guess we'll see how that works for us. Obviously, any time frames could work. We just chose some that seem to be somewhat typical on our current project.

Lastly, severity is what brought me into this whole thing. Originally, severity was all about workarounds (on this project). I never felt comfortable with this, so I suggested the following: critical, major, normal, minor, trivial, and enhancement. My guess is that most people are fine with this until they hit "enhancement." To most, a bug is a bug and an enhancement is something completely different. I disagree. I see a "bugs" as code-changing tasks that require testing. This includes simple refactoring changes. Why? Because they have to be regression tested to ensure everything works as expected. If this is skipped, you're risking breaking the app. Seriously, how many times have you saved something without checking it only to find out it either doesn't build or simply breaks logic? Yeah, I thought so. If that's not enough of a reason, then I'll stick to something everyone likes: simplicity. Bugs and enhancements are the same for the most part. Separating them just overcomplicates reporting and tracking.

I should probably modify the default bug and task templates to add some of these things in. Severity probably only works with bugs, but the status and priority concepts are arguably the same.

By Michael Flanakin @ 11:09 AM :: 2495 Views :: .NET, Development, Configuration Mgmt, Tools/Utilities :: Digg it!

If you've been wondering what'll be in the next release of Team Foundation Server, Brian Harry's   done a great job of summing up the final feature list for TFS 2008  in a fairly concise list of bullets. Brian's been doing an outstanding job of evangelizing TFS both internally and externally. If you're interested in its future, this is definately a man to watch!

By Michael Flanakin @ 11:01 AM :: 2920 Views :: Development, Patterns & Practices, Configuration Mgmt, Open Source/Standards :: Digg it!

Standards are very important; especially in team environments. One thing that's been getting to me the past few months is what seems to be a lack of standards when it comes managing Visual SourceSafe (VSS) and Team Foundation Server (TFS) repositories. Since most of my version control experience is with Subversion, I want to bounce back to the fact that data in the repositories is managed very simply. You have three (or four) top-level directories that represent the major version controlled entities: branches, tags, and trunk. The term "tag" may not be familiar to some, so let me just say that tags and labels are the same thing -- an ear-marked version of the repository in a significant state. "Trunk" is another term that some may not be familiar with, but it is essentially the main line of code you're working with. I love the fact that Subversion introduces you to these right off the bat because it almost forces you to learn and abide by good version control practices. You don't have this in the VSS/TFS world. For those who caught on to the optional fourth directory with Subversion, that would be shelves. "What? Subversion doesn't support shelving!" you say? Not true. A shelf is simply a branch in the Subversion world . (Shameless plug: Woohoo! I'm the first result when searching for shelving in Subversion.)

As I mentioned, digging into VSS and TFS for the first time, you don't really see these same principles. It's too bad, because that can cause chaos in the field. Well, maybe the word "chaos" is too strong of a word; but you'll be hard-pressed to find two implementations that work the same exact way. Putting some thought into it, I guess the best thing I can come up with is having an application directory with branch directories sitting alongside it. For instance, if my application is called MyApp, I would have MyApp, MyApp-1.0, MyApp-2.0, and MyApp-2.1. These map to the main and release branches, respectively. Not rocket science, I know, but I just haven't seen a common practice. If anyone has one, I'd love to hear about it. If I have more than one releasable project within my repository, then I'd include all project-related branches within a parent directory called MyApp, or something similar. Then, other releasable projects could sit alongside this one. Again, pretty simple.

Beyond this structure, which will probably change over the coming months, I also have something else of mild interest. Time and time again, I need to explain version control concepts to developers who haven't dealt with configuration management before. Not that I mind, but I recently created an image to visualize this for a project I'm on. I figured I'd share this for others to take advantage of. Looking at it, it's fairly easy to explain how the release cycle works and when/where branching and merging comes into play.

Note that this isn't specific to any type of repository, so whether you use VSS, TFS, Svn, or any other version control solution, it should apply to you just fine. The dark blue line represents the main branch (or trunk). At some point, a code freeze is identified, which is when the codebase is branched for the release. Testing is performed and bug fixes are applied to the release branch while, at the same time, changes are also made to the main branch for the follow-on release. Once the release branch is considered stable, a tag/label is applied (identified by the red star-burst), the release is deployed, and the changes applied to the branch are merged (identified by the orange line) back to the main branch (or trunk). Over time, while development on the main branch is moving along, there will inevitably be bugs in the production system. Let's just say your next major/minor release isn't for another 6 months. In that case, you'll probably want to do a point release to push out a bug fix or two (ok, 10 or 20 ). In this case, developers will pull the latest (aka head) from the specific release branch and apply necessary fixes. This is again tested, tagged/labeled, and re-deployed. To get these changes back into the main branch, the release branch is again merged to the main branch. This process will continue for the life of the project.

Honestly, it's all pretty simple; but as they say, "a picture is worth a thousand words."

By Michael Flanakin @ 9:15 PM :: 2354 Views :: Configuration Mgmt, Open Source/Standards :: Digg it!

CollabNet, maker of Subversion (Svn), has just released a software as a service (SaaS) offering to allow teams to make use of Svn without having to invest time and money into the resources to manage it. I think I’ve see this before, but it was from a small company. I’m glad to see it with Svn from it’s largest backer. At $55/user/month, I’m not sure I’d throw the money towards it, but thaen again, I’m not sure what an offering like this should cost. I would think it'd be based on a mixture of bandwidth and repository size, but what do I know? Personally, I can get a Svn server up and running on Windows within an hour, including having teams and repositories setup using Active Directory authentication. This of course makes it easier to manage and use, since every project I've worked on has had a Windows user-base.

The only real concern I have regarding the offering is intellectual property. With a company like CollabNet, I'm not as worried, but with a smaller company with little at stake, I would severely question it. I know that, as an individual, I’ve questioned offerings like this and would rather manage my own server at home than utilize someone else’s and risk IP loss. Maybe that’s just my nature. Despite my support for open source, I still struggle with handing over large amounts of code and getting nothing in return except a full inbox, which, in effect, costs me more time and money. Not that I’m not willing to give to the community.

Anyway, I’m glad to see this offering and I hope that it will increase the use of Svn.