What do dependency resolution, situational awareness, and superheroes have in common? Meet Chris Corriere, a DevOps/Software Engineer at Autotrader, speaking on creative ways to maximize usage of all of the above. Mark Miller, Community Advocate and senior storyteller at Sonatype caught up with Chris to learn more about what his team is up to.

Chris: I'm Chris Corriere, and I'm a Dev Ops engineer at AutoTrader.

Mark: Can you give us an overview on how you're using Nexus?

Chris: We use Nexus for dependency resolution. Part of that is to insulate our enterprise infrastructure from general third-party dependencies. We're able to filter that down with our internal repo and make sure that our developers are using things that are pre-approved, that we're allowed to track and update. We also use it to move around internal projects that have cross-dependency between applications in-house.

Mark: How are you enforcing pre-approved dependencies?

Chris: They are generally around who has access into Nexus and who is allowed to improve and pull things into Maven Central. But there are ways around that. There are ways to sneak things into builds. If a developer really wants to get something in then, sometimes when you're troubleshooting, you find some of those clever solutions. There's definitely an element of striking balance between that, of making sure they're able to experiment and get the tools in they need to get their job done, but not exposing any liability or risk in the process by pulling something in that's not trusted.

Mark: If somebody isn't using a binary repository, what could you tell them that would get them to use one?

Chris: Consistency within the build environment is one of the main draws to me, that and re-usability of code. I think that doubles-back into situational awareness – depending on how they're measuring their organization, what they're looking for in terms of improvement, and where there's room the optimize. There's probably a lot of interruption in build, a lot of different permutations. I'll say in different solutions, it could be more standardized and more consistent across teams. You can get by without it. But you're probably doing a lot more work for the same end result. Without a repo, there's a lot more drama, a lot more heartache involved.

"Without a repo, there's a lot more drama, a lot more heartache involved."

Mark: I would think that the more developers you had, the more you would actually have a real need for it.

Chris: I would say the most creative solution I've seen is teams get pretty consistent results with using source control and builds at particular revisions. But in that instance you have to have the build to succeed. You have to get through the build, and that's going to take time even if it doesn't break. Your repository is putting everything after that step where it's ready to go. You know it's built. You know it's safe. It didn't get into the reboot. It didn't make it through the filter.

Mark: Have you guys done anything cool with Nexus?

Chris: I wouldn't say anything too out of the ordinary. There's some overlap into how we're leveraging it that looks more like configuration management, which is unconventional. Depending on the project, you're able to check some things from Nexus and how they will stand up (against) a lot of your environmental dependencies outside of just a job application. It can dip into the version of Java you're running, different inch grips, and other things that nest into each other. That gets you to sort of square one to launch a lot of our standard internal apps. Again, back to the situational awareness, given some of the constraints of the teams we were working with, it's something I ran across and it felt a little left handed at first. But when you stop and look at it, they were able to get the ball moved down the field within the constraints that they were given. At the end of the day, it works.

Mark: Are you using any continuous integration, continuous delivery?

Chris: Yeah. I don't think that's a boolean of a value. We've got a lot of it end over life cycles, and we're running continuous builds. We've got some in-house tooling around that, and we also run Jenkins. There's always room to accelerate, improve, and optimize it. We're moving to more continuous delivery. We really want to start getting things out closer to prod. But you always start with the left side and move out from there, and try to debate quality from step one where there's lower risk. I've seen AutoTrader make a lot of good strides in that over the past couple years.

"There's always room to accelerate, improve, and optimize it. "

Mark: Final question, if you were going to be a superhero, would it be in dev, ops, or sec?

Chris: I'm going to go with security because I think there's some development and operations involved in that if you're doing it right. I don't think you should be blue team or red team. I think team purple is where it's at. You really got to come at it from both ways to get the job done today.

"I don't think you should be blue team or red team...purple is where it's at. You really got to come at it from both ways to get the job done today"

Mark: Excellent. Thank you, Chris.

Chris: My pleasure.

If you loved this interview and are looking for more great stuff on DevOps, I invite you to download the "Continuous Delivery and DevOps Reference Architectures," highlighting real world practices from organizations like PayPal, IBM, Adobe, USPTO, and many more.

Listen to the Interview Here.

• Mobile Internet Remodelling Part I – Fantasy or Family Expansion
• Breaking Constraints and Leaping Forward: Texas Instruments' New Multistandard Wireless Base Station SoC Drives Performance and Efficiency to Record Levels
• Millions of Consumers Are Taking Control Over Risk From Identity Theft With a Free Online Secure Payment Service From Orbiscom