The demand for code deployments is on a constant incline; developers owning their own code, from creation to production, is mandatory. By no longer separating developers from operations, organizations can innovate with confidence and resiliency in mind. We have many customers successfully living the DevOps philosophy, where incident management sucks a whole lot less. One success story is the online shipping, transport, and freight marketplace company, uShip.
Raleigh Schickel, DevOps manager at uShip, says his team isn’t setting any trends. They aren’t doing anything bigger, fancier companies aren’t doing.
But this isn’t true. Raleigh is building one of the most advanced versions of an incident management process. This is extremely important at uShip where people can deploy anytime they want, because the more you deploy, the more you innovate, and the more stuff breaks.
At its core, uShip’s incident management process considers operations a democratic function. Everyone contributes their expertise to solving the problems closest to them. With the proliferation of microservices, this attitude is both philosophical and practical.
“Here is how I look at it,” says Raleigh. “If you are going to develop microservices, you are injecting far more complexity into your systems. If you expect your Ops people to know all of the intricacies of the microservices, then in reality, many operations people also need to be developers.”
Decentralized systems knowledge creates a conundrum. “If you have 20 microservices and five go down, how many Ops people do you need to put that fire out if your devs aren’t taking responsibility? It’s a choice,” says Raleigh.
When everyone is empowered to deploy anytime, then nobody has all the information about who is doing what to the codebase. Before uShip’s developers took part in on-call, problems with a quick fix would lag. Rather than watching the systems and rolling back a deployment if necessary, someone in operations would have to guess what went wrong without supportive context or information. With the culture shift that Raleigh helped instigate, people aren’t guessing what happened today.
Raleigh explains this shift. He says, “As a developer, I want to know how my code is performing. I don’t want to be responsible for introducing defects and I certainly don’t want someone else to catch them. We’re reversing the paradigm. I want the devs to tell me that they broke something.”
The full uShip case study describes how the company brought back this all-hands-on-deck culture that proliferated early on, and inevitably lagged during an early period of high growth. The culture of code ownership is back. Read the write-up to hear how it happened.