2012-03-05

Source Control Rant / Migration Strategy

So we've migrated from TFS to Git at work. For all of you haters out there...

TFS is a competent, capable source control engine. It's a huge step forward from the old VSS, and it shows Microsoft is committed to it's customers. It's got a lot of great capability, and it's great for large teams, but it can be difficult for merging and branching strategies. It's relatively simple, but there's a lot of functionality available to those who seek it.

Git is also a competent, capable source control engine. It's a great new way to look at source control, and it really makes sense as a new evolution in source control. It's got a lot of power, and it handles merging and branching better than TFS. However, it's toolset for Visual Studio lacks, and it's more command-line driven than your average Visual Studio coder.

With that said, if your company is migrating from one to another, you need a strategy. Here are a few thoughts...

  1. A source control engine is just a place to save code. TFS is no better than Git which is no better than SVN which is no better then Mercurial which is no better than... They have their strengths and weaknesses, but it doesn't really matter which one you choose... if it works for you. I'm sick of hearing the "I don't want to learn new commands" or the "ProductX is better than ProductY because I said so" arguments. Buck up and deal with it. 
  2. When migrating from ANY technology to ANY OTHER technology, you need to define comparison documentation. Fully flush out the details before your migration. Here are some samples of what these documents might involve....
    • "In TFS, if you right clicked on your solution and clicked "Get Latest Version", with VisualSVN, you'll right click and select "Update"."
    • "In *ProductX*, if you ran the "Install Grapefruit Command", you will need to perform the following steps in *ProductY*: Click X, Drop Down Y, Button Z."
    • "In *ProductX*, if you ran the "DoWork Command", there is no direct equivelant command in *ProductY*. You'll need to see documentation on *FunctionX*, *FunctionY*, and *FunctionZ* to see similar entries."
  3. Your documentation needs to be collaboratively written by someone who is an expert in the new technology and by someone who has never used the new technology before.
Migrating technology is change, and everyone is frightened by change. We're technology professionals, and it is our jobs to embrace change for the sake of improvement. With that said, it's also our jobs to resist change for the sake of change alone. It does not make any sense to answer a question that no one asked, and that's something that a lot of tech professionals have a problem with (I'm looking at you all of you INTJs out there).

It's also our jobs to minimize the impact of the changes on those who aren't ready for it. And that's something we've historically done very poorly. With a little more communication and direction we can reduce this problem though. Remember, resistance comes when people don't know what or why.

And finally, for my sake, please shut up with the technology pissing matches. I don't care if you prefer Git or TFS, .NET or Java, Android or iOS, and neither do your employers.

P.S. Also, I wanted to share a link to a helpful SVN == Git Crash Course Cheat Sheet. http://git.or.cz/course/svn.html

No comments: