Table of Contents

git

Auf jedem Rechner, auf dem AL entwickelt werden soll, muss git installiert sein. Bei der Installation sollte darauf geachtet werden, überall die Windows-spezifischen Optionen zu wählen. Nach einer Erstinstallation müssen einmal die Einstellungen für Benutzername und Mailadresse hinterlegt werden. Es wird global eingetragen, da wir auf Sicht nicht mit abweichenden Einstellungen je Repository arbeiten. Dafür einmal in einem cmd-prompt oder PowerShell folgende zwei Kommandos eingeben. Die Beispiele sind dann entsprechend anzupassen:

git config --global user.name "Vorname Nachname"
git config --global user.email "vorname.nachname@gob.de"

Branching

Die Vorgaben für die Branching-Strategie erfordern neben der Verwendung von git auch die von Azure DevOps. Für die Verwendung in Projekten wird die folgende Strategie nahegelegt. Projektteams können in begründeten Fällen davon abweichen, entsprechende Optionen beschränken sich aber nur auf das Weglassen bestimmter Automatiken oder von production-Branches. Sonstige Eigenkreationen in der Strategie sind nicht erlaubt. Im Alltag vom gewählten Arbeitsfluss abzuweichen ist nicht erlaubt. Nur so ist die fachlich saubere Sicherung und Verwaltung des Quellcode sichergestellt.

Hinweis

Die Struktur von Branches, Work Items und deren Abarbeitung ist entscheidend für den reibungslosen Ablauf in der Entwicklung! Entwicklungsaufgaben sollten nie mehr als einige wenige Tage erfordern. Größere Arbeiten sind entweder in einzelne Work Items aufzuteilen oder wenigstens in Tasks herunterzubrechen. Siehe auch Azure DevOps. Die Bearbeitung mehrerer Work Items in einem Branch ist möglichst zu vermeiden, da die klare Zuordnung zu git Branches aufgeweicht wird und die Handhabung der Pull Requests im Lebenszyklus einer Entwicklungsarbeit erschwert wird. merge fast, merge often

Standard-Branching

Branch Anzahl Verwendung Policies
production/.. Je Release in einer Kundenumgebung Für Releases des Kunden. Jeweils neu anzulegen für anstehende Releases ins Produktivsystem des Kunden. • Bleiben dauerhaft bestehen
• Min. ein verpflichtender Reviewer
• nur Basic Merge
• Kommentare auflösen verpflichtend
• Work Item verknüpfen verpflichtend
dev Einer Für das Zusammenführen von laufenden Entwicklungen • Bleibt dauerhaft bestehen
• Min. ein verpflichtender Reviewer
• nur Squash Merge
• Kommentare auflösen verpflichtend
• Work Item verknüpfen verpflichtend
w/... Nach Bedarf. In der Regel viele. Arbeitsbranches für Entwicklungsaufgaben Bestehen nur für die konkrete Aufgabe und werden mit Abschluss des Pull Request immer gelöscht
f/.. Nach Bedarf. In der Regel keiner bis wenige. OPTIONAL: Feature-Branches für die Zusammenfassung von großen Entwicklungen, die aus einem kommenden Release herausgehalten werden sollen und aber die w/...-Branches mehrerer Entwickler zusammenführen müssen. Nach Bedarf, meistens analog dev
m/.. Nach Bedarf. In der Regel keiner bis wenige. OPTIONAL: Merge-Branches für das Nachmergen von dev in einen Feature-Branch Keine

Diagramm Git-Flow

Die hier dargestellten Branches zeigen einen beispielhaften Verlauf über die Zeit:

  • Der dev-Branch bleibt dauerhaft bestehen. Dort hinein fließen in der Regel alle Entwicklungsarbeiten zusammen. In der Regel wird dem Kunden der Stand dieses Branch im Testsystem bereitgestellt.
  • Entwicklungsarbeiten finden in vielen, teils parallelen Arbeitsbranches (w/...) statt. In der Regel befindet sich der Code nur auf Entwicklersystemen.
  • production-Branches werden immer dann angelegt, wenn ein fixierter Stand für den Produktivbetrieb ausgerollt werden soll.
  • Feature Branches (f/...) werden dann verwendet, wenn eine größere Entwicklung gezielt aus Releases herausgehalten werden soll. Dies wird nur in bestimmten Fällen benötigt und kann außerdem auch durch andere Maßnahmen ersetzt werden. Diese Branches sind daher optional.

