This DevOps Chat features OpenMake CEO Tracy Ragan. OpenMake are the producers of DeployHub and DeployHub Pro, which help DevOps with CI/CD. OpenMake is a company that was helping developers long before people spoke about DevOps. Using an open-source business model with DeployHub has transformed the company. We speak with CEO Tracy Ragan to find out how.

Audio

Transcript

Alan Shimel: Hey, everyone, it’s Alan Shimel, DevOps.com, DevOps Chat, and, in this episode of the chat, we’re joined by Tracy Ragan, CEO OpenMake Software. Tracy, welcome to DevOps Chat.

Tracy Ragan: Thank you, Alan. Thank you so much for inviting me. It’s my pleasure.

Shimel: Okay. So, Tracy, the last time I think you and I caught up, we were over at Jenkins World, out in San Francisco, a couple of weeks ago. And, you know, that was quite an event and it really kind of spoke to how big the CD space is becoming—you know, the CD market and the kinds of companies that are utilizing different CD solutions. Of course, OpenMake, you know, plays in that market arena, Tracy, but, for those of our listeners who maybe aren’t familiar with OpenMake, can you give us a little background?

Ragan: Absolutely. So OpenMake Software has been playing in this continuous delivery space long before it was in fashion. Our initial product, our Meister product, was created about 20 years ago, and it was created to accelerate the process of compiling code once it was checked into a version control tool. So you check in and you build—we were doing that close to 20 years ago. Now we were just doing builds off of a trigger; we weren’t doing continuous integration. What we were doing was the hardcore build automation, and what I mean by that—the automatic generation of the compile and link scripts, the acceleration of the compile process, and the dependency management so you could do just-in-time builds, to speed up the process of moving code forward.

So we were really early on in understanding the need for faster delivery of code and the ability to create what we call a “release candidate” at any point in what used to be call the “life cycle” and now what we’re calling the “pipeline.” So this is an area that we have heavy expertise in and a lot of heart for.

Shimel: Absolutely. You know, Tracy, one of the things that I always find interesting, and somewhat sad, is that, when we talk CD, right, some people—I think most people still refer to continuous delivery, but others, you know, talk about continuous deployment, and then, unfortunately, I think there’s a Venn diagram kind of subset that think that somehow continuous delivery and continuous deployment are one and the same. And—

Ragan: Yes.

Shimel: – why don’t we start with destroying that myth? Right? What’s the difference? Is there a difference—I think there is—between continuous delivery, continuous deployment?

Ragan: So if we look at the continuous integration process—and I think that’s where we have to start, to understand continuous delivery and then, of course, continuous build and continuous tests and continuous deployment underneath that— so continuous integration itself, I don’t wanna say it doesn’t do anything, but, in itself, it’s an orchestrator. It itself doesn’t compile code, it doesn’t test code, and it doesn’t deploy code. What does those steps are the unsung heroes who oftentimes write scripts or automation tools that sits underneath that process.

Continuous delivery is the ability to have a release candidate ready to go at any point in time across what’s now called the “pipeline,” so, if you have a continuous integration at the dev state, you might also have one at a test state—now this sounds very waterfall, which is why I don’t like to describe it this way—but, in essence, what you’re doing is saying, “The development teams are ready and they have a release candidate they wanna push off to testing. Testing should automatically test it and then push it off to production.” Now what’s core, what’s the lowest common denominator between those simple three states, is the ability to get it out to end targets so you can actually run a test at dev or run a test at test or execute it at prod. That’s what continuous deployment does.

I prefer to call it “continuous deployment.” We often hear it referred to as “application release automation,” or ARA, and that sometimes feels a little heavy and waterfall-like, but, in essence, that’s what those tools are doing, is they’re doing continuous deployment, in the same way as test automation tool does continuous test and in the same way, you could say, Maven or a product like our Meister is doing continuous build, all driven through a CI/CD workflow.

Shimel: Excellent. Excellent. And, you know, you hit on something else there—ARA. And that, again, we’ve seen several vendors kind of stake—they’ll put a flag in the ground around ARA. So now that we’ve got some basic definitions done, Trace, let’s talk about how do we move right—in this case, it’s almost shifting right, right?—how do we move rightwards down this deployment—delivery, deployment, management—you know, timeline? And—

