Configuration Management

Konfigurationsmanagement (CM) bezieht sich auf den Prozess, durch den alle für ein Projekt relevanten Artefakte sowie die Beziehungen zwischen ihnen gespeichert, abgerufen, eindeutig identifiziert und modifiziert werden.

Ein Versionskontrollsystem (VCS) ist eine Software, die verwendet wird, um Änderungen an Dateien und Verzeichnissen über die Zeit zu verfolgen, zu verwalten und zu dokumentieren. Es ermöglicht mehreren Personen, gleichzeitig an einem Projekt zu arbeiten, ohne dass dabei die Arbeit der anderen überschrieben wird. Das VCS speichert verschiedene Versionen der Dateien und ermöglicht es den Benutzern, zu einem beliebigen Zeitpunkt auf vorherige Versionen zurückzugreifen. Dadurch wird die Zusammenarbeit erleichtert und die Integrität des Projekts gewährleistet.

1. Alles in der Versionskontrolle behalten: Alle Artefakte, die mit der Erstellung der Software zu tun haben, sollten in der Versionskontrolle sein. Dies schließt Informationen ein, die benötigt werden, um Test- und Produktionsumgebungen zu reproduzieren.

2. Binäre Ausgaben der Kompilierung nicht in der Versionskontrolle halten: Die kompilierte Binärdatei der Anwendung sollte nicht in der Versionskontrolle gespeichert werden.

3. Regelmäßiges Einchecken in den Hauptzweig: Das regelmäßige Einchecken in den Hauptzweig ist wichtig, um sicherzustellen, dass die Arbeit für die Öffentlichkeit bereit ist, da ein Check-in eine Art der Veröffentlichung ist.

4. Aussagekräftige Commit-Nachrichten verwenden: Klare und aussagekräftige Commit-Nachrichten helfen dabei, nachvollziehen zu können, wer den Build kaputt gemacht hat und warum.

5. Häufige Commits durchführen: Häufige Commits machen Änderungen für andere sichtbar und erleichtern das Aufspüren von Fehlern. Außerdem sind Merges immer klein und leicht zu handhaben.

6. Link zu Projektmanagement-Tools in Commit-Nachrichten einfügen: Es ist ratsam, einen Link zur Kennung im Projektmanagement-Tool für das Feature oder den Bug, an dem gearbeitet wird, hinzuzufügen.

Build-Automation bezieht sich auf den Prozess, in dem die Erstellung (Kompilierung und Zusammenstellung) von Software automatisiert wird. Build-Skripts sind Anweisungen, die den Build-Prozess steuern. Sie können in verschiedenen Skriptsprachen geschrieben sein (z.B. Shell-Skript, Makefile, Gradle, etc.) und enthalten Befehle zum Kompilieren, Linken und Verpacken der Software.

Testautomatisierung bezieht sich auf den Einsatz von Software und Tools, um den Prozess der Durchführung von Tests in Softwareentwicklungsprojekten zu automatisieren. Testskripts: Testautomatisierung beginnt mit der Erstellung von Testskripts. Diese Skripts enthalten Anweisungen, die automatisierte Tests durchführen, wie z.B. das Auslösen von Benutzerinteraktionen, das Überprüfen von Ergebnissen und das Abgleichen mit erwarteten Ergebnissen.

Continuous Integration (CI) ist eine Softwareentwicklungsmethode, bei der Mitglieder eines Teams ihre Arbeit häufig auf einem Reposetory integrieren, in der Regel integriert jede Person mindestens täglich - was zu mehreren Integrationen pro Tag führt. Jede Integration wird durch einen automatisierten Build (einschließlich Tests) verifiziert, um Integrationsfehler so schnell wie möglich zu erkennen.

Der Unterschied zwischen Continous Integration und version control System ist dass das CI dafür zuständig ist software möglichst einfach zusammenzuführen und fehler durch automtisierten Build möglichst schnell zu erkennen während VCS dafür da ist um verschiedene Versionen eines Projekts zu verwalten

