Automic, now acquired by CA Technologies Learn more >
 

Bubblegum, Foil and Continuous Delivery: Using the Right Tool for the Job

Applying the wrong continuous delivery tools can be a disaster, so why does it keep happening and how can you avoid it?

Larry Salomon
Larry Salomon, April 26, 2017 12:30 pm
Blog > ARA | Continuous Delivery > Bubblegum, Foil and Continuous Delivery: Using the Right Tool for the Job

My wife and I have a fun dynamic: she approaches situations with surgical precision, while I tend to be more of an imprecise paintbrush. One day, she chastised me 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 in order to 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 "bubblegum and aluminum foil" result allows you to have an enterprise class CI/CD 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 CI/CD 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.)

Orchestrating a Continuous Delivery Pipeline

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

  • 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. Therefore, developers on one team can't modify applications being built by other teams or deploy an application into operational environments that they don't normally have access to.
  • 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?
  • 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 CI/CD strategy.

The original blog can be found at : http://larrysalomon.blogspot.co.uk/2017/04/use-right-tool-for-job.html

A practical blueprint to take you to continuous delivery

Suggested resource

A practical blueprint to take you to continuous delivery
Ebook Download

A practical blueprint to take you to continuous delivery

Follow this action plan to take you all the way to enterprise scale continuous delivery in four steps or less, from wherever you start from.

ARA
Continuous Delivery
Back to the blog
Larry Salomon

Larry Salomon

Larry Salomon Jr. brings 18 years of IT experience focused on application development and delivery. Coupled with his strong focus on the business relevance of technology, Mr. Salomon is a recognized thought leader in the application delivery space. You will find him in several LinkedIn discussion groups and his blog on business related topics (larrysalomon.blogspot.com).