Beispiel 1: Einzelne Anpassung abwickeln, Ende-zu-Ende

  1. Die Entwicklungsaufgabe liegt als entsprechendes Work Item vor. Es ist unerheblich, ob es sich um einen Bug oder ein PBI handelt.
  2. Entwickler/in legt einen mit dem Work Item verknüpften Arbeitsbranch dafür an (w/entwickler/0815-change-something), und zwar auf Basis vom Branch dev
  3. Entwicklung bis zum Pull Request w/entwickler/0815-change-something in dev
  4. Abschluss des Pull Request; Entwicklung ist nun in Branch dev
  5. Bereitststellen der Entwicklung zum Test. Dafür wird der dev-Branch entweder lokal kompiliert oder eine Release-Pipeline verwendet. In beiden Fällen sind die generierten App-Pakete in das Testsystem zu installieren.
  6. Nach Abnahme durch den Kunden wird ein production-Branch angelegt. Ggf. darin nun enthaltene, aber nicht für den Produktivbetrieb freigegebene Entwicklungen müssen dort entfernt werden.
  7. Der production-Branch wird entweder lokal kompiliert oder eine Release-Pipeline verwendet. In beiden Fällen sind die generierten App-Pakete in das Produktivsystem zu installieren.

In der vorangehenden Grafik entspricht dies dem Verlauf von w/...1 hin zu production/..1.

Beispiel 2: Mehrere parallele Anpassungen abwickeln (z.B. in einer Projektphase), Ende-zu-Ende

Grundsätzlich kann wie bei Einzelanpassungen gearbeitet werden. Es besteht aber keine Notwendigkeit, jede einzelne Entwicklung nach Fertigstellung auch produktiv auszurollen. Daher können Entwicklungen in dem dev-Branch "gesammelt" werden und auch gesammelt nach Abnahme in production überführt werden.

Die Entwickler schließen Ihre jeweiligen Work Items ab wie in Beispiel 1 beschrieben, allerdings jeweils nur bis zu dem Pull Request in den Branch dev (Schritt 4). Nach Abnahme bzw. Entscheidung für die Überführung kommen dann Schritt 5 ff. und dieselben Vorgänge wie in Beispiel 1.

In der vorangehenden Grafik entspricht dies dem Verlauf von w/...2, w/...3 und w/...4 hin zu production/..2.

Beispiel 3: Nicht alle Entwicklungen sollen ins Produktivsystem kommen

Es kommt vor, das sich im dev-Branch Entwicklungen befinden, die der Kunde noch nicht für den Produktivbetrieb abgenommen hat und parallel solche, die er nun im Produktivsystem haben möchte.

Zunächst einmal sollte diese Situation nach Möglichkeit vermieden werden. Im Normalfall, wenn es sich um beauftragte und fertiggestellte Anpassungen handelt, sollte mit dem Kunden die Abnahme aller fertigen Anpassungen erwirkt werden. Gelingt dies, ist man in der komfortableren Situation von Beispiel 2.

Ist es nicht zu vermeiden, wird folgendermaßen verfahren:

  1. production-Branch anlegen
  2. Identifizieren, welche Bestandteile des production-Branch nicht ausgeliefert werden sollen.
    1. Mit Glück sind einer oder mehrere Pull requests zu identifizieren, die heraus müssen. Diese können per revert aus dem production-Branch entfernt werden. Dies führt dann technisch zu einer Art Arbeitsbranch, mit der eine Änderung rückgängig gemacht wird.
    2. Mit Glück kann alternativ durch Ausblenden/Deaktivieren neuer Funktionen noch simpler eine "Entfernung" erwirkt werden. In dem Fall kann ein Arbeitsbranch von und nach dem production-Branch angelegt und die Änderung eingearbeitet werden.
    3. Im ungünstigsten Fall muss manuell entfernt werden, funktioniert wie der Punkt zuvor nur mit mehr zu leistender Arbeit.
  3. Nach der Vorbereitung des production-Branch dann weiter wie in Beispiel 1, Schritt 7.

