The DevOps trap, we should all embrace DevOps.Published on Mar 06, 2015
It all starts with the undeniable need and benefits of bringing the different practices and areas of software development together. Agile practices allow us to move faster and adapt to change.
XP practices promote code quality and better (or just more reliable) products for the end users.
The idea of cross-functional teams help us to identify problems in our approach to solve issues and pinpoint bad architectural decisions.
DevOps is one of the newest practices on the Agile arsenal. In reality is not that new, but we have been hearing about it more and more in the last three to four years and now, even the enterprise is starting to notice.
According to Wikipedia DevOps is:
DevOps (a portmanteau of "development" and "operations") is a concept dealing, among other things with software development, operations and services. It emphasizes communication, collaboration and integration between software developers and information technology (IT) operations personnel. DevOps is a response to the interdependence of software development and IT operations.
That is a definition that I can agree with.
Notice that there are no mentions in the "wikipedia article":http://en.wikipedia.org/wiki/DevOps to "developers" doing "operations". That is not a requisite of DevOps.
It's all about communication and collaboration. In time this usually means that some or all the developers in the team will have access to and help with whatever scripts, recipes, modules or method of deployment and configuration is used.
The focus is on transparency and predictability. Automation and the introduction of better management tools to reduce the amount of manual, repetitive and (let's face it) boring work is a big focus of the practice.
This collaboration will naturally bring some of the developers more interested with the operations, network and hardware side of things into a tighter collaboration with the "operations team". This results in a "good" vicious circle and big gains for the company that adopt the practice.
As with all social practices, the trap is trying to force DevOps into people. This can take many forms but the one that I keep seeing popping around is the idea of having developers double up as operation people and thus not having a proper operations team.
Don't get me wrong. I think that the goal should be not having "teams" and having polyskills people that can perform in different areas as needed or as they (as individuals) want to grow into.
This is the same trap we got into with other Agile practices, like "architecture" or much rather "no architecture". Since we don't have glorify architects in an agile team, sometimes this is portrayed as "we don't need no stinking architecture".
We should all embrace DevOps
We should certainly embrace DevOps and QaDev and DevProd and whatever new practice comes along that help us remove the barriers for collaboration. That encourage open and high bandwidth communication between all the members of the team and between "chickens and pigs":http://en.wikipedia.org/wiki/The_Chicken_and_the_Pig
Specially, between chikens and pigs!
But we should also recognize the need for strong operation people as part of the team tacking charge and helping the team move forward faster and safer. Enabling many deployments a day and achieving the somehow elusive holly grail of Continuous Delivery.