> For the complete documentation index, see [llms.txt](https://prof.aheil.de/devops/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://prof.aheil.de/devops/devops-historie.md).

# DevOps Historie

## Lernziele

* Den Ursprung der DevOps Bewegung **kennen lernen** und die »Konvergenz von DevOps« **verstehen**.

## Ursprung

DevOps wurde nicht erfunden, sondern basiert auf

* Lean,
* der Theory of Constraints,
* dem Toyota Production System,
* dem Resilience Engineering,
* unternehmensweitem Lernen,
* einer ausgeprägten Sicherheitskultur,
* zahlreichen menschlichen Aspekten und
* agilen Methoden.

**Lean Bewegung**

* In den 1980er im Toyota Productive System begründet \[1]
  * Value Stream Mapping
  * Kanban-Boards
  * Total Productive Maintenace
  * Just-in-Time-Konzept
  * Jidoka und Kaizen (jap.) als zentrale Philosophien
* Grundsätze
  * Durchlaufzeiten als bestes Maß für Kunden- und Mitarbeiterzufriedenheit
  * Kleine Arbeitseinheiten die beste Voraussetzung für kurze Durchlaufzeiten

\[1] Toyota Motor Corporation , Toyota Production System, <https://global.toyota/en/company/vision-and-philosophy/production-system/>

**Agile Manifest**

* 2001 begründet \[2]
  * Schlanker Satz von Werten und Prinzipien
  * Regelmäßige Auslieferungen von Software als Inkremente
  * Kleine bzw. kurze Zeiträume
  * Kleine motivierte Teams
  * Vertrauensbasiertes Management Modell
* Starker Zusammenhang von DevOps und der Agile Community

\[2] K. Beck, et al, Agile Manifest, <https://agilemanifesto.org/>

**Agile Infrastructure und Velocity**

* 2008 – Patrick Deboid und Andrew Shafer unterhielten sich über die Anwendung agiler Prinzipien auf Infrastruktur \[3]
* 2009 – John Allspaw und Paul Hammond auf O‘Reilly‘s Velocity Konferenz stellen vor, wie Entwicklung (Dev) und Betrieb (Ops) gemeinsame Ziele verfolgt hatten \[4], \[5]

\[3] P. Debois, Agile Infrastructure and Operations: How Infra-gile are You?, Agile 2008 Conference, Toronto, ON, 2008, pp. 202-207, doi: 10.1109/Agile.2008.42. \[4] J. Allspaw, 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr, <https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr/> \[5] 10 Deploys Per Day Dev and Ops Cooperation at Flickr, <https://youtu.be/c6tWX48tmAo>

\
**Continuous-Delivery-Bewegung**

* Jez Humble und David Farley: Continuous Delivery aus Continuous Build, Test und Integration führten zur Deployment Pipeline \[6]
* Code und Infrastruktur immer in einem auslieferbaren Zustand
* Eingecheckter Code kann immer sicher in Produktivumgebung eingespielt werden

**Toyota Kata**

* Mike Rother zeigte, dass die Lean Bewegung den Verbesserungsprozess bisher nicht beachtet
  * Tägliche und ständige Verbesserungen
* Grund für den Erfolg von Toyota aufgrund eines Zyklus von
  * Definieren gewünschter Zustände
  * Setzen von wöchentlichen Zielen
  * Feedback und ständiger Verbesserung der täglichen Arbeit

**Zusammenfassung**

* DevOps ist nicht „einfach so entstanden“ und wurde nicht „erfunden“
* Zahlreiche Bewegungen „konvergierten“ in eine ähnliche Richtung
* Die Entwicklung von DevOps hat sich über Jahre hingezogen

\
\
\
\
\
\ <br>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://prof.aheil.de/devops/devops-historie.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.