Supercharge Your Development Team with DevOps

DevOps is a powerful tool in custom development. It’s ideal for medium to large software teams working on projects that need speed as well as code quality and security.

Full Transcript Below:

Cody:

… ideas that will help longevity, security, and stability of any software project.

Cris:

How does DevOps interact with your development team?

Cody:

Pull requests and code review process to continuous delivery, continuous integration.

Cris:

How do we, here at Bixly, apply that both internally and then, externally to our clients? 

Cris:

All right, today we get to talk DevOps and we get to talk about the impacts of what it has on your team. So, first off, let’s just start at the top level. How does DevOps interact with your development team? How are they involved? What does that look like?

Cody:

So that’s an interesting topic to approach because DevOps as a concept and as a word and as a buzzword really hasn’t firmly defined itself a lot yet.

Cris:

Okay.

Cody:

The principle consensus of the world of people who work in DevOps is that ultimately, it is a culture. How that ends up being defined within an organization, whether it is a role, a department, a set of procedures depends on wherever you are. But for the most part, DevOps is a culture that brings upon to a software development team ideas that will help longevity, security, and stability of any software project it is applied to.

Cris:

Gotcha. So how do we, here at Bixly, apply that both internally and then, externally to our clients, this more concept of DevOps? How are we actually implementing it on a day-to-day basis in general terms?

Cody:

Yeah, there are a few different principles we go to. For one, there is a lot underneath that package of DevOps, but the ones we typically are applying in a practical sense usually would be everything from simple pull requests and code review process to continuous delivery, continuous integration, to automated deployment pipelines outside of that concept itself and otherwise, automating what we can to help that deployment process be more standardized and more rugged. So it doesn’t have one guy just having to go in and type all the commands and there’s always that risk of a mistake when you put a human in such a job that has to do absolute steps, absolutely repetitively.

Cris:

And correctly.

Cody:

Yeah, and correctly.

Cris:

Ideally.

Cody:

Mm-hmm (affirmative).

Cris:

How does this affect the speed? How does DevOps affect the speed of development? Is it slower? Is it faster? Is it indifferent? How does that affect?

Cody:

There’s many arguments on this topic, actually. Generally, it actually affects DevOps, I guess, in sense of an individual task basis, it will actually typically, make things a little slower.

Cris:

Okay.

Cody:

But the thing about it is that it makes them much more consistent. You won’t be circling back to visit tasks again down the road.

Cris:

Got it.

Cody:

So you say it makes development slightly longer so that the total picture is shorter in the long, long, long term. And that’s one of the benefits of DevOps principally is that it applies more of a regimented viewpoint on how you should go about development. No longer are we doing the 2005 cowboy coding kind of thing. You have a process, a flow, you have peer review in there. In science they have peer review to make sure their documents and theories are correct, that’s what we’re applying within DevOps in a lot of ways too. And then, on top of that, you have automated systems that have been tried and tested that take care of all the things that are after the software engineer is done.

Cris:

Gotcha. I mean, it sounds like, again, we’re taking a little bit more of that time, but overall, we’re getting a better quality product out of it. So, DevOps as a whole, how is this actually helping the code quality and the project security of things?

Cody:

Well, the main thing is it leaves less unchecked.

Cris:

Okay.

Cody:

Part of the DevOps process is a peer-reviewed process, typically. That’s a normally applied part of that whole package and that allows people to have more eyes on the same code instead of just assuming, oh, the project manager checked it. He knows the business side of it works, but what’s going on under the hood. That’s one of the principles here is that we have more than one person looking at the same code and that allows it to be more thoroughly looked at and also, vetted. That helps with security, reliability, all the things you could imagine by just giving more attention to a problem, right?

Cody:

In terms of long-term and stability, speed, and all of that, yeah, each task will take a little longer, but you’ll be visiting them, again, less. There’ll be less regressions, ideally. At least that’s the goal. And because of that, you could say it’s an overall win, both for speed and velocity of the project and security, because there’s more eyes on it. And also, DevOps traditionally is actually an interesting topic, but DevOps is wrapping system administration a lot of the time as well nowadays.

Cris:

Okay.

Cody:

