DevOps brings Development and Operations together with the sheer objective of ensuring quality and enabling faster time to market. However, what happens to QA in this scenario? How does the Testing team fit in? Let's ponder on this further and understand the role of QA and Testing in the DevOps world ...
DevOps leaders are engaged in an all-out effort to "shift left" so they can deliver better software faster and at lower cost. Much of this effort entails fairly dramatic re-engineering of the dev/test process. And, if we're honest, much of it also entails a management culture of extreme demands on the development and test team.
But while we're building our state-of-the-art DevOps toolchains and pumping our people full of Hint Kick, there may be another smart way to shift even further left:
Re-think build distribution infrastructure.
The Physics of Process
Process and management culture can't overcome the laws of physics. And if you have to share massive builds or artifacts across multiple dev and test teams worldwide—as financial institutions, game developers, and other organizations often do — physics definitely gets in your way.
That's because you have to keep shipping these massive files over the network to those multiple locations again and again as you cycle through your dev/test processes. On the typical enterprise network, that code distribution can take hours.
Consider a 10GB build distributed to five different locations from your primary facility over a 10Mbps MPLS connection. You don't have to be a network expert to do the math. If a couple of your remote locations have 5Mbps connections, it takes them 5 hours to get each build. If three of those locations have 2Mbps connections (as is likely the case in Asia), code distribution takes 12.5 hours.
So the physics of code distribution costs you a day. Repeatedly.
The irony is that the more agile and iterative you try to get in this scenario, the more you pay this distribution time-tax. Conventional code distribution is therefore a primary enemy of the Agile/DevOps "shift left" imperative.
The Shift-Enabling Alternative
The alternative to conventional ship-it-over-the-network-and-wait-a-day approach to build distribution is a hub-and-spoke model that allows you to lets you maintain a "gold copy" of your current codebase(s) in the cloud — while providing all your remote locations with their own local copies that get continuously and automatically updated with any changes as they occur.
This model eliminates network-related bottlenecks while allowing your geographically dispersed teams to collaborate without tripping over each other's work.
The result: You can shift left much more aggressively, without the constant counter-productive impediment of a network that can't deliver your builds fast enough to your entire team.
Of course, if you're leading the shift-left efforts at your company, you probably don't own your company's IT infrastructure. So you'll have to make your case to whoever does.
But it's a worthwhile effort. Hub-and-spoke code distribution gives software-intensive businesses competitive advantage by dramatically accelerating time-to-market for digital deliverables—while ensuring that test/QA rigor doesn't unnecessarily delay that delivery. It also saves infrastructure owners lots of money in storage, bandwidth costs and network acceleration hardware.
So if you want to shift left — but keep running into a chronic network bottleneck — have that conversation today. It'll be a win-win for your business and your budget!
Barry Phillips is CMO of Panzura.