SWC - Eins

1) Commanded -> Manuell gestartet
2) Schedulded -> Run build bei vordefinierten Intervall oder Zeitangaben
3) Triggered -> Build als Resultat von einem Event (z.B. CI)

Es braucht
- Build Server
- VCS (Version Control Server)
- Klarer Prozess
- Developer Responsebility -> Code checked in before "End of the Day", Code must be buildable, Code must have and pass unit-testing

Sequenziell (z.B. Wasserfallmodell):
- Feste Reihenfolge
- Wenig Änderungen möglich
- Testing oft erst am Ende 
- Weniger Feedback

Iterativ (Agile): 
- Kleinere Schritte (Iterationen)
- Häufiges Testing und Integration
- Schnelle Anpassung bei Änderung
- Kontinuerliches Feedback

- Fehler früh erkennen
- Qualität sichern und verbessern
- Funktionalität und Zuverlässigkeit testen

- Unit-Tests
- Integrationtesting

- Unit-Tests
- Code Reviewing
- Refractoring
- Coding-Standard
- Continous-Integration
- Automatische Builds (Maven)

- Verwaltung von sich ständig ändernde Artefakte, wie Dokumente, Source-Code, oder Konfigurationsdateien
- Verfolgt das Ziel, dass jede Änderung eindeutig nachvollziehbar dokumentiert ist und jede Version eines Artefakts wiederhergestellt werden kann
- Verantwortlich für das Erstellen und Aufrechthalten der Integrität aller Artefakte eines SW-Projektes während des gesamten Life-Cycle

- Konfigurationsplanung
- Toolauswahl
- Release-Planung/Management
- Report des Konfigurationsstatus
- Change-Request Management
- Konfigurationskontrolle
- Konfigurations-Identifikation

- Alte Bugs tretten wieder auf
- Alte Releases können nicht mehr gebuilded werden
- Alte Releases können nicht gefunden werden
- Dateien gehen verloren
- Dateien sind plötzlich verändert (Integration nicht gewährleistet)
- Selber Code existiert in mehreren Projekten
- Zwei Devs änjdern gleiche Datei, ohne es zu merken

Alles was in einem Projekt entsteht, zum Beispiel:
- Source Code
- Dokumentationen/Reporting
- Ausführbare Dateien
- Konfigurations-Datei (yml)
- Build-Skript (pom.xml)

- Das ist ein Artefakt, welches unter Konfigurations- bzw. Versions-Management gestellt werden muss.
- Es muss dabei eindeutig identifizierbar sein und alte Versionen müssen abrufbar bleiben

- Version: Bestimmter Zustand eines Konfigurationselements mit klar definiertem Funktionsumfang
- Release: Eine veröffentlichte Version. Häufig wird ein Reale für Nutzer oder Kunden bereitgestellt
- Variante: Angepasste Form einer Version z.B. Anpassung für Tablets, Sehbehinderte, Hardware, OS etc

- Es werden mindestens 2 Nummern für die Identifikation Verwendet (Major und Minor)
1) Major -> Es muss mit Inkompatibilitäten zwischen Major-Versionen gerechnet werden (1.xx -> 2.xx)
2) Minor -> Änderungen dieser Nummer sind rückwärtskompatibel (1.3.x -> 1.4.x)
3) Patch -> Bug-Fixes, Änderungen sind vorwärts und rückwärtskompatibel (1.3.1 -> 1.3.2)
4) Build -> Nummer gibt eine Neukompilierung von Source-Code an, z.B. aufgrund von Prozessor-, Plattform- oder Compilierungänderungen
5) Revision -> Kleine Änderungen an einer Version, welche Fehler behebt, jedoch keinen Einfluss auf den Funktionsumfang hat
6) Variante -> Variante einer Version, welche entwickelt wurde, um z.B. auf einer anderen HW oder OS zu laufen

Git -> VCS (Speicher Code etc)
Maven -> Build (Baut Projekt)
Gitlab-Ci -> Automation (Macht alles automatisch)
JUnit -> Testing (testet Code)
Checkstyle -> Code Qualität

Tool, welches hilft: 
- Dateien in Projekten zu verwalten
- Änderungen nachvollziehbar zu machen
- Änderungen rückgängig zu machen

Zentrale Datenbank eines Projekts, dort werden Projektdatien und ihre Historie gespeichert -> Repo vergisst nichts, alle Stände bleiben bestehen, neue Änderungen erzeugen neue Version

Lokale Kopie der Projektdateien auf einem lokalen Rechner, dort arbeitet der Entiwckler (Nie direkt auf dem Repo)