1. Ein Softwarentwickler commited Änderungen in den version control System

2. Die continous Integration erkennt die Änderung und führt einen Buildtest durch

3. Die Beiteligten Personen (Entwickler) werden über das Ergebnis des Buildtests informiert.

4. Der CI warten wieder auf Änderungen im VCS

• Bugs werden schnell gefunden bzw. ist die Suche leichter

• Dadurch wird der Entwicklungsprozess beschleunigt

• 
  

Files werden in dazugehörige Ordner (Directories) gruppiert. Diese Ordner sind:

1. include: Sind alle Headerfiles die in einem Project verwendet werden (Endung .h)

2. src (Source): enthält Sourcecode (z.b. .c .cpp etc.)

3. Build: enthält vom Compiler erzeugte Dateien. Darunter die Objektdateien (.o) die die Maschinenbefehle enthalten und Executabels (.exe).

   Objektdateinen beinhalten den vom Compiler übersetzten Sourcecode und Executables werden durch linken dieser Objektdateien erzeugt

4. test: Source code for testing

5. lib: Hier werden verwendete librarys gelegt

6. doc: Dokumentationen (Endung .txt)

Beispiel ist das Betriebssystem Linux

Ein "Build" bezieht sich auf den Prozess, bei dem der Quellcode eines Softwareprojekts in eine ausführbare Form umgewandelt wird. Dieser Prozess umfasst in der Regel mehrere Schritte:

1. Kompilieren: Der Quellcode wird in Maschinencode übersetzt. Dieser Maschinencode ist spezifisch für die Zielplattform (wie x86, ARM, etc.).

2. Linken: Die kompilierten Objektdateien werden zusammengeführt und mit den erforderlichen Bibliotheken verknüpft, um eine ausführbare Datei zu erstellen.

static libraries sind Bibliotheken die beim linken Teil der Executable wird.

dynamic libraries sind nicht direkt Teil des Executables sie werden zwischen verschiedenen Anwendungen geteilt und zur runtime geladen wenn benötigt (mithilfe eines dynamic link loaders)

1. Der build Prozess wird durch build Skripts definiert (z.B. Makefile)

2. Ein Build gibt Informationen über den Zustand der Software

3. Ein Build Prozess ist wiederholbar vor allem dann wenn man ein Version Control System benutzt um den Sourcecode zu verwalten

4. Build kann jederzeit ausgeführt werden (z.b. Build über Nacht laufen lassen)

5. Build ist Platformunabhängig

• Ein Unit Test ist eine Software um zu testen ob Bestandteile einer anderen Software richtig funktionieren. Diese Bestandteile können Funktionen oder Ganze Klassen beinhalten.

• Eine Executable Dokumentation ist ein executable dass nicht nur ausführbar ist sondern auch Dokumentationen als Text beinhalten. Somit kann nicht nur einfacher nachvollzogen werden wie ein Code funktioniert sondern er kann auch direkt ausgeführt werden.

• Setup: Hier werden die benötigte Umgebung geschaffen z.B. erstellen eines Objekts einer Klasse

• Excercise: Hier wird der Eigentliche Test durchgeführt z.B. durch aufrufen einer Methode des in Setup erstellten Objekts.

• Verify: Hier wird das Ergebnis der Methode mit den Erwartungen verglichen und Überprüft ob der Test gut gelaufen ist

• Teardown: hier werden die Resourccen wieder freigegeben z.B. durch wieder freigeben des erstellten Objekts

System under Test (SUT): Das ist das Teil, das wir testen wollen. Wenn wir z.B. eine Klasse, ein Objekt oder eine Methode auf ihre Funktionalität prüfen, ist das unser "System under Test".

Depended-on Component (DOC): Das ist eine Klasse oder Komponente, von der unser SUT abhängt. Oftmals passiert die Abhängigkeit durch Aufrufe von Methoden dieser Komponente.

