|
|
@ -702,7 +702,7 @@ In der letzten Übung haben wir einige neue Git-Befehle kennen gelernt. Um diese |
|
|
- durch formale Vorgehensweise |
|
|
- durch formale Vorgehensweise |
|
|
- ändert z. B. Whitespace und Formatierung |
|
|
- ändert z. B. Whitespace und Formatierung |
|
|
- Verringerung des Konfliktpotentials |
|
|
- Verringerung des Konfliktpotentials |
|
|
- Vorstufe zu COntinous Delivery |
|
|
|
|
|
|
|
|
- Vorstufe zu Continous Delivery |
|
|
|
|
|
|
|
|
- Softwareentwicklungsprozess |
|
|
- Softwareentwicklungsprozess |
|
|
- Code schreiben |
|
|
- Code schreiben |
|
|
@ -722,6 +722,68 @@ In der letzten Übung haben wir einige neue Git-Befehle kennen gelernt. Um diese |
|
|
- Ergebnis wird in Repo hochgeladen |
|
|
- Ergebnis wird in Repo hochgeladen |
|
|
- Lieferartefakt |
|
|
- Lieferartefakt |
|
|
|
|
|
|
|
|
|
|
|
- Abhängigkeitsverwaltung |
|
|
|
|
|
- Definition Abhängigkeit |
|
|
|
|
|
- alles an Code was von außerhalb der Firma kommt |
|
|
|
|
|
- alles was nicht vom Build-Prozess übersetzt wird |
|
|
|
|
|
- sind in Binary |
|
|
|
|
|
- werden von SCM nicht erkannt/eingecheckt |
|
|
|
|
|
- bekannte Plattform: Github |
|
|
|
|
|
|
|
|
|
|
|
- Versionsnummern |
|
|
|
|
|
- eindeutiges Schema |
|
|
|
|
|
- zeigt den Aufwand der Integration einer neueren Version |
|
|
|
|
|
- Major |
|
|
|
|
|
- Änderungen die zur Inkompatibilität führen können |
|
|
|
|
|
- Aufmerksamkeit bei Updates notwendig |
|
|
|
|
|
- Minor |
|
|
|
|
|
- neue Features und Eigenschaften |
|
|
|
|
|
- führen nicht zur Inkompatibilität |
|
|
|
|
|
- Programm welches bestimmte Features benutzt, braucht mindestens bestimmte Version in der die Features eingeführt wurden |
|
|
|
|
|
- Problem mit zu alten Versionen |
|
|
|
|
|
- Patch |
|
|
|
|
|
- Fehlerbereinigung |
|
|
|
|
|
- keine neuen Features |
|
|
|
|
|
- Label |
|
|
|
|
|
- Unterscheidung der Finalität der Version |
|
|
|
|
|
- _Gibt es noch Änderungen an der Version? Wie stabil ist die Version? alpha, beta..._ |
|
|
|
|
|
- gibt Auskunft welche Version für das Projekt am besten geeignet ist |
|
|
|
|
|
- Regeln |
|
|
|
|
|
- Label nur in ASCII |
|
|
|
|
|
- Major, Minor und Patch nur Zahlen und Punkte |
|
|
|
|
|
- wenn Major erhöht wird, werden Minor und Patch auf Null zurückgesetzt |
|
|
|
|
|
- eigentlich schlecht weil Patchlevel bei unterschiedlichen Majorversionen unterschiedlich sein kann |
|
|
|
|
|
- nicht einfach durchsichtig welche Version welche z.B. Sicherheitsupdates/gefixte Bugs hat |
|
|
|
|
|
- wenn Minor erhöht wird, wird Patch zurück gesetzt |
|
|
|
|
|
- kein Label ist immer die neuste Version |
|
|
|
|
|
|
|
|
|
|
|
- SCM |
|
|
|
|
|
- Sicherung/Backup der Arbeit von Entwicklern |
|
|
|
|
|
- Veröffentlichungsplattform |
|
|
|
|
|
- verschiedene Entwickler können an verschiedenen Features arbeiten (_parallele Entwicklung_) |
|
|
|
|
|
- Zusammenführung von Änderungen |
|
|
|
|
|
- was eingecheckt wird, sollte funktionieren |
|
|
|
|
|
- minimal clean Commits |
|
|
|
|
|
- Wechseln zwischen Entwicklungsständen (_branches_) möglich |
|
|
|
|
|
|
|
|
|
|
|
- Build-Prozess |
|
|
|
|
|
- manueller Prozess |
|
|
|
|
|
- Code wird übersetzt |
|
|
|
|
|
- besorgt sich Abhängigkeiten |
|
|
|
|
|
- automatisierte Tests werden ausgeführt |
|
|
|
|
|
- Lieferartefakte werden erzeugt |
|
|
|
|
|
- und ausgeliefert (_Depolyment_) |
|
|
|
|
|
- Build-Tools |
|
|
|
|
|
- beliebte Buildtools |
|
|
|
|
|
- make |
|
|
|
|
|
- for allem für C |
|
|
|
|
|
- kein Verwaltung von Abhängigkeiten |
|
|
|
|
|
- maven/gradle |
|
|
|
|
|
- Java |
|
|
|
|
|
- Versionsverwaltung von Abhängigkeiten |
|
|
|
|
|
- npm |
|
|
|
|
|
- Javascript/Typescript |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
fdai7783
1 year ago