Improving software quality means mixing DevOps with Agile

DevOps will always be about people first

What DevOps really comes down to is breaking down the barriers between the development people and the operations people.

Dan Cornelly, Denim Group CTO

This seems to be a common point of agreement. Denim Group's CTO, Dan Cornell, spoke of the need for each team member to broaden their perspective. "What DevOps really comes down to is breaking down the barriers between the development people and the operations people. For example, it's important for the developers to understand, 'I'm a developer and I have certain concerns. You're in operations and your concerns may be different from mine. But if I understand more about what it's like to do your job, if I understand more about what tools and facilities you need, I can help you out by building some of those things in.'"

This focus on human needs is why DevOps can be so difficult to define. There isn't one right way to do things, because every team and every team member is different. Clayton Coleman, lead engineer of OpenShift by Red Hat, acknowledged that a number of approaches coalesce to create a DevOps environment. "Bringing people together is really the heart of DevOps, and there are many different ways to do that. There are processes, technology and organizational changes." Processes certainly come into play when looking at the day-to-day functionality of a DevOps team.

Changing processes leads to improving software quality

One of the changes that seem to go hand in hand with DevOps is a shift toward continuous integration. The speed at which software is developed and deployed is one factor that has made merging development and operations less of a luxury and more of a necessity. Jeremy Eder, principle software engineer at Red Hat, revealed what his performance team is doing in this space. "We've really embraced continuous integration from a performance perspective. That means writing tests that can gate releases for performance and scale regression, not just functional and feature tests. Those are things we're doing internally that excite me in terms of automation because they allow us to have a lot more confidence in software that gets shipped, which is the purpose of CI in the first place."

Assurance of higher quality for each iteration of software is certainly an outcome that makes everyone on the team breathe easier. Neither development nor operations wants to deal with the fallout from nasty surprises.

Newer platforms may ease the pain of adopting DevOps

Of course, that doesn't mean everyone on the team will automatically get on board with the notion of DevOps. Coleman revealed one way that Red Hat is working to enable the shift for everyone via the OpenShift platform. "We're trying to make things as painless as possible for developers to get started in building Web or mobile app or microservice architecture -- having the tools that let you press a button and deploy real software in an enterprise or public cloud environment. On the flip side, we're making it really simple for operations to roll out changes to hundreds or thousands of applications simultaneously. It's about taking something that was hard before and making it trivially easy."

The logic is evident: When people are relieved of the stress and frustration caused by difficult and time-consuming aspects of their jobs, they play well with others. Making DevOps the pain-free option for everyone involved encourages adoption of new practices that can lead to improving software quality.

Will DevOpSec be next?

It seems natural to merge DevOps into a single organism, but the synergy shouldn't stop there. Cornell directed attention toward an often overlooked part of the ecosystem. "I would argue that you need to break down the barriers that both Dev and Ops have with the security people. It's very important for security teams to understand more about how software gets developed because all three of these groups have different concerns and different ways that they get rewarded. It's really only when these three groups are working together that the cost of everyone's job going smoothly collectively goes down."

Right now, that's not happening. "Too many teams aren't thinking about security at all during the development lifecycle. For example, a lot of teams need to start looking at how they do input validation and how they do output encoding as information passes between systems. They really need to take to heart the concepts of authentication and authorization so that they can start addressing those two security concerns and rolling them into the application as they're developing it. That's really going to get them a long way toward avoiding introducing serious security issues."

Cornell pointed out that, while modern frameworks often deal with validation as a matter of course, encoding is the control that must absolutely be implemented to avoid certain classes of vulnerabilities. This is especially true in the mobile development field where new security threats are being uncovered all the time. One thing is certain: DevOps won't be the end of the road. It will open up even greater prospects for collaboration, continuous improvement and improving software quality throughout the software cycle.

What strategies is your organization using to make DevOps work? Let us know.