Test Fixture: Das ist die Umgebung, die wir brauchen, um das SUT zu testen. Mindestens beinhaltet sie eine Instanz des SUT. Es können aber auch andere Instanzen (wie z.B. von der DOC) dazu gehören.

Test Suite: Hier fassen wir mehrere einzelne Tests zusammen, um sie alle auf einmal auszuführen. Das macht es einfacher, alle Tests mit einem einzigen Befehl laufen zu lassen.

Test Runner: Der Test Runner ist das Werkzeug, das die Tests durchführt. Er sorgt dafür, dass alle Testmethoden in der Testklasse aufgerufen werden, entweder in einer grafischen Benutzeroberfläche oder über die Kommandozeile.

Unity Test ist ein Farmwork (also eine Vorgefärtigte Softwarestruktur) die für leichteres Unit Testen erstellt wurde.

Unity test enthält vorgefertigte Methoden und Assertions um Test anhand der 4 Phasen des Unit tests durchzuführen.

Die Grundelemnte beinhalten:

• Vorgefertigte Methoden zum Test von Software

• Assertions um das testergbnis zu Überprüfen

• Test runner um die Tests durchzuführen

Außerdem nutzt es Testsuits um mehrere Test durch einen einzigen Befehl auszuführen

Ein Version Control System (VCS) ist ein Softwaretool, das verwendet wird, um verschiedene Dateien, die zu einer Software gehören, zu organisieren und verschiedene Versionen dieser Dateien zu verwalten. Es ermöglicht auch die Zusammenarbeit zwischen verschiedenen Entwicklern an einem Projekt, indem es Änderungen verfolgt und die Möglichkeit bietet, zu früheren Versionen zurückzukehren, falls dies erforderlich ist.

Bei einem lokalen Versionskontrollsystem werden die Dateien, die zu einem Projekt gehören, auf einem einzelnen Computer gespeichert und organisiert. Wenn dieser Computer abstürzt oder die Daten beschädigt werden, besteht die Gefahr, dass alle Daten verloren gehen, da es keine externe Sicherung gibt. Daher ist es wichtig, regelmäßig Backups zu erstellen, wenn man ein lokales Versionskontrollsystem verwendet. Zudem können nur ein Benutzer auf die Daten zugreifen was die Zusammenarbeit mit anderen Entwicklern stört. Es ist jedoch einfach zu benutzen.

In einem zentralisierten Versionskontrollsystem liegen alle Projektdateien auf einem externen Server, auf den mehrere Personen zugreifen können. Einzelne Dateien können auf einem lokalen Computer ausgelagert, bearbeitet und dann wieder auf den Server hochgeladen werden. Das ermöglicht mehreren Entwicklern, gleichzeitig am Projekt zu arbeiten. Allerdings besteht der Nachteil darin, dass alle Daten zentral auf dem Server liegen, sodass bei einem Serverausfall die Gefahr besteht, dass alles verloren geht. Daher ist auch hier eine regelmäßige Sicherung wichtig.

Ein Distributed Version Control System (DVCS) ist ein Versionskontrollsystem, bei dem jede Arbeitskopie eines Projekts ein vollständiges Repository enthält. Das bedeutet, dass jeder Entwickler eine vollständige Kopie aller Dateien und deren Verlauf (Versionsgeschichte) hat.

Im Gegensatz zum zentralisierten Versionskontrollsystem (CVCS), bei dem alle Dateien auf einem zentralen Server liegen und von dort aus verwaltet werden, erlaubt ein DVCS den Entwicklern, auch offline zu arbeiten. Sie können Änderungen an ihren lokalen Kopien vornehmen, ohne eine ständige Verbindung zum Server zu benötigen.

Wenn ein Entwickler Änderungen abschließt und diese in das gemeinsame Repository einfügen möchte, erfolgt ein sogenannter "Pull Request" oder "Push". Dies ermöglicht es anderen Entwicklern, die neuen Änderungen in ihre lokalen Kopien zu integrieren.

Beispiele für Distributed Version Control Systems sind Git und Mercurial.

