STAREAST 2015 Interview with Bryan Linder on Continuous Delivery


In this interview, Bryan Linder discusses his STAREAST presentation. Look for more keynotes, sessions, and interviews at this year’s STARWEST conference in Anaheim


In this interview, Bryan Linder defines the methodology, processes, and tools associated with release automation, outlines the benefits of more frequent, smaller releases, and talks about his overall experience at STAREAST.

Jennifer Bonine: We're back with more virtual interviews for you guys this afternoon. I have Bryan Linder. Hi, Bryan.

Bryan Linder: Morning.

Jennifer Bonine: How are you doing?

Bryan Linder: Outstanding!

Jennifer Bonine: Good! Bryan, you had a talk this morning on automation and CI and CD. So, for people who aren't familiar with CI and CD, maybe just give them a high-level overview, just on kind of what those things are and what you've seen in terms of trends in that space.

Bryan Linder: Sure. Continuous integration, unit integration tests ... where you are doing that ... You're putting them together and you're putting them in an environment that is fully integrated. Every single time you build something, continuously, on a daily basis. “Oh, we built some stuff, cool. Let's run all our tests. Put it in the environment, run our tests.”

Jennifer Bonine: Getting that feedback ...

Bryan Linder: Constantly getting feedback to develop.

Jennifer Bonine: With the developers constantly.

Bryan Linder: Continuous delivery, putting it in the environment, on a regular basis. Once you're doing continuous integration, you build it, you deliver it to your dev environment. Test it, it worked. Cool. You deliver it to your next environment up the line, next environment up the line, everything up until you get production.

You stop before production, do as much additional testing as you want make yourselves comfortable, then push it for the last step.

Continuous deployment is different, because that's where you cross the line. That's where you say we're comfortable enough with the amount of testing we're doing on our stuff before production. We're going to put in production before we do any extra testing. Test it, test it, test it, test it, test it, next environment, next environment, next environment here it is in production, it's live. God bless it. Let's test it more now.

If there are any problems, make a note of it, put in some hot fixes, or whenever else. You're deploying so fast anyway, if you do see any problems you're confident that you can fix the problem and move it out right away.

Jennifer Bonine: Now that continuous deployment … not for everyone, probably, right?

Bryan Linder: No.

Jennifer Bonine: They don't have the appetite for that.

Bryan Linder: Nope.

Jennifer Bonine: What would you say in terms of where you're seeing that the most? Where people are comfortable with that type of strategy? Because you're in essence letting it out, and you know there's probably going to be issues, right? Because you didn't do all of the testing, but you're relying that once it gets out there, other people will find those things, tell you, and help you then put hot fixes in around those.

Bryan Linder: Sure. I think the trend that I'm seeing is those who are embracing both agile and DevOps methodology.

Jennifer Bonine: Mm-hmm (affirmative)

Bryan Linder: So, really opening that business driven, value driven, communication of the needs for agile, and the communication of the delivery system of DevOps. Between the development team and the business and the development team and IT operations teams. Those groups, the ones that are embracing that culture change, are more comfortable moving things out there knowing, you know what if it's a problem ... Where historically we'd be stuck or we'd have to roll something back ... In these cases we're rolling stuff out fast enough. We can just go address it immediately. It will take less time than waiting to test it further before you get there.

Jennifer Bonine: What's interesting, I think, and in your presentation this morning you talk about it ... We'll ask you to quote that stat again about how many jobs there are out there in DevOps.

Bryan Linder: Yeah.

Jennifer Bonine: I think it's getting ... It's kind of one of those buzzwords and those hot topics right now, that we see conferences that've created whole tracks around it because people are so interested in it.

Bryan Linder: Yep.

Jennifer Bonine: People are flocking to it. Can you tell us that stat, first of all, about how many people think they need it? Do you think people even know what it really is or what they're asking for?

Bryan Linder: Okay, for the first question on the stat, I actually looked this up this morning on Dice and did a search: There are about 1,200 jobs nationwide for DevOps engineers. Which is going to your second question, something that there is no definition for. A DevOps engineer is someone who's got DevOps skill sets and knowledge, which really comes back to there are those people that are developers that understand they need to talk to the IT group.

There are those people who are systems administrators and so on that know they need to talk to the developers to get things done faster and easier for each other and with each other.

Jennifer Bonine: Uh huh.

Bryan Linder: Then there's understanding that we're talking about communication, not another job or another skill. It's getting the people, with those skills to stay siloed and work together, as opposed to creating a third silo that doesn't actually exist, which confuses everybody. Which, obviously, though, a lot of companies think they need it and it is a job. Everybody thinks that. They don't know what it is, but they know they want some.

Jennifer Bonine: They want some of it, right?

Bryan Linder: That's right.

Jennifer Bonine: It's the hot thing that we all want. I think that's interesting that that's the trend now.

Bryan Linder: Yep.

Jennifer Bonine: And everyone goes, “I want some. I don't know really what it is, but I want it because everyone else does.”

Bryan Linder: Yeah, you know what this is almost like for me, down at the expo table we ran out of the little tchotchkes that we brought.