Ragan: So I think what we have to do is we have to talk about DevOps, right? So we have this other big term that’s being thrown around, and that’s “DevOps.” Everybody I speak to has a different opinion of what DevOps is, so I’ll just share with you mine. DevOps is the process in which the development teams start taking over more of the operational tasks. And the operation teams’ role is mainly one of auditing or having some level of control. My guess is that, as DevOps is pushed left, so developers are doing more of the work, we’re going to see operation teams become smaller.

And that’s really—if you really look at what companies are doing, they have large operation teams because they’re doing their own thing when it comes to doing software releases. They’re not part of the CI/CD process, in many of these cases. But, in reality, what happens is is that the developers are the ones who have to do the hand-holding at production, so the more we can get developers to declare their definitions around their software deployments, what their environment looks like, the easier it becomes for the data centers to become leaner. And that’s really what Agile, DevOps is all about, is getting, in the hands of the developers, tools that can automate these operational tasks to a point that the testing teams and the production teams can consume them and have some transparency and some level of control around them.

Shimel: Got it.

Ragan: So that’s what continuous deployment, application release automation, is achieving, is that ability for developers to dig in at the dev level, not with scripts because scripts can’t adapt across the pipeline, but to do that in a model-driven way that could adapt across a pipeline, so that the work – all the declarations are done down at dev, and the users of that are testing and production. Even down to a configuration change, if need be, at a Cisco router level. We’re talking low-level definitions.

Shimel: Sure. Sure. So, you know, Tracy, it’s funny; you guys over at OpenMake have been involved in this space, as you said, 20 years, right? Way before we start using—throwing around the terms “DevOps” and “continuous” this and “continuous” that. And kind of living in the DevOps bubble, if you will, we think, “Oh, everyone’s doing this kind of stuff and this is the way it should be done and this is the way it is being done.” But, really, when you look at it—and you probably have a better view than most, Tracy—how far along are we on market adoption, around this, you know, more—I think it’s a more holistic approach to DevOps and continuous delivery and deployment, as well as ARA?

Ragan: That’s a hard one to answer. I can give you my best guess and give you some numbers I hear from the analyst. If we talk about ARA, the analyst tell us about 20 percent of the companies have adopted ARA. Now, but, that being said, when I hear—yeah?

Shimel: Yeah, I was gonna say that sounds high to me.

Ragan: It does, but let me tell you why it sounds high. It sounds high because, when companies adopt an ARA solution, they’re often talking about a legacy product that somebody on the operations side of the house decided to purchase. And, oftentimes, they’re legacy because they have the requirement of in-target agents, so the decision to put an agent on every single production end point, including cloud or even define them to a micro-service, has to be done way right. That doesn’t mean that we’re doing continuous deployment; it means that their operations side of the house decided on a tool that may or may not be adopted by the left side of the house.

You know, when I talk to companies, most of them will talk about that they’re adopting DevOps, but if you ask them if they’re able to solve a build in less than 10 minutes or if production can repeat the deployment that developers defined, the answer will be “No.” So the reason why it’s hard to answer that question, to get clear metrics on it, is because everybody’s definition of what that is is so drastically different.

Shimel: Yeah.

Ragan: In my mind, I’ve only met a few companies that have really established a real Agile, DevOps practice, and it’s not for the entire organization—it’s for a few teams—so we’re babies, when it comes to this. I believe we have a long way to go to really understand how to make that shift left so that this Agile concept of where testing and production are not separate states in life cycle and separate silos, but part of a circular process that is included everybody on the same team. So waterfall still persist, and to be quite honest, in continuous integration, if you look at what drives the CI process, we are still using the same waterfall scripts that we did, you know, five or 10 years ago, depending on how far you are in CI. Much of the stuff, they consider automated because a script executes it, but that’s not automation. It’s automation in the waterfall world, but it’s not automation in an Agile, DevOp practice.

Yeah, these steps really have to truly be automated so that it’s transparent, there’s reporting, there’s clean metrics, there’s a continuous feedback loop, because that’s the best way to go fast. The best way to go fast in anything you do is control, right? The more control, the more speed. The problem with control, on the ARA side, is it costs too darn much, which is why we decided to do an open-source solution. It’s like developers, in order to achieve this, in order to really achieve this and really move as fast as possible and increase these release cycles, you have to have developers being able to get their hands on a product that will do the deployments without having to babysit a script for every state in the life cycle.

Shimel: Agreed.

Ragan: So we have a ways to go.

