Devops Mastery - Episode 16 - Code Management DevOps Tools

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 the benefits of the code management system. If I write a new piece of code on a flight from Cleveland to Dallas I can test it locally and then check it in. Then when I get a connection back to the central server I can pass the code off to other people and complete integration testing and other tasks.

So how do you decide which one to use?

In most cases people in a company will have experience with a tool set. It may sound like a cope out but using the one the majority of people are familiar with in this case is the best place to start. Other things to consider are:

* Cost of the tool - Free, cost per user, cost per X floating/concurrent users

* Operation system requirements of the tool - Is enough of the functionality available to all the OS platforms in your company

* Consistent functionality across operating systems

* Integration with other tools in the environment

* Compatibility with other tools - Support or Plug-in availability with development, Continuous Integration/Deployment systems and testing suites

* How large a learning curve is there for your entire team?

How many different tools in this class should you choose?

Normally a company standard is chosen. This does not always work. Most notably if your company is split between Windows and Linux development. Tools like Microsoft's Team Foundation Server(TFS) work great for .net developers. Linux developers are left with less than optimal tool sets to interact with the Server. Microsoft and other tool providers have recognized this issue and implemented ways to use different tools in a single management interface. In Microsoft's case, this gives people the option to use native TFS and GIT for instance. This may not work for everyone. So having more than one option may make sense. Going beyond two options normally costs exponentially more from an on-boarding and employee training perspective. So one is optimal but two is tolerable.

Who should own this class of tools?

Ever