|
|
|
@ -607,23 +607,23 @@ Schreibe Code im TDD cycle. |
|
|
|
|
|
|
|
#### Bedeutung von CI im Softwareentwicklungsprozess |
|
|
|
|
|
|
|
Größe von Software-Projekten |
|
|
|
**Größe von Software-Projekten** |
|
|
|
- steigende Komplexität |
|
|
|
- mehrere Entwickler |
|
|
|
- Zusammenführen der Einzelleistungen |
|
|
|
|
|
|
|
Zusammenführen der Einzelleistungen |
|
|
|
Z**usammenführen der Einzelleistungen** |
|
|
|
- Widerspruch Kreativität vs. Konformität |
|
|
|
- technische Konflikte |
|
|
|
- persönliche Konflikte |
|
|
|
- Aufwand |
|
|
|
|
|
|
|
Vorteile von CI Systemen |
|
|
|
**Vorteile von CI Systemen** |
|
|
|
- formale Prozesse verringern |
|
|
|
- automatisierte Prozesse verringern Aufwand |
|
|
|
- Vorstufe zu Continous Delivery |
|
|
|
|
|
|
|
Aufbau eines CI/CD-Systems |
|
|
|
**Aufbau eines CI/CD-Systems** |
|
|
|
|
|
|
|
- Entwicklungsumgebung des Programmierers |
|
|
|
- Source Code Management System (SCM) |
|
|
|
@ -632,9 +632,9 @@ Aufbau eines CI/CD-Systems |
|
|
|
- Continous Integration Server |
|
|
|
- Erweiterungen für Continous Delivery |
|
|
|
|
|
|
|
Entwicklungsumgebung des Programmierers |
|
|
|
**Entwicklungsumgebung des Programmierers** |
|
|
|
|
|
|
|
Integrated Developement Environment (IDE) |
|
|
|
**Integrated Developement Environment (IDE**) |
|
|
|
- Syntax highlighting |
|
|
|
- Syntax-Vervollständigung |
|
|
|
- automatisierte Refactorings |
|
|
|
@ -643,7 +643,7 @@ Integrated Developement Environment (IDE) |
|
|
|
- Code automatische Formatierung |
|
|
|
- Fehler-Lokalisierung |
|
|
|
|
|
|
|
Source Code Management System (SCM) |
|
|
|
**Source Code Management System (SCM)** |
|
|
|
- Sicherung der Arbeit einzelner Entwickler |
|
|
|
- zentrale Verfügbarmachung |
|
|
|
- Zusammenführung parallel geänderter Dateien |
|
|
|
@ -651,28 +651,28 @@ Source Code Management System (SCM) |
|
|
|
- Zugriff auf dedizierte Stände (releases) |
|
|
|
- wechsel zwischen Entwicklungsständen |
|
|
|
|
|
|
|
Abhängigkeitenverwaltung |
|
|
|
**Abhängigkeitenverwaltung** |
|
|
|
- nicht selbst im Build-Lauf erzeugt |
|
|
|
- zentrale Bereitstellung (innerhalb der Organisation) |
|
|
|
- Zugriff auf einzelne Versionen |
|
|
|
|
|
|
|
build – Werkzeug |
|
|
|
**build – Werkzeug** |
|
|
|
- Übersetzen |
|
|
|
- Liefer-Artefakte erzeugen |
|
|
|
- Abhängigkeiten organisieren |
|
|
|
- automatisierte Tests ausführen |
|
|
|
- Deploymen |
|
|
|
|
|
|
|
Continous Integration Server |
|
|
|
**Continous Integration Server** |
|
|
|
- SCM überwachen |
|
|
|
- build-Prozess starten |
|
|
|
- Ergebnisse berichteten |
|
|
|
|
|
|
|
Erweiterungen für Continous Delivery |
|
|
|
**Erweiterungen für Continous Delivery** |
|
|
|
- Staging System |
|
|
|
- Produktions System |
|
|
|
|
|
|
|
Ablauf des CI-Prozesses |
|
|
|
**Ablauf des CI-Prozesses** |
|
|
|
- Checkin Change |
|
|
|
- Fetch Change |
|
|
|
- Build |
|
|
|
@ -680,7 +680,7 @@ Ablauf des CI-Prozesses |
|
|
|
- Ergebnisauswertung |
|
|
|
- Benachrichtigung |
|
|
|
|
|
|
|
Checkin Change |
|
|
|
**Checkin Change** |
|
|
|
- veröffentlichen der Änderung |
|
|
|
- eigener branch |
|
|
|
- alle aktuell veröffentlichten Änderungen integriert. |
|
|
|
@ -689,27 +689,27 @@ Checkin Change |
|
|
|
- automatisierte (Unit–)Tests sind ”grün” |
|
|
|
- Lieferobjekt kann lokal gebaut werden |
|
|
|
|
|
|
|
Fetch Change |
|
|
|
**Fetch Change** |
|
|
|
- Änderungen feststellen |
|
|
|
- zeitgesteuert |
|
|
|
- ereignisgesteuert |
|
|
|
|
|
|
|
Build |
|
|
|
**Build** |
|
|
|
- Änderung mit aktuellem Stand integrieren (merge) |
|
|
|
- compile (Produktivcode und Testcode) |
|
|
|
|
|
|
|
Test |
|
|
|
**Test** |
|
|
|
- nur nach erfolgreichem compile |
|
|
|
- Testframework starten |
|
|
|
- Ergebnisse sammeln |
|
|
|
|
|
|
|
Ergebnisauswertung |
|
|
|
**Ergebnisauswertung** |
|
|
|
- Ermittelt Status von merge, compile und Test |
|
|
|
- Erfolgsfall: Änderung als neuen aktuellen Stand übernehmen undveröffentlichen |
|
|
|
- Ergebnisdarstellung als Webseite |
|
|
|
|
|
|
|
|
|
|
|
Benachrichtigung |
|
|
|
**Benachrichtigung** |
|
|
|
- zeitnah |
|
|
|
- Fehlerfall: Committer |
|
|
|
- Erfolgsfall: alle |
|
|
|
@ -721,17 +721,17 @@ Benachrichtigung |
|
|
|
- WhatsApp |
|
|
|
|
|
|
|
|
|
|
|
Rolle von automatisierten Tests |
|
|
|
**Rolle von automatisierten Tests** |
|
|
|
- Problem des Continous Integration |
|
|
|
- Vorteile automatisierter Tests |
|
|
|
- Grenzen automatisierter Tests |
|
|
|
|
|
|
|
Problem des Continous Integration |
|
|
|
**Problem des Continous Integration** |
|
|
|
- compilierbar ! = ausführbar |
|
|
|
- CI soll immer lieferbaren Stand bereit halten |
|
|
|
- Programm muss im CI Prozess ausgeführt werden |
|
|
|
|
|
|
|
Vorteile automatisierter Tests |
|
|
|
**Vorteile automatisierter Tests** |
|
|
|
- automatisierte Tests führen Programm aus |
|
|
|
- dokumentieren gewünschtes Verhalten |
|
|
|
- sind wiederholbar |
|
|
|
@ -739,7 +739,7 @@ Vorteile automatisierter Tests |
|
|
|
- Ausführungszeit von Arbeitszeit entkoppelt |
|
|
|
|
|
|
|
|
|
|
|
Grenzen automatisierter Tests |
|
|
|
**Grenzen automatisierter Tests** |
|
|
|
- finden nur Abweichungen von gewünschten/bekanntem Verhalten |
|
|
|
- finden keine neuen fachlichen Fehler |
|
|
|
|
|
|
|
|
devops
2 years ago