Shimel: I agree 100 percent. But I’m gonna tell you—you know, and this, again, it’s not my original thought, but it’s something I’ve heard and I fully agree with, and that is I don’t think it’s the mission of DevOps or CD or ARA, you know, that we’re gonna totally eliminate waterfall. I think there are, you know, situations where waterfall—excuse me—where waterfall may, in fact, be the right solution to the problem. I think—[coughs] excuse me, Tracy—I think there are other areas where some sort of combination of waterfall and Agile, waterfall and DevOps, you know, some continuous kind of stuff, you know—it’s like that—you know, General MacArthur said, “Old soldiers never die; they just fade away,” or something like that. I think old development styles and techniques never die either, so I don’t necessarily believe in throwing out the baby with the bathwater. What do you think about that?

Ragan: I think technology will change that. When you’re talking about monolithic applications that have been around for a while and they have some sort of a cadence that they’ve been going through, where they have developers developing and testers testing and production teams managing the production releases, you’re probably right. It’s gonna be some sort of a water-Scrum-fall or what we’re calling “bimodal” approach.

But, with the introduction of microservices, that is going to change the way—if it’s not a monolithic application, as we move into microservices, even though it solves—microservice solves some problems, it’s going to complicate the landscape of the production environment, which means that the need to have these production operation types and these testing types working hand in hand, on the development team, will be critical. So, as we see microservices become more prevalent, we’re going to see waterfall slowly die.

Shimel: Okay.

Ragan: It’s just the nature of micro-services. Now it becomes—microservices becomes code as well. Everything has become code, which means that the productions teams are not gonna be able to track and manage that level of detail in the production environment. It’s gonna go beyond just a collection of DLLs or a WAR JAR file that’s going out to an end location. It’s gonna complicate matters and it’s gonna change the way we—it’s gonna change waterfall drastically.

Shimel: Yep. And so it’s gonna change it drastically and maybe it does evolve, if you will, but I think that’s what technologies—I think—you know, one of the things I’ve learned over too long, being in this business, is we don’t see revolutions as much as we see evolutions. And then, when we look back over a five-, seven-, 10-year span, it seems like, “Oh, my God, that was revolutionary.” But, from the day to day, it’s rather evolutionary.

Ragan: I would agree. When it comes to—you know, we have—if you look at the macro and the micro, when it comes to the micro level, we have changed—you know, software developer bank doesn’t evolve anymore; it’s revolutionized. And that is due to Agile. What happens is is that, in some of these enterprises, the fear of doing frequent releases has slowed down the adoption of lean practices at the production state. That, we have to fix because there should be a revolution. If an end user needs a fix, it needs to get out there. It shouldn’t evolve over a six-month period.

Now, if we look at the macro, we take a—you know, we soar up a few miles up—when it comes to major shifts in the way the community at large does business, it is a evolution. Everybody—I mean, I was at the Gartner data center show last December, and very few of those enterprises had even completed the adoption of cloud. They still had big, you know, warehouses of servers, so you’re right. From the perspective, I would say, the data center adoption, it does evolve, but, at a micro level, I think that we see a revolution in the way developers want to develop software and are driving software, and that’s where the microservices is gonna change a lot of how we do things. And I think, as more developers push for that, I think it’s gonna happen faster than we think.

Shimel: I don’t—I—so that, along with the evolution versus revolution thing, I think the speed of—you know, this internet time speed warps, you know, the world we live in. It just—I mean, it’s crazy. So it’s no doubt about that one. Tracy, we’re actually—I didn’t realize—we’re kind of over our time, but it’s okay. These things often run over. Let me just quickly bring it back to OpenMake. What are you guys—anything new? Announcements feature-wise? Or what’s happening over there that you may wanna share with our audience?

Ragan: Well, we have our DeployHub product that you can become part of the open-source community and participate in freely-available continuous deployment at deployhub.org. We are also—we’ll be getting a press release out very shortly here, regarding a SAS version of our continuous deployment solution, which it will be both a supported version of the open-source, as well as the pro version which includes release management capabilities, all from a SAS model, so you don’t have to download anything. We can do that because we’re agentless. Makes it real easy to support people in a cloud model.

Shimel: Excellent. Tracy Ragan, CEO of OpenMake Software. Thanks for being our guest on DevOps Chat. Hope to have you on soon—have you on again soon and you can keep us posted.

Ragan: Okay. Thank you, Alan.

Shimel: Thank you. This is Alan Shimel for DevOps.com and DevOps Chat. Have a great day, everyone, and we’ll see you soon on the next chat.

— Alan Shimel