|
@ -170,7 +170,102 @@ Rebase vs Merge: |
|
|
|
|
|
|
|
|
Keep commits small and clean for easier problem solving and back tracking. |
|
|
Keep commits small and clean for easier problem solving and back tracking. |
|
|
|
|
|
|
|
|
|
|
|
## Vorlesung (23.11) |
|
|
|
|
|
|
|
|
|
|
|
### Lernziele |
|
|
|
|
|
|
|
|
|
|
|
Vorteile von Continuous Delivery (CI): |
|
|
|
|
|
|
|
|
|
|
|
1. automatisierte Prozesse verrigern Aufwand |
|
|
|
|
|
2. formale Prozesse verringern Konfliktpotential |
|
|
|
|
|
3. Vorstufe zu _Continuous Delivery_ |
|
|
|
|
|
|
|
|
|
|
|
Bestandteile von Softwareentwicklungsprozess: |
|
|
|
|
|
|
|
|
|
|
|
1. Code schreiben |
|
|
|
|
|
2. Abhängigkeitenverwaltung |
|
|
|
|
|
3. Code veröffentlichen |
|
|
|
|
|
4. Integration |
|
|
|
|
|
5. build-Prozess: compile und test |
|
|
|
|
|
6. Bereitstellung |
|
|
|
|
|
|
|
|
|
|
|
Abhängigkeitenverwaltung: |
|
|
|
|
|
|
|
|
|
|
|
1. nicht selbst im Build-Lauf erzeugt |
|
|
|
|
|
2. nicht im SCM eingecheckt |
|
|
|
|
|
3. zentrale Bereitstellung (innerhalb der Organisation) |
|
|
|
|
|
4. Zugriff auf einzelne Versionen |
|
|
|
|
|
|
|
|
|
|
|
Semantische Versionierung: |
|
|
|
|
|
|
|
|
|
|
|
__1.2.3-beta1__ |
|
|
|
|
|
|
|
|
|
|
|
1- MAJOR - inkompatible Änderungen |
|
|
|
|
|
2- MINOR - zusätzliche Features, Programmteil bleibt abwärtskompatibel |
|
|
|
|
|
3- PATCH - Fehlerbehebungen, Programmteil bleibt abwärtskompatibel |
|
|
|
|
|
beta1- LABEL - spezifische Build-Kennzeichung |
|
|
|
|
|
|
|
|
|
|
|
Source Code Management (SCM): |
|
|
|
|
|
|
|
|
|
|
|
1. Sicherung der Arbeit einzelner Entwickler |
|
|
|
|
|
2. zentrale Verfügbarmachung |
|
|
|
|
|
3. Zusammenführung parallel geänderter Dateien |
|
|
|
|
|
4. parallele Entwicklung verschiedener Features ermöglichen |
|
|
|
|
|
5. Zugriff auf dedizierte Stände (*releases*) |
|
|
|
|
|
6. Wechsel zwischen Entwicklungsständen (`branches`) |
|
|
|
|
|
|
|
|
|
|
|
build - Prozess: |
|
|
|
|
|
|
|
|
|
|
|
1. Übersetzen |
|
|
|
|
|
2. ängigkeiten organisieren |
|
|
|
|
|
3. automatisierte Tests ausführen |
|
|
|
|
|
4. Liefer-Artefakte erzeugen |
|
|
|
|
|
5. Deployment |
|
|
|
|
|
|
|
|
|
|
|
build-Prozess starten: |
|
|
|
|
|
|
|
|
|
|
|
- Abhängigkeiten auflösen |
|
|
|
|
|
- compilieren |
|
|
|
|
|
- automatisierte Tests ausführen |
|
|
|
|
|
- Lieferartefakt erstellen |
|
|
|
|
|
- Lieferartefakt ausliefern |
|
|
|
|
|
|
|
|
|
|
|
Integration: |
|
|
|
|
|
|
|
|
|
|
|
1. SCM überwachen |
|
|
|
|
|
2. build-Prozess starten |
|
|
|
|
|
3. Ergebnisse berichteten |
|
|
|
|
|
|
|
|
|
|
|
Problem des Continuous Ingegrations: |
|
|
|
|
|
|
|
|
|
|
|
1. kein menschlicher Eingriff |
|
|
|
|
|
2. compilierbar nicht bedeutet ausführbar |
|
|
|
|
|
3. CI soll immer lieferbaren Stand bereit halten |
|
|
|
|
|
4. Programm muss im CI Prozess ausgeführt werden |
|
|
|
|
|
|
|
|
|
|
|
Vorteile automatisierter Tests: |
|
|
|
|
|
|
|
|
|
|
|
1. automatisierte Tests führen Programm aus |
|
|
|
|
|
2. dokumentieren gewünschtes Verhalten |
|
|
|
|
|
3. sind wiederholbar |
|
|
|
|
|
4. erkennen Laufzeitfehler (außer UnitTests) |
|
|
|
|
|
5. Ausführungszeit von Arbeitszeit entkoppelt |
|
|
|
|
|
|
|
|
|
|
|
gemeinsames _remote repository_ |
|
|
|
|
|
|
|
|
|
|
|
1. alle Entwickler arbeiten ausschließlich gegen ein gemeinsames _remote repository_ |
|
|
|
|
|
2. jeder Entwickler hat (Schreib-)Zugriff |
|
|
|
|
|
3. einfache Synchonisation |
|
|
|
|
|
4. (gepushte) Zwischenstände für alle direkt sichtbar |
|
|
|
|
|
|
|
|
|
|
|
privater *fork*: |
|
|
|
|
|
|
|
|
|
|
|
1. es gibt ein zentrales remote repository (= _master_) |
|
|
|
|
|
2. jeder Entwickler hat ein separates remote repository (= _fork_) |
|
|
|
|
|
3. jedes locale repository hat 2 _remote repositories_: |
|
|
|
|
|
- `origin` - *master*, nur lesend |
|
|
|
|
|
- `upstream` - privater *fork*, Schreibrechte |
|
|
|
|
|
|
|
|
|
|
|
### Kritik |
|
|
|
|
|
|
|
|
|
|
|
*forking* is a good practice for a large scale project, where a lot of people working on the same repository at the same time. |