1. Working Directory (Arbeitsverzeichnis):

   • Das Working Directory ist der lokale Ordner auf deinem Computer, in dem du an deinem Projekt arbeitest. Hier liegen die Dateien, die du gerade bearbeitest.

   • Es enthält sowohl die aktuellen Dateien als auch die älteren Versionen, die im Repository gespeichert sind.

2. Staging Area (Index):

   • Die Staging Area ist eine Zwischenstation zwischen dem Working Directory und dem Repository.

   • Hierhin fügst du die Dateien hinzu, die du für den nächsten Commit auswählen möchtest. Das bedeutet, du sagst dem Versionskontrollsystem, welche Änderungen du in die nächste Version deines Projekts übernehmen möchtest.

   • Diese Auswahl ermöglicht es dir, spezifische Änderungen getrennt zu halten und organisiert zu verwalten.

3. Repository (Repositorium):

   • Das Repository ist der zentrale Speicherort für alle Versionen deines Projekts. Es ist oft auf einem externen Server, kann aber auch lokal auf deinem Computer sein.

   • Hier sind alle Versionen der Dateien gespeichert, die du je in das Projekt eingecheckt (committet) hast.

   • Das Repository ermöglicht es dir, zwischen verschiedenen Versionen zu wechseln, ältere Versionen wiederherzustellen und die Arbeit anderer Entwickler zu integrieren.

Zusammengefasst: Das Working Directory ist der lokale Ordner, in dem du arbeitest. Die Staging Area ist eine Zwischenstation, in der du Änderungen für den nächsten Commit auswählst. Das Repository ist der zentrale Speicherort für alle Versionen deines Projekts.

1. Untracked (Nicht verfolgt):

   • Untracked bedeutet, dass eine Datei im Working Directory existiert, aber noch nicht dem Versionskontrollsystem hinzugefügt wurde.

   • Das Versionskontrollsystem kennt diese Datei noch nicht und nimmt keine Änderungen daran zur Kenntnis.

2. Unmodified (Unverändert):

   • Eine Datei ist unverändert, wenn sie bereits im Repository gespeichert ist und seit dem letzten Commit keine Änderungen erfahren hat.

   • Das bedeutet, dass die Version im Working Directory identisch mit der Version im Repository ist.

3. Modified (Verändert):

   • Eine Datei ist als verändert markiert, wenn sie im Working Directory bearbeitet wurde, seit dem letzten Commit.

   • Das Versionskontrollsystem erkennt an, dass es Unterschiede zwischen der Version im Working Directory und der Version im Repository gibt.

4. Staged (Bereitgestellt):

   • Eine Datei ist als bereitgestellt markiert, wenn sie aus dem Working Directory in die Staging Area verschoben wurde.

   • In der Staging Area befinden sich die Änderungen, die du für den nächsten Commit auswählen möchtest.

Zusammengefasst: Untracked bezieht sich auf eine Datei, die noch nicht dem Versionskontrollsystem hinzugefügt wurde. Unmodified bedeutet, dass eine Datei im Working Directory unverändert ist. Modified zeigt an, dass eine Datei im Working Directory bearbeitet wurde. Staged bezieht sich auf Änderungen, die ausgewählt wurden, um in den nächsten Commit aufgenommen zu werden.

Beim Tagging im Repository markiert man ein bestimmtes Commit mit einem "Tag" oder einer Bezeichnung, um es leichter identifizieren zu können. Typischerweise werden Tags verwendet, um wichtige Meilensteine oder Versionen zu kennzeichnen.

Ein häufiges Anwendungsszenario ist das Markieren des letzten Commits vor einem Release, um leicht auf den Zustand der Software zu diesem Zeitpunkt zurückkehren zu können. Dies ermöglicht es Entwicklern, den spezifischen Codestand für eine bestimmte Version zu überprüfen oder darauf aufzubauen.

Tags sind eine nützliche Methode, um bestimmte Punkte in der Historie des Repositorys zu markieren und zu verwalten.