In der vorangehenden Grafik entspricht dies dem verlauf von w/..5 und w/..6 hin zu production/..3 mit w/..7.

Beispiel 4: Eine komplexe Entwicklung, die nicht mit den restlichen Entwicklungen übernommen werden soll

Es kann in bestimmten Fällen vorkommen, dass ein ganzes neues Modul oder eine umfassende Änderung bestehender Module implementiert werden muss. So eine Aufgabe ist in der Regel selber in einzelne PBI unterteilt, die man aber nicht einzeln schon in dev zurückführen möchte. Das will man normalerweise nicht, da fachlich unfertige Lösungen in dev stören können wenn es um Bereitstellung ins Testsystem oder v. a. ums Anlegen neuer production-Branches geht. Teil-fertige Lösungen müssen dann in aller Regel aus dem Code wieder entfernt werden, was je nach Komplexität der neuen Lösung viel Arbeit machen kann.

  1. Ein Feature Branch wird angelegt und mit Policies eingerichtet
  2. Entwickler arbeiten analog Beispiel 2, allerdings legen sie Ihre Arbeitsbranches nicht auf Basis von dev an, sondern auf Basis des Feature-Branch. Zurückgeführt wird auch statt auf dev hier in den Feature Branch.
  3. Die Zurückführung in dev erfolgt nach Abschluss aller Entwicklungsaufgaben, indem ein Pull Request vom Feature Branch in den dev Branch vorgenommen wird. Hierfür wird temporär die Policy von dev umgestellt, und der Merge Typ "merge" anstelle von "squash" verwendet.

In der vorangehenden Grafik entspricht dies dem Verlauf von f/...1 mit w/...12 und w/...13 und w/..14.

In der Handhabung gibt es Besonderheiten, die beachtet werden müssen.

Nachmergen aus dev

Sobald während der Entwicklung in diesem Beispiel 4 der Bedarf entsteht, den Stand von dev in den aktuellen Feature-Branch nachzuziehen, wird ein Zwischenbranch verwendet.

  1. Ein Merge-Branch (m/..1) wird angelegt, ausgehend vom aktuellen Feature-Branch.
  2. Ein git Merge von dev in den Merge-Brach wird durchgeführt.
  3. für den Merge-Branch wird ein Pull Request zurück in den Feature-Branch angelegt. Dabei wird der PR so eingestellt, das ein Basic Merge und auf keinen Fall ein Squash Merge verwendet wird.

Rückführung in dev

Mit dem Abschluss der Entwicklungsarbeiten kommt der Punkt, an dem der Inhalt des Feature-Branch in den allgemeinen dev-Branch erfolgen muss. Dies erfolgt mit diesen Schritten:

  1. Ein git Merge vom aktuellen Feature-Branch in den dev-Brach wird durchgeführt. Dabei wird der PR so eingestellt, das ein Basic Merge und auf keinen Fall ein Squash Merge verwendet wird.
  2. Der Feature Branch wird nach Abschluss des PR manuell gelöscht. Dafür müssen zuvor seine Policies entfernt werden.

Namenskonventionen

Branch Konvention Beispiel
production/.. production/[Version] production/2021.1
w/... w/[ENTWICKLERKÜRZEL]/[KURZBESCHREIBUNG] w/musterm/define-naming-convention
dev dev dev
f/.. f/[KURZBESCHREIBUNG] f/combine-naming-convention-development
m/.. m/[ENTWICKLERKÜRZEL]/[KURZBESCHREIBUNG] w/musterm/merge-dev-to-f

Es werden nur Kleinbuchstaben verwendet!

Hinweis

In vielen Projekten hat sich für die Kurzbeschreibung in Arbeitsbranches bewährt, die Nummer des Work Item mit anzugeben. Das hilft v. a. bei der lokalen Suche nach dem richtigen Branch in VS Code. Beispiel w/entwickler/0815-change-something

×
Vergrößertes Bild