Since decades, software follows lifecycle models. For it’s implementation and operation, time provided multiple models for addressing occuring challenges. These appear in form of best practices, frameworks and philosophies, such as:
- IT Infrastructure Library (ITIL)
- DevOps which became DevSecOps
This chapter drills into these entities for collaborative work.
DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality.
– Bass, Len; Weber, Ingo; Zhu, Liming.
Rob England defines DevOps within The IT Skeptic as followed:
“DevOps is agile IT (operations) delivery, required to match the cadence of agile IT development. DevOps is a philosophy, not a method, or framework, or body of knowledge, or *shudder* vendor’s tool. DevOps is the philosophy of unifying Development and Operations at the culture, practice, and tool levels, to achieve accelerated and more frequent deployment of changes to Production.
- Culture=behaviour, teamwork, responsibility/accountability, trust/empowerment…
- Practice=policy, roles/RACI, processes/procedures, metrics/reporting, KPIs/improvement…
- Tools=shared skills, toolmaking for each other, common technology platforms…”
I personally agree to this statement, as it combines a philosophy for collaboration between several departments and includes management, developer, tester and administrators while involving customers. If the business users are highly integrated the philosophy is also called BizDevOps, which means Business plus DevOps. However; DevOps is a philosophy and not a method, framework or body of knowledge. Therefore the culture of a company, their processes and lived roles are the key for the success of DevOps. Sometimes DevOps is compared to frameworks such as ITIL, as they have shared disciplines and can integrate into each other. By putting those two next to each other it is possible to find relations:
| DevOps Stream | Frequency | ITIL Roles and Disciplines |
| Code objects checked in, tested and deployed | Daily | Research & Development Management (R&DM) * Service Asset and Configuration Management (SACM) |
| Knowledge updates created and tested for the new functional requirements | Every other day | Service Asset and Configuration Management (SACM) Service Validation and Testing (SV&T) Knowledge Management |
| Formal Operational acceptance tests | 2 times / week | Service Validation and Testing (SV&T) Service Level Management (SLM) Business Relationship Management (BRM) Appl. / Techn. Management |
| Hardware deliveries | As required | Research & Development Management (R&DM) * Techn. Management |
| Early Life Support and Continual Service Improvement | Daily | Continual Service Improvement (CSI) Service Level Management (SLM) Business Relationship Management (BRM) Service Owner |
| * discipline before ITIL 2011 |
Even though there are relations, ITIL is a still a whole framework and provides larger deployables and scope, while DevOps is more agile and flexible. Therefore DevOps deployables are smaller. DevOps could be considered as younger brother of ITIL, which provides a more agile throughput. Within this booklet, I introduce some milestones for DevOps and considerations when aiming for DevOps approaches.