Beim Branching wird eine Kopie des aktuellen Entwicklungsstandes erstellt, um daran unabhängig von anderen Entwicklungen zu arbeiten. Diese Kopie wird oft als "Branch" bezeichnet. Jeder Entwickler kann in seinem eigenen Branch arbeiten, ohne andere zu beeinflussen.

Sobald die Entwicklung in einem Branch abgeschlossen ist, können die Änderungen in den Hauptentwicklungszweig (auch "Master"-Branch genannt) integriert werden. Der Merge-Prozess übernimmt die Änderungen aus dem Quell-Branch und fügt sie in den Ziel-Branch ein.

Der Hauptzweig enthält die unveränderte Version der Software, bis ein Merge-Prozess stattfindet. Sobald ein Merge durchgeführt wird, werden die Änderungen aus dem Quell-Branch in den Ziel-Branch integriert, und dieser enthält dann die aktualisierte Version.

Das Branching ermöglicht eine parallele Entwicklung, ohne dass sich Entwickler gegenseitig beeinflussen. Der Merge-Prozess sorgt dafür, dass die Änderungen in einem kontrollierten und nachvollziehbaren Prozess zusammengeführt werden.

Beim "Three-Way Merging" handelt es sich um eine Technik, die verwendet wird, um Änderungen aus zwei verschiedenen Branches in einen gemeinsamen Zielspeicher zu integrieren. Es werden dabei drei Versionen des Codes verglichen:

1. Die gemeinsame Basis (Base): Dies ist der Stand des Codes, von dem beide Branches ausgegangen sind. Es ist die gemeinsame Version, bevor die jeweiligen Änderungen gemacht wurden.

2. Die erste Änderung (Branch A): Dies sind die spezifischen Änderungen, die im ersten Branch gemacht wurden.

3. Die zweite Änderung (Branch B): Hierbei handelt es sich um die spezifischen Änderungen, die im zweiten Branch gemacht wurden.

Das Ziel des Three-Way Mergings ist es, automatisch zu bestimmen, wie die Änderungen aus beiden Branches in den gemeinsamen Zielzustand integriert werden können. Dabei sollen Konflikte vermieden oder erkannt und gelöst werden.

Der Prozess des Three-Way Mergings ist besonders wichtig bei der parallelen Entwicklung von Software, da er sicherstellt, dass die Arbeit mehrerer Entwickler erfolgreich zusammengeführt wird, ohne dass Konflikte entstehen.

1. Entwicklung auf der Hauptlinie (Develop on Mainline):

   • Beschreibung: Bei diesem Muster arbeiten alle Entwickler direkt auf der Hauptentwicklungslinie (Hauptlinie) des Versionskontrollsystems. Neue Funktionen und Bugfixes werden direkt in diese Hauptlinie integriert.

   • Vorteile: Einfach und geradlinig. Alle Änderungen sind sofort für das gesamte Team verfügbar.

   • Nachteile: Es kann zu Konflikten führen, wenn mehrere Entwickler gleichzeitig an derselben Stelle arbeiten.

2. Zweig für Veröffentlichung (Branch for Release):

   • Beschreibung: In diesem Muster wird ein separater Zweig für die Vorbereitung einer Veröffentlichung erstellt. Hier werden nur Stabilisierungsänderungen und Fehlerkorrekturen vorgenommen, um die Version für die Veröffentlichung vorzubereiten.

   • Vorteile: Erhöhte Stabilität und Zuverlässigkeit der Veröffentlichung. Die Entwicklung in der Hauptlinie kann während der Vorbereitung der Veröffentlichung fortgesetzt werden.

   • Nachteile: Möglicher Mehraufwand beim Zusammenführen von Änderungen zwischen dem Veröffentlichungszweig und der Hauptlinie.

