Development-Operations of IT systems and software, or ‘DevOps’, has as many definitions as practitioners. Many firms say they are employing ‘DevOps’ when they still operate in silos. Other firms use ‘DevOps’ when they don’t need to, or on projects that have no need of complex iterations and support. Still other firms suggest they are employing ‘Dev-Sec-Ops’ merging security into development and operations and automating securitized deployments.
So what then is DevOps in reality? In the real-world DevOps is essentially the following:
The development, building, deploying, managing and support of code, or IT systems by the same team. No silos, no hand-overs, no confusion. The minimum amount of time before a handover can be accomplished, to a typical ops-team, is when the system or software is completely documented, stabilised and has gone through a cycle of deployment, initial usage, trouble-ticket resolution and quite likely minor patch and code updates.
DevOps means that the team that built the system, supports, maintains and updates it. They own it.
There are 3 components to DevOps:
1 ) Code Building – which should be based on Agile, Scrum and iterations. This includes code documentation, on-going testing and peer reviews, product owner reviews, end-user reviews of Proof of Concepts.
2 ) Code, Software, Application or Component deployments – which should pass through a Dev-QA-Prod iteration. This includes automated testing, manual testing, end user testing, the use of recorded test cases and documentation.
3 ) Support of the deployed code or Application in which the Dev team interacts with users to trouble shoot errors including Application code problems, data errors, source file issues and general problems with the database or integration of systems.
These 3 main areas should be the locus and responsibility of one group. At some point in time, after stability and the resolution of key errors and the implementation of patches; there can be a handoff, and knowledge transfer to a ‘support’ or ‘operations’ team. This is only possible if the following are completed:
-Complete system, code documentation and peer review assessments including conceptual, logical, and E-R diagrams
-Description of code, logical models, queries, look up logic and schemas
-Documentation on databases, source files and query logic
-Code, AMIs and deployment have passed security reviews and are able to withstand external audits and hackers
Too often none of the above are completed, making ‘operations’ impossible. Ops is essentially keeping the system alive, looking after the server resources, monitoring what is running and dealing with front-line support issues. Change requests, feature changes, code upgrades are not done by the Ops team.
In this regard DevOps is certainly a part of Agile, in which iterative development, Proofs of Concept and the use cross-functional teams replace the sorry, decrepit and failed theology called Waterfall. But it is not a replacement for everything. DevOps can be however, a useful addition to many development – ITSM environments.
The above also conforms to the definition of DevOps by The Agile Admin (TAA) website, managed by a team of developers who describe it as “the practice of operations and development engineers participating together, over the entire service lifecycle [of systems], from design through the development process to production support”.
Within DevOps there should be automation. An example is in the area of infrastructure deployment and management where we can use tools such as Splunk or Nagios to deploy monitoring platforms, or Jenkins and Chef to automate the provisioning of code and infrastructure. DevOps thus relies heavily on automation.
In essence the idea of DevOps, and cross-functional Agile teams is heavily based on cultural changes, automation and iteration.
Resources:
Amazon Web Services (AWS), which has DevOps as the core of its system development has a good DevOps guide – here.
===END
