Sign in / up

back to article Tool time: Implementing configuration management, properly

Configuration Management (CM) isn't just about IT, but in the space I have, I want to look at some issues around implementing an IT CM solution. To start with, people often overlook the fact that IT is a fashion industry - but fashion isn't a very good driver for choosing tools that may be critical to your business. The most …

COMMENTS

House rules Send corrections
This topic is closed for new posts.
  1. aaaa

    How to choose a methodology

    I think I (and many others) have written pretty much the same thing a gazillion times:

    http://www.quora.com/How-good-is-git-compared-to-clearcase/answer/Arthur-Barrett

    Of course people still keep asking the same question (what is better Git or XYZ), so maybe it does still need exploring. You've highlighted the need to determine the management vision, and the requirements, but my experience is that finding those out (and putting it in a language everyone can understand) is the stumbling block. People give up and simply resort to: this one integrates with abc, or this one has a nice GUI. Them's not management requirements folks (and integrations and GUI's are simply a dime-a-dozen).

    0 1
  2. jillesvangurp

    Tools go in and out of fashion indeed. There are a few considerations:

    1) Is it open source? This is not about getting free stuff but about long term viability of the solution as well as integration options. For example Perforce is closed source, which means it is largely ignored by the OSS community. This impacts you when doing continuous integration, setting up deployment tooling, etc. You'll find few people with relevant experience setting it up or using it. Most IDEs won't support it. Etc. Kind of makes it a really sucky choice regardless of its other qualities. Google chose Perforce when CVS was mainstream and Subversion had not been released yet. It's the same reason Linus Torvalds opted to develop Git instead and skipped subversion entirely (he wanted an OSS solution). I suspect, large parts of Google's code base are in Git repositories these days. As a professional, I steer clear of anything proprietary. I have zero tolerance on closed source components in my software or tool chain. Rarely worth the trouble bothering with proprietary stuff.

    2) Is it up to date? When picking a new tool, betting on something that is out of date is foolish. Tools that have become unfashionable rarely become fashionable again. If you use subversion, it is time to look onwards. Git is mainstream now and has a bright future. Btw. Git-svn is a superior svn client, useful when stuck with outdated infrastructure.

    3) Is it mainstream or am I taking a bet on some oddball solution? Git used to be the latter but has now become the de-facto choice across the industry. Sometimes these bets pay off. However, most of the oddball Git alternatives failed to get much traction.

    4 2
This topic is closed for new posts.