Spiegeln.md - Struktur und kleine Bugs

@feikens @koehler

Hallo Ihr 😄

Ich habe eben versucht die Anleitung zum Pull-Mirroring durchzuarbeiten und hatte dabei eine paar Probleme. Am Ende - und mit Unterstützung von deutlich fachkundigerem Personal als ich - war ich doch erfolgreich. Das Prinzip funktioniert also, aber ich glaube, die Anleitung könnte noch etwas besser werden. Und nur meckern ist ja langweilig, deswegen hier mein Vorschlag, was vielleicht helfen könnte.

Ich fang mit dem einfachen an:

"Bugs"

1. Einrückung in .gitlab-ci.yml

Beim einfügen des Codes gibt es Fehler, die Einrückungen in Zeile 2 und 3 stimmen nicht ganz. Da fehlen 3(?) Leerzeichen.

2. Geschützer Branch

Der neu erstelle Branch ist geschützt. Ich muss erst unter Repository - geschützte Branches den Schutz löschen. Der Schalter Push erzwingen zulassen alleine reicht nicht.

3. Variablen Schützen

Wenn der Branch dann ungeschützt ist, müssen die CI/CD-Variablen noch das Flag Variable Schützen deaktivieren.

Erst danach funktionierte das pull mirroring.

Struktur

Ich hatte aber auch einige Mühen, dem Text an sich zu folgen. Ich glaube das hatte zwei Ursachen:

  1. Die Verwendung von Ziel und Ausgang ist verwirrend und evtl. nicht durchgängig verwendet.
  2. Ich erwarte die Erklärung für von A nach B kopieren, in Wirklichkeit ist es aber ein von A nach B, nach C kopieren.

Um diese Schwierigkeiten zu beheben, würde ich - zum anpassen der Erklärung - den Task gedanklich aufteilen in:

1. Quelle / Ziel

  • Ganz untechnisch: Eine Quelle hat immer schon etwas. Ein Ziel hat es noch nicht, da soll es hin. Wir wollen also etwas aus einem Quell-Repo zu uns kopieren/spiegeln. Damit wäre in der .gitlab-ci.yml die Variable auch die origin-URL

2. Richtung

  • Wenn die Orte geklärt sind, ist die Frage: Schiebe ich es oder ziehe ich es?"
    • ziehen: Das Ziel sagt, "Quelle, gib her."
    • schieben: Die Quelle sagt, "Ziel, hier nimm."

Damit ließe ich Push-Mirroring in unserem Fall gut erklären.

Wir haben aber nicht den Zweierschritt von A nach B gehen, wenn wir ein Pull-Mirroring durchführen. Deswegen würde ich erst erklären, dass ein Umweg gebaut wird, indem wir eine VM im Ziel-Gitlab starten, die das Ziehen für uns übernimmt und die Daten von dort dann in einem weiteren Schritt in unser Repo pusht - von A nach B nach C. Wobei B und C beides im Zielsystem stattfindet.

Die aktuelle Anleitung erinnert mich in Ihrer Struktur an oldschool "Klickweg-Erklärungen", die auch jemand ohne viel Hintergrundwissen abarbeiten kann. Was gut ist, die Zielgruppe wollen wir ja auch erreichen. Dieser Mensch hat am Ende aber nicht viel dazu gelernt.

Dieses Prinzip ist in meinen Augen, ein wichtiger Grundstein im "Wie wir es in Sachen Digitalisierung in den letzten 20 Jahren zum Status Quo geschafft haben." Wenn die Anleitung zuerst das Wo und wie erklärt und dann einen kurzen Überblick über die logischen Schritte gibt, geben wir den Menschen auch eine viel bessere Chance, nicht nur zu machen, sondern auch zu verstehen.

#ContextIsKing 😎

Ich bin gespannt, was Ihr dazu denkt.

Mit bestem Gruß

Jörg

Edited by Jörg Brüggemann