New buzz phrases in information technology come and go. DevOps as a portmanteau of ‘developer’ and ‘operations’ seems to have come to stay so far.
While formal definitions of DevOps are somewhat thin on the ground, we can reasonably define this term to describe the interrelationship between programmers and IT operations staff such as systems administrators, database administrators and others within an ‘Agile’ practice methodology.
Within DevOps, programmers are programmers.
If some programmers are higher level project focused developers bordering on being architects, then they are still programmers.
Equally, within DevOps, operations staff are operations staff. This means that sysadmins are right in there with all the other “sub-disciplines” of operations.
Elegant, rather beautiful programming
Distilled then, DevOps embraces the (arguably rather beautiful) interdependence between both sides of the development shop fence and stresses communication, collaboration and integration, in an elegant manner.
Senior VP of marketing at DevOps and “orchestrated IT” company Serena Software David Hurwitz suggests that in the real world, DevOps situations will mean two teams having to overcome the issues that they face, based on different goals.
• Operations want stable systems and no problems for users.
Both sides want what is best for the user and for the business as a whole, but there is a real ‘tortoise and hare’ quality to DevOps that can’t be underestimated. From an internal politics side, getting over the problem involves keeping that higher business requirement in mind, and not taking things personally.
Serena’s Hurwitz writes as follows:
“From a practical perspective, release management is the biggest pain point within DevOps – actually managing how the software is pushed out into production involves both Dev and Ops working together… and the result has to be a clean deployment so that the end-user gets the service they want without any visible delay.”
“Traditionally, getting software out to production can be either the responsibility of operations, or of the development team. IT operations teams will have established and trusted deployment strategies in place that minimise downtime and ensure stability at the expense of agility and speed of response.”
Development-driven release management
“Development-driven release management goes the other way and looks at how deployment can be carried out as often and easily as possible. However, these deployments aren’t necessarily into production. For instance, dev-driven releases are most advantageous earlier in the lifecycle, including for acceptance testing, performance testing and integration testing purposes.”
“Some development shops are also embracing dev-driven releases directly into production, though this is primarily in dot.coms where the quality and auditability standards are lower than in classical industries such as financial services, government, health care and other sectors where critical transactions are enabled.”
“From a process standpoint, continuous delivery has two big requirements: first, the process itself has to be solid beyond development. This means that it has to be as solid as any process that a traditional IT operations team might put into place. Secondly, it puts the emphasis on the release process to be automated and auditable.”
“For companies that want to take this developer-driven approach, there has to be an understanding of the changes required in getting to continuous delivery and decision taken about how far to extend the developer-driven process into the delivery lifecycle.”
“Even where continuous delivery remains limited to pre-production stages, the benefit of going down this route is that IT as a whole can be more nimble in responding to a changing market, whether this is launching new services or expanding available functionality. With a lot more businesses looking at how to expand the ethos of agile from development into their wider organisation, this is a great opportunity to show the rest of the world how things can and should be done.”