Tuesday, April 18, 2017

Use the Right Tool for the Job

Image copyright (c) by James Aiken
My wife and I have a fun dynamic: she approaches situations with surgical precision, while I tend to be more of an imprecise paintbrush like you would imagine was used in the painting you see here. One day, she chastised me one day for cutting something with a butter knife and insisted that I should be using a paring knife instead.  I argued that it wasn't needed.

Who was right?

As you can imagine, I was intentionally vague with the description of the situation above so that I could illustrate that an understanding of the context is required to answer it properly.  In this particular situation, I already had the knife out from making my daughter a sandwich for her lunchbox and had switched to cutting strawberries.  So, technically, she was correct, but I was also able to properly execute my task with the tool at hand, literally.

This loosey-goosey approach to executing a process works in some situations, but in others it should be avoided at all costs.  Would a MacGyver approach work with DevOps?  Could you slap together a bunch of unrelated tools in such a way that the proverbial "bubblegum + aluminum foil" result allows you to have an enterprise class CICD solution?  The answer is "probably not."  Yet I have found numerous organizations that attempt to shoehorn single purpose solutions like Jenkins or Chef into the role of CICD orchestrator, only to wonder what went wrong when the level of effort ends up being immense and/or yields something that either doesn't meet their expectations or isn't able to grow with them as an organization.

As with the example about cutting strawberries, context is needed here.  Many commonly used DevOps solutions are single-minded in their purpose:  Jenkins was built to be a continuous integration tool; Chef was built to be a provisioning / configuration management tool; etc.  And just like you wouldn't use bubblegum and aluminum foil to build a jet engine, you shouldn't use solutions to do things they weren't intended to do.  This includes situations where the company that produces such a solution releases a subsequent bolt-on in hopes of expanding the scope of use to include use cases that should not be considered in the first place.  (I'm looking at you, Chef.)

With continuous delivery, specifically, you need to realize that any orchestration solution needs to be able to address the following six verbs:

Who should have access to various applications and processes that are part of an organizational portfolio?  Roll-based access control should allow you to limit who has access to what so that developers on one team can't modify applications being built by other teams, or deploy an application into operational environments to which they don't normally have access.

What artifacts should be included as part of the application deployment process?  Are all artifact types supported by the solution?

Where is the application to be deployed?  Does the solution allow you to deploy across multiple environments while automatically adapting the workflow to account for environment-specific configuration differences?

When do deployments occur?  Can it be on-demand?  Scheduled via a release calendar?  Queued up so that a different function can decide when the queue should be processed?

Why are you using an enterprise class orchestration solution?  Are you still doing enterprise releases twice a year or are you looking to increase the frequency of deployments to be once a week or more frequently than that?  And...

How does an application get deployed?  How is the process defined?  How are integrations with surrounding parts of the ecosystem (e.g. ITSM solutions, etc.) accomplished?

Applying this litmus test to the commonly used solutions like Jenkins, Bamboo, etc. will show you that these solutions often excel in one or possibly two of these areas, but rarely will you find something that addresses all six in a way that allows your organization to benefit without adding risk to the operational side of the business.

The onus is on you to understand the raison d'ĂȘtre of your toolset so that you can also understand why changes may be needed.  If you are looking to expand your capabilities so that you can deliver business functionality to your end users in an expedited fashion while also putting structure around the process so that there is no risk added as a result of the increase in velocity, then you need to stick to evaluating orchestration solutions that were built for this purpose from the beginning.  This will give you the confidence to move forward with the implementation of your CICD strategy.