Like most management ideologies, DevOps is stuck in its ways and resistant to change. While traditional strategies might have worked perfectly well in the past, today’s software development landscape is radically different from where it was twenty years ago, and we desperately need new management paradigms.
The problem with DevOps is mostly one of culture. We now have the tools to make the process of developing and testing software more efficient and accurate, and yet many IT departments and software development organizations refuse to make changes. Frankly, it’s frustrating.
Old-Fashioned Deployment Notions
It used to be the case that DevOps would never deploy on a Friday for fear that bugs and issues would arise in the following days, wrecking the weekend for engineers. But this was more a symptom of problems in the past that had to do with software development. People just didn’t have the tools to iron out the bugs before the product launched. The only way to test was to thrust it upon customers and then see what issues turned up.
But with today’s DevOps tools, that’s no longer necessary. Developers don’t have to plan for a couple of days of pandemonium after releasing a piece of software: the big stuff should have already been dealt with.
Notice the word “should” in that last sentence. Developers should deal with the big issues, but more often than not, they don’t. Businesses are letting themselves down. Not only do they lose out on the flexibility of rolling out on a Friday, but they also harm the customer experience. Clients don’t want to be testers: they want to be consumers.
Lack Of Automation
When it comes to DevOps, there’s also a shocking lack of automation. Software companies have developed tools that allow programmers to test builds of different versions of software across hundreds of virtualized machines, automating the collecting and storing of data. But few companies use these platforms, despite the obvious efficiency benefits. It’s a tragedy.
What’s driving this culture is the acceptance of cherished fallacies. People in the industry have a particular set of beliefs about how the sector works, and tend to accept them without challenging the status quo. Also, many people at the head of DevOps departments are incredibly risk-averse. Managers and leaders of departments don’t want to experiment with new models because they have already spent years refining their development pipelines. It seems too risky to rock the boat with a radically new system.
How To Fix The Broken Culture
Many people in the industry now openly admit that the DevOps culture is broken. But, unfortunately, they don’t yet see a way of fixing it. The good news is that there are a set of best practices out there which high-efficiency companies are using to speed the process, reduce workload, and prevent weekends from being ruined by product launches.
Check out some of the ways that companies can fix their broken DevOps cultures.
Build A Testing System
Many managers seem to think that testing code is just about testing software. That’s like saying that cyber security best practices only involve installing anti-virus. Unfortunately, there’s a lot more to it than that. An active cyber security effort includes things like BYOD policies, managing private networks, and setting up SIEM software. The same goes for testing code. It’s not just about testing software, but also about testing the entire software development system itself. Testing is great, but it’s only one part of the DevOps pipeline. There are many more aspects that need consideration.
Treat Code As An Asset
Many companies treat their code as a liability: something that has the potential to lose them money. Software should, however, add to the capital stock of the firm. It’s a kind of store of intellectual value that should, ideally, have lasting value beyond the cost of creating or replacing it.
DevOps Should Be Auditable
If you don’t know how your firm got to the position that it’s in today, then you can’t retrace your steps to figure out where you may have gone wrong. Good DevOps tools, however, allow you to create an audit trail, allowing you to see what software, hardware, and process changes you’ve made and when. Without that information, you’ll struggle to get to the bottom of recurring issues.
DevOps Should Be Automated
Manually performing DevOps tasks is as much a cultural problem as it is an efficiency problem. All people working on code should be aware of shortcuts to the end product. Without automation, you risk boredom and delays.