Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| edv:devops:start [15 50 2025 19 : 50] – angelegt - Externe Bearbeitung 127.0.0.1 | edv:devops:start [29 17 2026 07 : 17] (aktuell) – André Reichert-Creutz | ||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| - | {{ : | + | ====== |
| - | Was ist DevOps: Bei DevOps handelt es sich um eine Kultur der Zusammenarbeit, | + | |
| - | ===== Das DIKW Modell ===== | + | // |
| - | Das DIKW-Modell hilft uns dazwischen zu unterscheiden, ob Daten/Information oder Wissen/Weisheit (also data/ | + | |
| - | {{ edv: | + | |
| - | |Data|Ungeordnet, | + | |
| - | |Informarion|Wer, | + | |
| - | |Knowledge (Wissen)|Informationen die zu einer Erkenntnis führen = Ergebnis| | + | |
| - | |Wisdom (Weisheit)|von individuellen Erlebnissen, | + | |
| - | ===== Was sind die Unterschiede zwischen CI, CD und CD? ===== | + | <typo fs:90%; lh: |
| - | === Continuous Integration === | + | DevOps ist keine Software, |
| - | Entwickler, die mit Continuous Integration arbeiten, mergen ihre Änderungen so oft wie möglich zurück in den Haupt-Branch. Zur Validierung der vom Entwickler vorgenommenen Änderungen wird ein Build erstellt, der dann automatische Tests durchläuft. Auf diese Weise lassen sich die Integrationsprobleme vermeiden, die möglicherweise auftreten, wenn die Entwickler | + | </ |
| - | Bei der Continuous Integration wird großer Wert auf die Testautomatisierung gelegt, um die Anwendung auf Fehlerfreiheit zu überprüfen, | + | ===== Für wen ist das gedacht ===== |
| - | === Continuous Delivery === | + | ^ Zielgruppe ^ Vorkenntnisse ^ |
| - | Continuous Delivery ist eine Erweiterung der Continuous Integration, | + | | Auszubildende Fachinformatik (Systemintegration und Anwendungsentwicklung) | Linux-Kommandozeile, |
| + | | Umschüler | ||
| + | | Administratoren, | ||
| - | Dies bedeutet, dass du zusätzlich zu automatisierten Tests über einen automatisierten Release-Prozess verfügst und deine Anwendung jederzeit mit einem Klick auf eine Schaltfläche bereitstellen kannst. | + | Programmierkenntnisse sind hilfreich, aber keine Voraussetzung. Wer ein Shell-Skript lesen kann, kommt durch. |
| - | Theoretisch kannst du mit Continuous Delivery entscheiden, | + | ===== Wie diese Unterlage aufgebaut ist ===== |
| - | === Continuous Deployment === | + | Jedes Kapitel folgt demselben Muster: |
| - | Continuous Deployment geht noch einen Schritt weiter als Continuous Delivery. Bei dieser Methode wird jede Änderung, die sämtliche Stationen der Produktionspipeline durchlaufen hat, für die Kunden freigegeben. Dieser Prozess erfolgt vollautomatisch. Nur wenn ein Test fehlschlägt, | + | |
| - | Continuous Deployment ist eine hervorragende Möglichkeit, | + | * **Lernziel** — was du danach |
| + | * **Theorie** — knapp gehalten, nur so viel wie nötig | ||
| + | * **Praxis** — ein Lab zum Mitmachen | ||
| + | * **Anti-Pattern** — was in der Praxis regelmäßig schiefgeht | ||
| + | * **Reflexionsfrage** — bezogen auf deinen eigenen Betrieb | ||
| - | ==== Wie stehen die Verfahren miteinander in Beziehung? ==== | + | Die Kapitel bauen aufeinander auf. Wer quer einsteigt, sollte zumindest Teil A gelesen haben. |
| - | Einfach formuliert ist Continuous Integration ein Bestandteil von Continuous Delivery und Continuous Deployment. Continuous Deployment entspricht Continuous Delivery – abgesehen von den automatisch erfolgenden Releases. | + | |
| + | ===== Das durchgehende Fallbeispiel ===== | ||
| - | ==== Vorteile von Microservices ==== | + | Durch alle Kapitel begleitet uns dieselbe Anwendung: **KFZ-Rechner**, ein kleiner Webdienst, der eine Versicherungsprämie berechnet. Zu Beginn liegt er als Ordner |
| - | Microservices haben nicht nur einen Einfluss auf die technologische Basis des Projektes, sondern auch auf die Organisation | + | |
| - | ==== Was ist Shift-Left Testing ==== | + | <typo fs:90%; lh:150%> |
| - | === Wasserfall-Modell === | + | Jedes Kapitel fügt genau ein Stück hinzu. Das ist Absicht: DevOps entsteht nicht durch eine große Umstellung, sondern durch viele kleine. |
| - | Software-Entwicklung läuft traditionell nach dem sogenannten Wasserfall-Modell ab. Nacheinander werden die folgenden Phasen „von oben nach unten“ bzw. auf einem Zeitstrahl von links nach rechts abgearbeitet: | + | </ |
| - | - Definition der Anforderungen | + | ===== Lernpfad ===== |
| - | - Entwicklung des Designs | + | |
| - | - Coding | + | |
| - | - Tests | + | |
| - | - Veröffentlichung | + | |
| - | === Die Linksverschiebung | + | ==== Teil A — Warum überhaupt ==== |
| - | Beim Shift Left Testing wird der Wasserfall aufgelöst. Die Reihenfolge ohne Tests sieht jetzt so aus: Anforderungen - Design - Coding - Veröffentlichung. Das Testen wird auf dem Zeitstrahl möglichst weit nach links geschoben und mehrfach durchgeführt. | + | |
| - | ==== DMAIC-Zyklus ==== | + | * [[edv:devops:01_warum_devops|01 Warum DevOps]] — Ausgangslage, |
| - | {{ edv:devops:dmaic-zyklus-uebersicht1.png? | + | * [[edv:devops: |
| - | Definition: Das Akronym DMAIC steht für den Kernprozess des Qualitätsmanagement-Ansatzes Six Sigma und beschreibt dessen Phasen |Define (Definieren)|Measure (Messen)|Analyse (Analysieren)|Improve (Verbessern)|Control (Steuern)| | + | |
| - | ===Define – Definieren=== | + | ==== Teil B — Wie man arbeitet ==== |
| - | Was ist das Problem? | + | |
| - | In dieser Phase wird der Ist-Zustand dokumentiert und definiert, wer die Kundschaft (im weitesten Sinn) des Prozesses ist und welche Kundenbedarfe er erfüllen soll. Auf dieser Basis werden dann die Leistungsmerkmale des Prozesses definiert, die kritisch für die Erfüllung der Kundenerwartungen sind. Zudem werden Projektparameter wie Umfang, Grenzen und Zeiträume festgelegt. | + | |
| - | ===Measure – Messen=== | + | * [[edv: |
| - | Wie lässt sich die Auswirkung messen?\\ | + | * [[edv: |
| - | Daten, Zahlen | + | |
| - | ===Analyse – Analysieren=== | + | ==== Teil C — Wie man ausliefert ==== |
| - | Welche Ursachen hat das Problem? | + | |
| - | Ziel der Analysephase ist, die Ursache-Wirkungs-Beziehungen zwischen In- und Outputs nicht nur qualitativ, sondern möglichst auch quantitativ darzustellen, | + | |
| - | ===Improve – Verbessern=== | + | * [[edv: |
| - | Wie lässt sich das Problem eliminieren? | + | * [[edv: |
| - | In der Verbesserungsphase sollen Lösungsmöglichkeiten für die in der Analysephase identifizierten und ausgewählten Probleme gefunden werden. Dies kann durch Kreativitätstechniken (wie Brainstorming oder Brainwriting, Mindmapping, Morphologischer Kasten) unterstützt werden. Die möglichen Lösungen werden anhand von Normen (gesetzliche Auflagen, Verordnungen, | + | * [[edv: |
| + | * [[edv: | ||
| - | ===Control – Steuern=== | + | ==== Teil D — Wie man betreibt ==== |
| - | Die letzte Phase dient der Verankerung der erreichten Verbesserungen und neuen Verfahren im Alltagsbetrieb durch Standardisierung und Dokumentation. Der Prozess bzw. die Wirkung der Maßnahmen wird mit den entwickelten Messsystemen kontinuierlich überwacht, um bei Abweichungen vom definierten Ziel geeignete Korrekturmaßnahmen einleiten zu können. Die Überprüfung der Zielrerreichung erfolgt durch das Controlling. | + | |
| + | * [[edv: | ||
| + | * [[edv: | ||
| + | * [[edv: | ||
| + | * [[edv: | ||
| + | * [[edv: | ||
| - | ====Fazit==== | + | ==== Teil E — Wie man absichert |
| - | Der Vorteil des DMAIC-Prozesses als Kern von Six Sigma liegt darin, dass er ein weites Spektrum an Möglichkeiten und Werkzeugen im Bereich der Projektmanagementtechnik eröffnet. Von großem Wert ist das Schaffen eines konzeptionellen Rahmens im Unternehmen, | + | |
| - | * auf Markt- und Strategieveränderungen kann schnell und konsequent reagiert werden. | + | |
| - | * die konsequente Datenbasierung und die Prozessorientierung werden gefördert. | + | |
| - | * Fehler werden reduziert und Doppelarbeit wird vermieden. | + | |
| - | * die Kundenzufriedenheit wird durch Einbindung der Kundenbedürfnisse erhöht. | + | |
| - | * die Profitabilität sowie der Umsatz eines Unternehmens werden gesteigert. | + | |
| - | * durch Einbindung der Zulieferer wird ein verbessertes Lieferantenmanagement möglich. | + | |
| - | ===== C.A.L.M.S und die drei Wege ===== | + | * [[edv:devops:14_devsecops|14 DevSecOps]] — SAST, DAST, Secrets, Lieferkette |
| - | CALMS ist ein konzeptioneller Rahmen für die Integration von Entwicklungs- und IT-Betriebsteams (DevOps) innerhalb eines Unternehmens. Das Akronym steht für | + | |
| - | |Culture (Kultur)|Automation (Automatisierung)|Lean (Schlank)|Measurement (Messung)|Sharing (Austausch)| | + | |
| - | | {{ edv:devops:calms.jpeg? | + | |
| - | **Culture** umfasst die unternehmensweit geltenden Werte, Überzeugungen und Haltungen, die das Handeln und Umfeld von Unternehmen charakterisieren und Entwicklung, | + | ==== Teil F — Wie man misst ==== |
| - | **Automation** bezieht sich auf die Überzeugung, dass alles, was effektiv automatisiert werden kann, auch automatisiert werden sollte. Das Ziel dabei ist, Mitarbeiter von sich wiederholenden Aufgaben zu befreien, Fehler zu reduzieren | + | |
| + | * [[edv: | ||
| - | **Lean** bedeutet, Überschuss zu reduzieren und trotzdem die gewünschten Ergebnisse zu erzielen. Das bedeutet beispielsweise, | + | ==== Teil G — Wie man es im regulierten Umfeld macht ==== |
| - | **Measurement** bezieht sich darauf, für alles Daten zu sammeln | + | |
| - | **Sharing** bezieht sich auf die Notwendigkeit einer laufenden Kommunikation und Abstimmung zwischen Entwicklung und Betrieb. Dabei sollten nicht nur Ergebnisse und Daten ausgetauscht werden, sondern auch Analysen und Ideen. | + | ==== Nachschlagen ==== |
| - | ==== Das Drei Wege Modell ==== | + | * [[edv:devops: |
| - | === Der Erste Weg: Durchfluss === | + | * [[edv: |
| - | Der Erste Weg beschäftigt sich damit, | + | |
| - | läuft | + | |
| - | Team zum anderen. Das heißt zu identifizieren, | + | |
| - | fließen, warum sie fließen und was mit ihnen danach passiert.\\ | + | |
| - | Beim Durchfluss werden vorher besprochene Beschränkungen identifiziert – d.h. zu verstehen, wo sich die Engpässe | + | |
| - | befinden und wo die Produktion am langsamsten ist, damit man danach die größte Wirkung priorisieren kann. | + | |
| - | Nur wenn man versteht, wie Arbeit fließt, kann man die Hindernisse, | + | |
| - | identifizieren und die Mauer eliminieren. | + | |
| - | ===Der Zweite Weg: Feedback=== | + | ===== Zeitbedarf ===== |
| - | Der Zweite Weg beschreibt die Prinzipien, die gegenseitiges und ständiges Feedback von rechts nach links bei allen Phasen des Wertstroms ermöglichen. In der IT findet Arbeit in komplexen Systemen statt. Das Risiko von katastrophalen Störungen oder Folgen ist sehr hoch. Eng verknüpfte Komponenten sind häufig stark vernetzt, und diese Variabilität und Komplexität heißt, dass nicht immer die gleichen Ergebnisse entstehen, wenn eine Sache zweimal gemacht wird. Deswegen werden Sicherheit, Zuverlässigkeit und Stabilität sehr wichtig \\ | + | |
| - | * Systems Thinking wird ausschlaggebend. | + | |
| - | * Feedbackschleifen helfen sicherere, resilientere Arbeitssysteme zu entwickeln, weil sie mehr Möglichkeiten bieten, um Fehler zu entdecken und zu korrigieren. | + | |
| - | ===Der Dritte Weg: Kontinuierliches Experimentieren=== | + | ^ Umfang ^ Dauer ^ |
| - | Der Dritte Weg behandelt die Erzeugung einer Kultur des kontinuierlichen Experimentierens und das Lernen, die kontinuierliche Erzeugung von Wissen für Einzelne, Teams und die Organisation, | + | | Nur lesen | etwa 6 Stunden | |
| + | | Mit allen Labs | 3 bis 4 Tage | | ||
| + | | Als begleitete Schulung | 5 Tage | | ||
| - | ===== Deployment Pipeline (CI/ | + | ===== Werkzeuge für die Labs ===== |
| - | Die Deployment Pipeline ist ein Prozessmodell, | + | |
| - | Die Schritte in einer CI/ | + | Alles, was gebraucht wird, läuft auf einem Linux-System mit 8 GB RAM — ein Notebook, eine VM oder ein Raspberry Pi 5 genügen. |
| - | * Build – Die Phase, in der die Anwendung kompiliert wird. | + | <typo fs:90%; lh:150%> |
| - | * Test – Die Phase, in der der Code getestet wird. Hier lassen sich durch Automatisierung sowohl der Zeit- als auch der Arbeitsaufwand verringern. | + | * Git |
| - | * Release – Die Phase, in der die Anwendung ins Repository gestellt wird. | + | * Podman oder Docker |
| - | * Bereitstellung – In dieser Phase wird der Code in der Produktionsumgebung bereitgestellt. | + | * ein Editor |
| - | * Validierung und Compliance – Welche Schritte zur Validierung eines Builds notwendig sind, bestimmen die Anforderungen des jeweiligen Unternehmens. Scanning Tools für die Image-Sicherheit, wie Clair, sichern die Qualität von Images, indem diese mit bekannten Schwachstellen (CVEs) verglichen werden. | + | * ein Git-Server (Gitea, GitLab oder GitHub — auch selbst gehostet) |
| + | * optional: Ansible, Prometheus, Grafana | ||
| + | </ | ||
| - | {{ edv:devops: | + | Verwandte Unterlagen in diesem Wiki: |
| - | + | ||
| + | * [[edv: | ||
| + | * [[edv: | ||
| + | * [[edv: | ||
| + | ===== Legende ===== | ||
| + | Farbig hinterlegte Kästen bedeuten: | ||
| + | |||
| + | <WRAP center round tip 90%> | ||
| + | Ein Praxistipp oder eine Empfehlung aus der Erfahrung. | ||
| + | </ | ||
| + | |||
| + | <WRAP center round important 90%> | ||
| + | Etwas, das man wissen muss — typischerweise eine Stelle, an der es sonst klemmt. | ||
| + | </ | ||
| + | |||
| + | <WRAP center round alert 90%> | ||
| + | Eine Warnung. Hier kann echter Schaden entstehen. | ||
| + | </ | ||
| + | |||
| + | ---- | ||
| + | |||
| + | //Weiter mit [[edv: | ||