3. Zweig für Feature (Branch for Feature):

   • Beschreibung: Hierbei handelt es sich um das Muster, bei dem für jede neue Funktion oder jedes neue Feature ein eigener Zweig erstellt wird. Entwickler arbeiten an ihren Features in isolierten Branches, bevor sie in die Hauptlinie integriert werden.

   • Vorteile: Klare Trennung der Entwicklung von neuen Funktionen. Es reduziert das Risiko von Konflikten und Fehlern in der Hauptlinie.

   • Nachteile: Möglicher Mehraufwand beim Verwalten und Integrieren von Feature-Branches

1. Git:

   • Beschreibung: Git ist ein verteiltes Versionskontrollsystem, das entwickelt wurde, um die gemeinsame Arbeit an Softwareprojekten zu erleichtern. Es ermöglicht Entwicklern, Änderungen zu verfolgen, zu verwalten und zu teilen.

   • Merkmale:

     • Dezentralisiert: Jeder Entwickler hat eine lokale Kopie des gesamten Repositorys, was die Arbeit offline ermöglicht.

     • Effiziente Verwaltung von Branches und Merging.

     • Hohe Geschwindigkeit und Effizienz, da es lokal arbeitet.

2. GitHub:

   • Beschreibung: GitHub ist eine Webplattform, die auf Git basiert und eine zentrale Anlaufstelle für die gemeinsame Arbeit an Git-Projekten bietet. Es bietet eine Benutzeroberfläche zur Interaktion mit Git-Repositories.

   • Merkmale:

     • Kollaborative Entwicklung: Mehrere Entwickler können an Projekten zusammenarbeiten und Änderungen verfolgen.

     • Pull-Requests ermöglichen die Diskussion und Überprüfung von Änderungen vor der Integration in das Hauptrepository.

     • Problemverfolgung, Wiki, Projektaufgaben und andere Tools zur Projektverwaltung.

3. GitLab:

   • Beschreibung: GitLab ist eine ähnliche Plattform wie GitHub, bietet jedoch zusätzlich die Möglichkeit, GitLab auf eigenen Servern zu hosten (selbst gehostete Version). Es ist eine webbasierte DevOps-Lösung, die verschiedene Werkzeuge für die Softwareentwicklung bereitstellt.

   • Merkmale:

     • Selbst gehostete Version: Unternehmen können GitLab auf eigenen Servern hosten, was mehr Kontrolle über Sicherheit und Datenschutz ermöglicht.

     • Integriertes CI/CD: GitLab bietet integrierte Funktionen für die kontinuierliche Integration und Bereitstellung von Software.

     • Erweiterte Projektmanagementfunktionen, einschließlich Scrum, Kanban, Issue-Boards und vieles mehr.

Zusammenfassend gesagt, ist Git die zugrunde liegende Versionierungstechnologie. GitHub und GitLab sind Plattformen, die auf Git aufbauen und erweiterte Funktionen für die Kollaboration, Projektverwaltung und CI/CD-Bereitstellung bieten. GitLab bietet zusätzlich die Möglichkeit zur Selbsthosting-Version, während GitHub eine ausschließlich gehostete Plattform ist.

1. Legal Comments: z.B. Copyright oder Authorship

2. Bewegungsgrund: Um darzlegen warum ein code so geschrieben wurde wie er ist

3. Manche Anweisungen können für andere Leser schwieriger nachzuvollziehen sein. Es macht hier sinn Klarzustellen was gemeint ist

4. TO-DO Kommentare

1. Eine chronologische Auflistung wann was gemacht wurde. Dafür gibt es Version Control System

2. Auskommentierter Code

3. Redundanz: Man sollte nicht versuchen code nochmal in Worten auszufomulieren.

4. Kommentare zu geschlossen Klammern z.B. } // if Statement; wenn der Code zu unübersichtlich ist als dass man sieht wo die Klammern dazugehören dann besser den Code überarbeiten

• veraltete oder fehlende Dokumentation

• Chaotische und verwirrende Dokumentation

• Zu viel Dokumentation kann auch ein Problem sein, wenn es schwierig wird, spezifische Informationen zu finden

• Schwer zu lesende Dokumentation