Jennifer Bonine: Uh huh.

Bryan Linder: So we bought a couple dolphins and flamingos and put them on the table. Man, we could have raffled those things for $700. They can go buy them over at the store right here, but people came over, "That is the cutest flamingo I've ever seen in my entire life. It's a pink flamingo that says 'Florida' on it. Cutest thing I've ever seen in my life. How do I get me one of those?" I don't know what it is. I don't care what it is. I just know it's cute.

Jennifer Bonine: I just want it.

Bryan Linder: I really want one of those.

Jennifer Bonine: I really want one.

Bryan Linder: Same thing with DevOps.

Jennifer Bonine: I just really want it.

Bryan Linder: Don't know what it is, know I have to have it, how do I get it? What does it cost? Doesn't matter, I have to have it, give it to me. That's how it goes.

The other thing you talk about, though, around continuous integration, is looking at your return on investment.

Jennifer Bonine: And how to judge the return on investment. For people out there who are getting into this space and looking at continuous integration in their environment, can you give them a high level on how you look at ROI and calculate that for ...

Bryan Linder: Oh, boy.

Jennifer Bonine: I know, right?

Bryan Linder: A high level?

Jennifer Bonine: In three minutes or less.

Bryan Linder: Probably at the highest level, I'd say that it really goes back to your automation maturity. The further up the DevOps and release automation chain you go, the less effort it takes to do it and the more benefits you get out of it. To get that realized benefit, there's a mathematical formula that I use to figure it out. Going any further than that would be time-consuming. That's really what it comes down to, is getting the most benefit and most value out of the works and effort that you put into it, the money that you spend on it.

Jennifer Bonine: Bryan, for those that couldn't attend your presentation this morning, where can they find it on that if they want more information on that and that mathematical formula?

Bryan Linder: As far as for DevOps and release automation itself, all of that should be available with the conference presentation materials, including the handout that we made on the tools comparison application release automation. What they won't find in there is what I use for return on investment analysis.

Jennifer Bonine: Okay.

Bryan Linder: That wasn't part of this presentation, but they can always reach out to me, because they should know where I am.

Jennifer Bonine: Yes, so if people want to find you and want to get more information on calculating ROIs. If you're maybe out there and struggling with how to do that and you need some advice or insight you obviously understand the ROI calculation you also do the tools comparison. You've been through this a lot with a lot of companies ...

Bryan Linder: Many times.

Jennifer Bonine: And about what makes sense in building the strategies. How can they find you reach out to you to get that information?

Bryan Linder: In the slide deck, last file in the deck is my business card.

Jennifer Bonine: Okay.

Bryan Linder: Which has my email address, my cell phone number ... They can reach out to me at any time.

Jennifer Bonine: If they can't find it, can you tell us the email to contact you?

Bryan Linder: Absolutely. It's B-linder, or if you pronounce it straight out, it's blinder.

Jennifer Bonine: Blender.

Bryan Linder: Blinder, B-L-I-N-D-E-R ...

Jennifer Bonine: B-L-I-N-D-E-R.

Bryan Linder:

Jennifer Bonine: So, [email protected], if you need to find some of those things that might not be in the presentation or if they just don't want to sift through all the material and find it, they can always email you or contact you and find you to get more information on that. Real quick, we don't have a lot of time, but there's obviously free tools and paid tools.

Bryan Linder: Yep.

Jennifer Bonine: Ways for people to get information on ... Can a free tool work for me, or do I need to spend a whole bunch of money to do it?

Bryan Linder: Yep, and that’s sort of a trick question, because you always have to spend money. The question is where you're spending it.

Jennifer Bonine: Exactly.

Bryan Linder: When you get a free tool, you're spending it on learning the tool and on building out the frameworks that aren't implemented from scratch. And when you go pay for a tool, you get the free frameworks, you get the support, and you have to pay for the licensing and the maintenance. It's depending on your specific situation.

Jennifer Bonine: It's all about where you want to spend it. Yep, what works.

Bryan Linder: It's what will work best down the road. To keep an eye on that.

Jennifer Bonine: Perfect, we're out of time. Thanks, Bryan.

Bryan Linder: Sure.

Jennifer Bonine: This was great, I appreciate it.

So again, if you're looking to find Brian, [email protected].

Bryan Linder: That's me.

Jennifer Bonine: Thanks, Bryan, I appreciate it.

Bryan Linder: Thank you so much.

Brian LinderAn evaluator of QA tools and technology (“cool QA stuff”), Bryan Linder has more than twenty-one years of experience in quality assurance and control in roles from enterprise QA tools architect through director of QA. Bryan has extensive expertise implementing solutions to streamline the testing process. One highlight was leading an agile effort to integrate the latest test tools from IBM, Microsoft, and Hewlett Packard in a highly regulated environment. Bryan is regularly sought out by firms seeking innovative quality tools architecture and administration, as well as process and technology guidance. Read Bryan’s professional blogs.

About the author

Upcoming Events

Jun 02
Sep 22
Oct 13
Apr 27