arrow_back

Q&A with Joe Campbell: On DevOps Part 2:New Tools, Metrics, and Lessons of Continuous Delivery

headshot_ofJoe_fromseanWelcome to Interview Series! In this Series, we ask questions that you submit through our social media channels to our consulting practice leaders.

So, here we go with Part 2 of our first Interview in the series: Today, we are speaking with Joe Campbell.

Joe is currently our Director of Engineering at CirrusLabs. Over his 20 year career, Joe has led Enterprise DevOps for organizations such as Comcast and ING Direct. He has built continuous delivery capabilities and significantly improved ROI by enabling Agile software develoyment into production by the push of a button. He has also led expansion of system use to track the Agile software development effort from ‘cradle to grave’.

1. How would you combat executive fear associated with having a button that deploys the product?

Executives want to be assured that, when the company deploys code, the code is going to work -- the first time and every time. They care about the reputation of the organization. To alleviate their fear, continuous delivery systems should allow for the same tooling to be used to deliver and verify the code in other environments. Using the same mechanism to deliver code into lower environments like development or Quality Assurance (QA) provides running evidence that the action of deploying isn’t scary, that the process will work -- the first time and every time.

2. What can continuous integration and/or continuous delivery uncover about how software is being developed?

When it starts to pick up speed, Continuous Integration has a tendency to uncover bad habits in software development. For instance, it may uncover partial work or slightly incomplete work causing the build job to run and break. The problem tends to be that developers then don’t want to commit on top of that code, because it is unclear if the code they commit from that point is working correctly or not. This can be painful and can be resolved by developing new team agreements about what to do in the event of a broken build.

Continuous delivery (CD) will uncover just how well your monitoring and metrics work. Continuous Delivery requires that you focus on the right metrics and operational indicators for your application at deployment. If this is all at once, canary deployment, batches, or one-at-a-time monitoring and metrics have to be in place in order to understand the success or failure for the deployment as it is happening. Thus, Continuous Delivery tends to uncover missing metrics for gaining that understanding.

3. What metrics do you advise to use and to avoid?

You have probably heard the saying that you get what you measure… I think that metrics should be used to support the application, the development.

For example, I don’t’ believe in measuring “Number of lines of code committed over the past X time.” When you measure how many lines of code a developer committed, your developers will find a way to game the system and make themselves look good at the expense of the code base. That is, developer metrics may give you an interesting view, but its use in the long run will train people to ‘game’ the metric to make themselves look good. Instead, measure the value that gets delivered from a team. Don’t ‘even’ out the output of each individual to the same thing.

4. What are your thoughts on the industry and new tools coming to market? (Submitted by our friends at cloud test platform Appvance)

The industry is heading in the direction of treating build as a commodity. I don’t know that’s an entirely good direction to head in, because the build portion is the front half of a funnel that delivers software into your environments. How a build fits into your organization and how it delivers on your organization’s needs is important. While it is true that you can get build systems as commercial off-the-shelf software, it still has to be integrated into your processes and existing systems. Builds start off the workflow of software from birth to death – and should function at high levels of success in your organization. It is tough for me to see that as a commodity. For me, it is integral to getting things started along continuous delivery and good configuration management capabilities in your organization.

Now it’s your turn: What do you think? Post your comments below and join the discussion!

Read Part 1 of this interview.

Joe is available for individual conversations. Choose a convenient time here: