devops

 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.

Devops Mastery - Episode 16 - Code Management DevOps Tools

What follows are the criteria I use to determine what to script or automate first, second, and so on.  It's another of the "it depends" questions that never have an easy answer.  I will try to help you make some rational decisions but ultimately it's your world to live and you need to decide.

The thing I see everyone want to do first is automate and that takes the longest to do.  That task takes the better part of a week to complete because you are constantly getting pulled in a hundred different directions.  This is not the first thing you need to automate or should automate.  Not that the duration of the task isn't important but the number of times you have to do it, is more important.  I may only spend 2-3 minutes compressing some logs on a development web server.  If I am doing it on 10-20 various servers every week it's not only annoying but it's sucking a lot more time because of the context switching it's causing.  There is also the cost to your company in the time spent by the users of the system trying to troubleshoot the full disk.

So how do I figure out what's sucking up all my time?  Do I track everything I do all the time?  Heck no I don't.  I use a simple spreadsheet to track my work for 3-4 weeks at a time.  I repeat this every 3 months or so.  Then look at what I spent my time on.  I track smaller items with just tick marks and an average time to complete the task.  I don't worry about what time of day it is.  If you want to note the time it takes you for longer tasks it will give you better data but not necessarily better results for this purpose.  Remember the time you are spending on individual tasks isn't as important as the number of times you have to repeat it.   

Now let's flash forward to 3 weeks from now after you have some data collected and answer the following questions.  

    What are the top 10 issues you resolve on a regular basis?
    Are any of the tasks on the list affecting mission critical parts of your organization?  Do you think you should add them to the list? You will likely want to add them and pay close attention to the next item on these tasks.
    How many steps are there to automate in the top 20 tasks you do to resolve these issues? (Exact numbers are not needed, just a really good guess.)

Your top ten list plus the items affecting Mission critical parts of the organization should be your starting point.  To further narrow it down start with the items with the least number of steps.  When doing this though make sure none of the steps are "Install the OS" or "Install Oracle".  Those task steps are not really one step but multi-step tasks on their own.  Now that you have your list ask someone else for input.  Be sure to provide them with the complete list.  I have often described myself and co-workers as being on a mission when they start automating.  This is great, shows focus and determination.  It also can in some cases cause mission blindness.  You want so badly to automate that really hard thing that you miss the quick wins lying at your feet.  Asking someone else to look at your lists will hopefully help you keep from being blind.

Take your own time if you need too complete the list.  As much as the company will benefit from your automation efforts, your work life balance will be the most improved. So spending a little of your time up front will give you more of your back time later.  

If you can reduce a series of tasks you do daily that takes 30 minutes into a single script that runs in 30 seconds over the course of a month you will have 9 more hours to do new scripts.  You will also gain from the lack of typos the script will make on Monday mornings.  If you can take that same script and have it run as a scheduled tasks (think cron or at commands), then you can get back the whole 10 hours to put back into scripting the next thing.  

Remember the goal of automation is to free you from the mundane tasks so that you can work on the more complex and proactive ones.  You will never stop feeling like you are spinning your wheels if you can't get out of the daily repetitive mud.  Automation is the way to push yourself back out onto the proactive route you have been looking to reach.


devops

Benjamin Whitt