The pipeline, the research and the operating model behind changing software safely and often.
DevOps began as a way to stop development and operations optimising against each other, and it became a body of evidence about what makes delivery fast and stable at the same time. This list is for engineers, delivery leads and product people who have to argue for the investment. It opens with the practices, moves to the research that justifies funding them, and ends with the reliability and organisational material that decides whether those practices survive contact with the rest of the company.
The three ways of flow, feedback and continual learning, turned into concrete practices with a case study attached to each. The broadest single book here and the one to start from if you are shaping a programme of work rather than fixing one pipeline.
Humble and Farley on the deployment pipeline in full, including testing strategy, configuration management, infrastructure and the database changes that stall most teams. Read it when releasing is the thing limiting how quickly you can learn anything.
Four measures of delivery performance and the twenty four capabilities that predict them, with the research method published alongside. This is the evidence to put in front of a sponsor who believes speed and stability trade off against each other.
Theory of Constraints told as a novel about an IT department in trouble, which is the version a sceptical colleague will actually finish. Good for building shared language before you propose any of the practices above.
How Google runs production, including service level objectives, error budgets and the blameless postmortem. The error budget is the mechanism that lets the speed and reliability argument settle itself rather than escalate.
Continuous delivery fails quietly when a hand off is baked into the org chart. Skelton and Pais give you the platform team offered as a service and the interaction modes that remove the queue between teams.
Where the throughput thinking underneath all of this originates, set in a manufacturing plant rather than a data centre. The five focusing steps are the method you apply to a pipeline once you can see the bottleneck.
The governance, budgeting and audit questions that arrive once you deploy several times a day. Useful in regulated environments where the objection to frequent release is compliance rather than engineering.