IV Verwendung der Versionsverwaltung

In unserer Organisation verwenden wir Git als einziges System zur Versionsverwaltung, um Änderungen in unseren Softwareentwicklungsprojekten zu verwalten und nachzuverfolgen. Unsere gesamte Codebasis ist auf GitHub gehostet, einer cloudbasierten Plattform für Git-Repositories, die es uns ermöglicht, unsere Projekte effizient zu verwalten, Issues nachzuverfolgen und effektiv zusammenzuarbeiten.

Die Verwendung von Git ermöglicht es Entwicklern, mithilfe von Branching gleichzeitig an verschiedenen Features zu arbeiten, über Commits eine detaillierte Historie aller Änderungen aufzuzeichnen und Änderungen mithilfe von Merges effizient zusammenzuführen. Dies erhöht nicht nur die Nachvollziehbarkeit und Verantwortlichkeit, sondern erleichtert auch die effektive Zusammenarbeit zwischen Entwicklern.

A. Code-Check-in-Richtlinie

Unsere Code-Check-in-Richtlinie betont die Bedeutung einer sauberen, funktionsfähigen und gut organisierten Codebasis. Bevor Code in den master-Branch eingecheckt werden kann, muss er die folgenden Kriterien erfüllen:

1. Keine //todo oder auskommentierter Code: Code sollte keine //todo-Kommentare oder Abschnitte auskommentierten Codes enthalten. Alle //todo-Punkte sollten adressiert und jeglicher auskommentierter Code vor dem Check-in entfernt werden.

2. Angewandtes Code-Format: Code sollte den etablierten Formatierungs- und Stilrichtlinien der Organisation entsprechen. Konsistenz in der Formatierung verbessert die Lesbarkeit und Wartbarkeit des Codes.

3. Entfernung ungenutzten Codes: Jeglicher Code, der nicht verwendet wird, sollte aus der Codebasis entfernt werden. Unnötiger Code kann die Codebasis überladen und möglicherweise Verwirrung und Fehler verursachen.

4. Abdeckung durch Tests: Wichtige Teile des Codes, wie Klassen, Funktionen und Module, sollten durch Tests abgedeckt sein. Weitere Details zu unserer Teststrategie werden im entsprechenden Abschnitt bereitgestellt.

Die Einhaltung dieser Regeln stellt sicher, dass der Code im master-Branch von hoher Qualität ist, leicht verständlich ist und wie erwartet funktioniert. Sie erleichtert außerdem die effektive Zusammenarbeit und minimiert das Risiko, Bugs oder Probleme einzuführen.

B. Branching-Strategie

Unsere Organisation übernimmt das GitHub-Branching-Modell, das Einfachheit und Effizienz betont. Wir konzentrieren uns typischerweise darauf, Bugs in der neuesten Version zu beheben, und halten daran fest, dass der gesamte in den main-Branch gemergte Code potenziell releasefähig sein sollte.

Bei der Entwicklung neuer Features oder Bugfixes erstellen wir für jede Aufgabe separate Branches. Branch-Namen folgen einer bestimmten Konvention: <type>/<team>/<name-of-branch>.

• type: Gibt den Zweck der in diesem Branch vorgenommenen Änderungen an. Es könnte "dev" für neue Ergänzungen oder "fix" für Bugfixes sein. Für Fälle, in denen ein Feature nur in Kombination mit anderen Features sinnvoll ist, kann ein Typ "integration" verwendet werden.

• team: Dies könnte der Name des Teams oder des einzelnen Entwicklers sein, der an dem Branch arbeitet.

• name-of-branch: Dies sollte das entwickelte Feature oder den Bugfix widerspiegeln. Wörter in Branch-Namen werden durch Bindestriche (-) getrennt.

Integration-Branches sollten regelmäßig auf den main-Branch rebased werden, um mit den neuesten Änderungen auf dem aktuellen Stand zu bleiben. Kleinere Features, die zu diesem Branch hinzugefügt werden, sollten gesquasht werden, um die Historie sauber zu halten und unnötige Zwischen-Commits zu vermeiden. Alle Merges in den Integration-Branch sollten einem Code-Review unterzogen werden, um zu vermeiden, große Mengen an Code prüfen zu müssen. Diese Branching-Strategie hilft, unseren Entwicklungsprozess zu straffen, und fördert die effiziente Zusammenarbeit zwischen Entwicklern.

C. Pull Requests und Konfliktlösung

Pull Requests spielen eine entscheidende Rolle im kollaborativen Entwicklungsprozess. Ein Pull Request wird erstellt, wenn ein Entwickler seinen Feature- oder Fix-Branch zurück in den main-Branch mergen möchte.

Um die Integrität und Konsistenz des main-Branch zu wahren, müssen Pull Requests frei von Konflikten sein, bevor sie geprüft und integriert werden können. Vor dem Initiieren eines Pull Requests sind Entwickler verpflichtet, die neuesten Änderungen aus dem master-Branch in ihren Feature- oder Fix-Branch zu mergen oder zu rebasen.

Die Beschreibung eines Pull Requests sollte eine klare und prägnante Erläuterung der eingeführten Änderungen enthalten, etwa "Implemented feature XYZ" oder "Fixed bug ABC". Bei umfangreichen Änderungen, wie architektonischen Anpassungen oder dem Hinzufügen oder Entfernen von Abhängigkeiten, muss eine gründliche Begründung geliefert werden.

Dies ermöglicht es den Reviewern, den Kontext der Änderungen zu verstehen, erleichtert einen effektiveren Review-Prozess und stellt sicher, dass alle Änderungen zielgerichtet und für das Gesamtprojekt vorteilhaft sind.

D. Automatische Builds

Alle dev/*-Branches werden automatisch durch den CI-Build geprüft. Dies stellt sicher, dass der Code kompiliert und dass alle Tests bestehen. Der Build muss behoben werden, bevor der Branch in den main-Branch gemergt wird.

Alle Änderungen am main-Branch werden automatisch gebaut. Wenn der Build erfolgreich ist, werden Services automatisch in die Staging-Umgebung ausgerollt. Wenn das Projekt einen NuGet-Build hat, wird das NuGet-Paket auf nuget.org veröffentlicht. Die Version dieser NuGet-Pakete ist 0.0.YYMM.DDxxx und unterscheidet sich von der Version offizieller Releases, bei denen wir Tagging und semantische Versionierung verwenden.

E. Release- und Tagging-Strategie

Wir erstellen Releases, indem wir den main-Branch mit einer bestimmten Version taggen. Diese Version wird dann als Version für Services sowie für NuGet-Pakete verwendet. Wir taggen nach folgendem Schema: rMajor.Minor.Build, z. B. r1.0.0.