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? Everyone in IT. Ownership is different than management. Owners have a vested interest in the health of the system they own. In this case both Developers, Testers, and Operations Teams can be affected by the choices and processes used to do things like upgrades and maintenance. So everyone should be represented when decisions about the tool(s) are made. Should you only keep code in the repositories? Because repositories don't have to be limited to code they make it easy to create work flow procedures based on them. Often it makes a lot of sense to keep even the requirements documentation in a repository so that everyone can see the history of what and when they changed. Most of these tools have a method for kicking off other processes when a change has been made to some or all of the repository. These are called hooks and can do everything from kicking off Continuous Integration/Deployment work flows to sending a message to the next group in the process work flow for review. Remember the tool you choose is less important than that you use one. Discussions about these tools often come with a lot of passion. So take the time to talk through the options and listen to everyone before making a final decision. I would also recommend that larger companies choose a small team of people who are passionate about this class of tools to represent the larger groups. It will help to manage the process and hopefully build consensus about the final decision. The people on the team should also agree to be advocates of the chosen tool(s) to the larger group.

You can listen to Episode 16 - Code Management DevOps Tools online on Radio and Podcast. Open the player on this page to stream the available audio.

Episode 16 - Code Management DevOps Tools is an episode from Devops Mastery by Devops Mastery.

This episode is 00:17:50 long.

This episode was published on Jul 10, 2014.

Yes. Use the heart button on the episode page to add it to your favorite episodes list.

Yes. This page shows related episodes from Devops Mastery when more episodes are available from the podcast feed.