Is it necessarily meant to do that? No, but a lot of the time, much how a full-stack engineer encompasses front end to a backend engineer or backend to a front end engineer, DevOps seems to be wrapping around what system admins do. And part of that is also, raw hardware security, firewalls, VPNs, things of that sort. So that’s a big part of it as well as the actual system security and also, centralizing that configuration as well. That’s a big part of DevOps.

Cris:

A term I’ve heard bouncing around a little bit and I need some explanation on it, so I want to come to you.

Cody:

Sure.

Cris:

Explain the term shift left. What does that mean?

Cody:

So shift left is weird sounding. It’s a buzzword, for sure. But in a project timeline, imagine going left to right.

Cris:

Mm-hmm (affirmative).

Cody:

You have all these things from starting the project codebase itself to writing out features, to deploying it, to testing and security, to vetting final code. And a lot of those last things I just mentioned occur on the right of that timeline near the finish line.

Cris:

Okay.

Cody:

The goal of DevOps is to shift those items left.

Cris:

Oh, okay.

Cody:

So they occur early and more iteratively and they happen the entire project timeline over and over again. That’s the concept of continuous integration and continuous delivery among other things that they can so-called shift left. So, the idea here is that by continuing to do that, if you’re rolling out changes right now and deploying that right now and you’re integrating those changes right now, every single time a feature is done, those little problems that occur won’t be a giant bag problems that happen near the end of the project near deployment. So you have a more consistent flow of velocity, and you don’t end up tripping upon deployment, which is a really common thing that happens on very many projects.

Cody:

I mean, you talk to any software engineer who will tell you about crunch time, and that’s usually when everyone realized everything’s on fire and no one’s taking vacation, everyone’s working their butts off to get things done right at the end of a project usually. That’s to avoid that problem because that takes a huge amount of man-hours, and by shifting left, you have smaller problems you can handle over a longer period of time before they become a larger problem that requires a significant reworking.

Cris:

And I’ve even seen that on some projects that we’ve maybe come in somewhere in the middle and worked on a component piece. But then, for some reason we stepped back and the team kept running with it and they were going to do deployment, and they were going to do some of that final stages. And then, we find six to eight months later, we’re checking back in on the project, “How’d that go?” And they’re like, “Ah, we never really got there,” or, “Oh, we got stuck up on this thing.” And you’re like, “Okay.” And so, how are we ensuring that with our customers, that we’re putting this mindset forward to them as we’re wrapping things up, how are we getting them in this mindset of thinking about shifting left as early as possible?

Cody:

Well, the main thing is we’re looking for projects that honestly need it. When projects are small, a lot of the time the DevOps benefit is more of adding bureaucracy on top of a very small thing. So there is a certain, call it critical mass that is necessary for DevOps to really benefit, usually larger projects, larger teams, or at least long-term projects. So firstly, we’re looking at that. And then, as that comes, we’re offering our assessments to them to let them know, “Hey, there’s this new concept it’s called DevOps. We have a whole brochure about it, it shows all the benefits it’ll help your project with. And we think it’ll really return your ROI on the software.” We recommend that to them. And then we go from there if that makes sense for their project. And ideally, we’d love it to be the case for any project to have it on there because it makes our lives easier as administrators of making sure things are operating smoothly, but we have to be realistic with the goals of every client and we take that into account, but ideally, we try and get it wherever it can fit.

Cris:

That’s good. Well, hopefully, as we unpacked DevOps a little bit and how this benefits the teams, how it connects, and everything, hopefully, some people watching this will have some good takeaways and we’ll be able to help the projects that need it, start to have this concept of shifting processes a little bit to the left and having a much more continuous integration cycle.

Cody:

Absolutely. I don’t disagree.

Alexandra:

Thank you for joining us for this episode of Bixly Tech Tuesday, where Cris and Cody got to talk really about the importance of implementing DevOps and how it can improve your development team overall, and your software project overall, just the huge impact that it can have. If you have any questions, go ahead and leave them in the comment section down below and we’ll get right back to you.

Alexandra:

And don’t forget to check out the description box down below, we have a bunch of helpful links for you guys, including a link to our free custom software guide, as well as a link to our free DevOps guide and a link to our website, bixly.com. There’s a link right at the top of our website that says, “Start My Roadmap,” and that actually gets you a free 60-minute conversation with Cris to talk about your next app idea. Until next time, this has been an episode of Bixly Tech Tuesday.