- Vorgang, wenn eine Working Copy vom Repo bezogen wird. 
- Reine Leseoperation, auf Dev Maschine wird eine neue Working-Copy erstellt
 

- Vorgang, wenn eine Datei oder ein ganzes Set an Dateien (neu oder edited) mit einer Beschreibung ins Repo gespeichert werden.
- Diese Dateien werden unter "Versionskontrolle" gebracht (git commit -m "xxx")
- Das ist eine Schreiboperation auf das Repo (Erfolgt Atomar = Entweder alles wird im Repo gespeichert oder gar nichts)
 

- Jeder Commit verändert das Repo und erzeugt eine neue identifizierbare Version oder Revision des Repos
- Wichtig um auf einen bestimmten Stand der Arbeit zurückkommen zu können
- Entweder haben die Commits versionsnummern, sind nummeriert oder haben einen Hash als Identifikation

- Bezeichnet einen Entwicklungsverlauf, also zusammengehörige Projektdateien inklusive ihrer Historie
- Haupt Entwicklungsbereich heisst in Git traditionell "master", heute "main"

- Verzweigung eines Entwicklungsverlaufs
- Erlaubt unabhängige Weiterentwicklung

- Zusammenführen von zwei Entwicklungsverläufen, bzw. Branches
- Dabei müssen unterschiedliche Dateistände vereinigt werden (oft manuell)

- Identifiziert/Markiert eine bestimmte Revision/Version eines Entwicklungsverlaufes oder Configuration Items und fügt zusätzliche Infos hinzu (z.B. "Release für Demo xxx")
- Tags sind nur Momentaufnahmen (Snapshots) eines Entwicklungsverlaufes

- Das ist eine Lokale Kopie eines gesamten Repos von einem Remote-Server (Typisch für Git)

Synchronisation zwischen zwei Repos (Lokal Repo und Remote-Repo)
Push: Verschiebt den Zustand des lokalen Repos/Branches auf das Remote-Repo
Pull: Holt den neusten Zustand vom Remote-Repo und synchronisiert ihn mit dem lokalen Repo

- Repo ist auf einem zentralen Server installiert (Nur da!)
- Entwickler holt sich seinen Working-Copy von dem zentralen Server und spielen diese auch wieder direkt zurück
- Wenn der Server einmal nicht erreichbar ist, können keine Datien gesichert oder mti anderen Teammitgliedern getauscht werden

- Bei Distributed version control systems (DVCS), werden auf dem Entwickler rechnern nicht nur Working-Copies abgelegt, sondern eine komplette Kopie des gesamten Repos (clone)
- Enwtickler kann sämtliche Resets und Commits mit seinem lokalen Repo durchführen
- Will er seine Änderung teilen, muss ein Push und Pull durchgeführt werden
- Auch wenn der Server nicht erreichbar, stehen die Versionen zur Verfügung
- Commit geschieht Lokal

1) Repo holen: git clone <url>
2) Datei ändern -> Passiert lokal
3) Änderung vormekren "git add file" -> Landet in Staging Area
4) Änderung commiten "git commit -m "xxx"" Landet in Lokal-Repo
5) Änderungen hochladen "git push"
6) Neue Änderungen vom Team holen "git pull"
 

- Use a sane Repo-Layout (Einheitliche Branch-Struktur verwenden, um die Projektfiles auf dem Repo zu verwalten)
- One change per commit (Je kleiner die Menge der Daten die auf einmal commitet wird, umso einfacher Veränderungen zu sehen und rückgängig zu machen)
- Pull/Fetch often (Lieber oft mit kleinen Änderungen erfreut werden, als einmal eine riesen Überraschung)
- Push often, commit even more often (Stelle deine Arbeit so bald wie möglich deinen Teamkollegen zur verfügung)
- Comment your commits 
- Don't Check in broken Code 
- Delete, don't comment (löschen statt auskommentieren)
- Never mess with the .git folder

1) Working Copy: Hier werden Dateien bearbeitet
2) Staging Area/Index: Hier landen Änderungen nach "git add file". Bereich aus dem der nächste Commit gebaut wird
3) Repository Lokal: Hier liegen bereits commitete Stände
4) Remote-Repository

Bild

Das sind die Zustände einer Datei:
- untracked (Git kennt die Datei noch nicht)
- tracked (Datei ist unter versionkontrolle)
- modified (Datei wurde geändert, aber noch nicht gestaged)
- staged (Änderungen wurden mit "git add" für den nächsten Commit vorgemerkt
- commited (Änderungen sind im Repo gespeichert)