Episode description
Before we begin this discussion remember this one thing while you read this; what you use to manage code is less important than making sure you manage it. Management in this context means version tracking, an ability to roll back changes in code, and being able to compare two versions of the code in question. The time people spend trying to track which is the latest version of a backed up file far exceeds the time it takes to learn any repository management tool. Wasting time arguing the merits of the tools is just that a waste of time. While I am not a fan of certain tools in this class they all can handle the basics I have outlined above. I believe so strongly in this that I am not going to share my personal choice or make a recommendation in this article. This tool set has been the domain of developers in most organizations since the dawn of computing. With the focus on software defined infrastructure operation teams need to use these tools. They need to become as adept at using repository management tools as they are with configuring an interface or building out a database. The older systems all worked and did the basics with varying degrees of ease and success. More modern tools like the FLOSS worlds favorite GIT try to advance the tools. That doesn't mean that GIT doesn't have it's issues or drawbacks. These tools generally fall into two sets. The first is a centrally managed system where a server is required to do the basic commands like checking in code. The second is a distributed system which allows everyone to manage locally without a server. This second type then allows you to push the local copy up to a central server for distribution to others. The modern approach and trend is towards distributed systems. They give the people writing the code the most control and flexibility over what they are working on by not requiring a network connection to the central server. I can be completely disconnected from any network and still get all
