Oleg Skrynnik wrote the book DevOps a business perspective. It’s the core literature for the EXIN DevOps Foundation certification and gives a good overview of DevOps.
Definition DevOps: ‘DevOps is an evolution of the ideas of agile software development and lean manufacturing, applied to the end-to-end value chain in IT, which allows businesses to achieve more with modern information technology due to cultural, organizational and technical changes’
The book is built around 6 chapters. The first chapter explains DevOps in general. Next, we get key facts and challenges of lean production and agile as the foundation for DevOps. Followed by an explanation of the five DevOps principles.in a next chapter DevOps is compared with traditional practices and 10 DevOps practices are explained and ends with the practical application of DevOps.
The evolution of Agile software development methods created the need for a new approach to IT management. Management of IT infrastructure as a code enabled by virtualization and cloud computing provided the opportunity for the same new approach to IT management. This new approach was the inspired emergence of DevOps.
- Reduce time to market (business idea testing, hypothesis evaluation)
- Reduce technical debt (the debt occurs when a programmer chooses a non-optimal way to solve a problem in order to shorten the development time)
- Eliminate fragility (fragile systems first and foremost need stability, they need to be changed as little as possible, and changes should be carefully checked both before and after the intervention)
DevOps is based on five principles:
- Value stream. Creating value in response to a customer’s request
- Deployment pipeline. The most automated transition of changes through all steps of the value stream, starting from the Development is complete’ point, down to ‘Deployment into operations’ (including continuous integration, delivery and deployment)
- Everything should be stored in a version control system: source code, tests, scripts, artifacts, libraries, documentation, configuration files, development tools
- Automated configuration management. Any changes to any environment can be made only by scripts stored in a version control system
- The Definition of Done. Creation of new functionality is done only when the application is running in the production environment and all the assembly, testing and deployment activities are done automatically
Ten DevOps key practices:
- Unusual teams: not a temporary construct, responsible for a small domain, full time, cross-functional, small, versatile professionals, self-organizing, collocated, responsible for the tool in use
- Work visualization: helps to build a pull system, improves visibility of tasks in progress, remaining amount of work, prioritization, reduces the number of hand-offs and helps to identify inefficiencies
- Limit the WIP: helps to build a pull system, improves estimating of the lead time, identification, visibility, evaluation and elimination of constraints, decreases specialists’ work interruptions and work re-scheduling
- Reduce batch size: reduces total amount of work, lead time and number of defects, and improves the rhythm of the flow, the quality of the products
- Mind the operational requirements: the product owner as interested in the fully operational IT system, including both functional and other (or operational) requirements
- Early detection and correction of defects: testers develop tests and the test environments correspondent to the production environment as accurately as possible to support fast detection of defects
- Managed, not controlled improvements and innovations: banning any normal work during the time allocated for improvement, Kaizen Blitz (with a very definite and tangible result), hackathons
- Funding that enables innovations: funding of products rather than projects would be more appropriate, and this means a completely different way of budgeting and resource planning
- Task prioritization based on cost of delay divided by duration
- Continual identification, exploitation and elevation of constraints
The last chapter describes some practical applicability and limitations of DevOps, consequences when using COTS (Commercial Off-The-Shelf), an evolving architecture towards a microservice architecture, DevOps and ITSM, Cargo Cutting (thoughtless copying), start where you are, progress iteratively and use a value stream as the core for DevOps.
Conclusion: If you want to understand what DevOps really means, this is a good book to start your journey and bring it into practice.