Build-Prozess mit Jenkins, SVN -> Builden alter Versionsstände von 3 Repos

[TiGü]

Hallo Schwarmintelligenz,

ich wollte mal euren Rat einholen und erfahren, wie das woanders gelöst wird.

Ich führe gerade in meiner neuen Firma einen Build-Prozess mit Jenkins ein. Die Delphi-Projekte baue ich über MSBUILD.
Historisch bedingt nutzen wir SVN als Versionsverwaltung (VisualSVN und als Clients TortoiseSVN) und zur Entwicklung z.Z. Delphi XE5.

Für mein Problem möchte ich drei Repositories vorstellen:

• Wir haben ein Hauptprogramm mit eigenen Repository:
  https://mycompanysvn/FooBar/trunk/V3.0
  Normalerweise checken wir Entwickler alle lokal nach "C:\Projekte\FooBar 3.0" aus.
  
• Dazu kommen noch verschiedene DLLs, die hier liegen (historisch bedingt in /branches):
  https://mycompanysvn/Tools/branches/R3951
  Hier ist der übliche Ordner "C:\Projekte\Tools".
  
• Des Weitern pflegen wir für unser Hauptprogramm noch eigene visuelle Komponenten:
  https://mycompanysvn/Komponenten/branches/R051
  -> "C:\Projekte\Komponenten"

Im Folgenden nutze ich die absoluten Pfade auf einen normalen Entwickler-Rechner, damit man gedanklich leichter folgen kann:

In "C:\Projekte\FooBar 3.0\develop\_XE5" liegt ein Gruppenprojekt (FooBar_Group.groupproj).
Das beihaltet FooBar.dproj aus dem gleichen Unterordner und auch verschiedene DLL-Projekte aus "C:\Projekte\Tools".

Das Builden in Debug Win32 nach jedem Einchecken, um auf vergessene Units zu prüfen stellt kein Problem da (Jenkins pollt alle 5 Minuten auf Änderung).
Auch der Nightly Build der aktuellsten Sourcen in Release Win64 mit übersetzen per Sisulizer und das Packen des Setups stellt keine Hürde dar.

Interssant wirds jetzt erst, wenn man auf Zuruf einen reproduzierbaren Build von dem Stand vor z.B drei Wochen haben möchte.
Hier ist es im Moment so, dass nach dem bisher händischen Erstellen eines Releases die SVN-Revision des Hauptprogramms getaggt wird.
Sie lässt sich dann bspw. so im SVN finden: https://mycompanysvn/FooBar/tags/Freigaben/V3.0.004.0
Hier ist aber nur der Stand des Hauptprogramms zu finden, nicht das was unter Tools und Komponenten zu finden ist.

Wie ist der allgemein übliche Weg, um die Abhängigkeiten in Zeit (Datum, Uhrzeit) bzw. SVN-Revisionsnummer zwischen drei verschiedenen Repositories zu managen?

1. Mein erster Gedanke war, einen parametrierbaren Build zu erstellen, der sechs Eingabefelder hat.
Pro Repository ein für die SVN-URL und ein optionales String-Eingabefeld für die Revsionsnummer.
Da muss man aber ziemlich viel im SVN-Log nachgucken, was wann wie zusammmengehört und ist so bspw. für externe Abteilungen unbenutzbar.
Während ich den Zusammenhang zwischen SVN-Log, drei Repositories und SVN-Revisionsnummer von den Entwicklern verlangen kann, sieht es da beim Produktmanagment schon anders aus.
Wenn die einen bestimmten Versionsstand brauchen, sollte das für die Kollegen relativ straight forward sein, ohne groß Nachfragen zu müssen.

2. Dann kam noch die Idee auf, die Abhängigkeiten im Hauptprogramm als Textdatei/Batchdatei zu hinterlegen.
Diese wird während des Build-Prozesses ausgelesen und anhand der darin definierten Werte werden die Abhängigkeiten aufgelöst.
Also bspw. ist die SVN-Revisionsnummer für "Tools" und "Komponenten" im aktuellsten Fall -1, so dass diese Repositories auf den neusten Stand ausgecheckt werden.
Wenn man aber bspw. etwas baut mit dem oben erwähnten Tag "V3.0.004.0", dann muss derjenige Entwickler, der den Branch angelegt hat, die SVN-Revisionsnummern für "Tools" und "Komponenten" auf den damals definierten Stand setzen (SET Tools_SVN_Revision=8123; SET Komponenten_SVN_Revision=427).

Code:

$ svn checkout https://mycompanysvn/Tools/branches/R3951@8123
$ svn checkout https://mycompanysvn/Komponenten/branches/R051@427

Ich vermute und hoffe, es gibt noch andere Möglichkeiten und Wege, die mithilfe von SVN und Jenkins gelöst werden können.

Sollte irgendwas unklar sein in meiner Schilderung, bitte ich um Rückfragen.

Wie ist eure "Best Practice", wie löst ihr das in eurem Build-Prozess?

[freimatz]

Der allgemein richtige Weg, um die Abhängigkeiten in Zeit (Datum, Uhrzeit) bzw. SVN-Revisionsnummer zwischen drei verschiedenen Repositories zu managen ist
a) Die Repos auf git umzustellen
b) die abhängigen Repos als Submodule einzubinden in die Repos wo man sie braucht.
(Alternativ kann man noch alle Projekte mit einem Paketmanager verwalten lassen.)

Was der allgemein übliche Weg ist kann ich dir leidern nicht sagen, da ich extrem wenige Firmen kenne die überhaupt solche Abhängigkeiten haben. Ich fürchte dass man allgemein üblich - wie leider auch bei uns - irgend so nen Murks macht wie du es vorschlägst. SCNR

[TiGü]

Zitat:

Zitat von freimatz (Beitrag 1455342)

Was der allgemein übliche Weg ist kann ich dir leidern nicht sagen, da ich extrem wenige Firmen kenne die überhaupt solche Abhängigkeiten haben. Ich fürchte dass man allgemein üblich - wie leider auch bei uns - irgend so nen Murks macht wie du es vorschlägst. SCNR

Würde es dir etwas ausmachen, jemanden Wissenden bei dir in der Firma zu fragen?

[Uwe Raabe]

Wie wäre es denn, wenn man die jeweils verwendeten Tools- und Komponenten-Repoversionen bei einem Release des FooBar Hauptprogramms mit dem gleichen Tag "V3.0.004.0" markiert? Eventuell noch ergänzt um den Namen des Hauptprojekts, also "FooBar V3.0.004.0".

[TiGü]

Zitat:

Zitat von Uwe Raabe (Beitrag 1455349)

Wie wäre es denn, wenn man die jeweils verwendeten Tools- und Komponenten-Repoversionen bei einem Release des FooBar Hauptprogramms mit dem gleichen Tag "V3.0.004.0" markiert? Eventuell noch ergänzt um den Namen des Hauptprojekts, also "FooBar V3.0.004.0".

Angenommen, man würde das so machen:
Würde das vom SVN dann so aufgelöst werden, dass das zukünftige Beispiel "V3.0.005.0" mit den drei getaggten Repos:

• https://mycompanysvn/FooBar/tags/Freigaben/V3.0.005.0
• https://mycompanysvn/Tools/tags/Freigaben/V3.0.005.0
• https://mycompanysvn/Komponenten/tag...ben/V3.0.005.0

...dann beim Auschecken von Jenkins in SVN über den parametrierten Build mit dem SVN-Tag "V3.0.005.0" alle drei Repos von diesem Versionsstand/Datum&Uhrzeit geholt werden?

[Uwe Raabe]

Zitat:

Zitat von TiGü (Beitrag 1455350)

...dann beim Auschecken von Jenkins in SVN über den parametrierten Build mit dem SVN-Tag "V3.0.005.0" alle drei Repos von diesem Versionsstand/Datum&Uhrzeit geholt werden?

Ich bin jetzt nicht so fit in Jenkins, aber das sollte eigentlich möglich sein. Aktuell müsst ihr ja auch die URLs für die benötigten Repos festlegen. Ich denke schon, daß man bei Angabe des Revisions-Parameters diesen auf die anderen Repos anwenden kann.

[TigerLilly]

SVN Externals sind doch für genau sowas gedacht:
https://tortoisesvn.net/docs/release...externals.html

Wir haben unsere 3rdParty Libs in eigenen Repositories + halten das über Externals mit unserem Code in sync.

[freimatz]

Das ist wohl so was ähnliches wie bei git die Submodule

Zitat:

Zitat von TiGü (Beitrag 1455345)

Zitat:

Zitat von freimatz (Beitrag 1455342)

Was der allgemein übliche Weg ist kann ich dir leidern nicht sagen, da ich extrem wenige Firmen kenne die überhaupt solche Abhängigkeiten haben. Ich fürchte dass man allgemein üblich - wie leider auch bei uns - irgend so nen Murks macht wie du es vorschlägst. SCNR

Würde es dir etwas ausmachen, jemanden Wissenden bei dir in der Firma zu fragen?

Derjenige ist heute wieder vom Urlaub zurück. Also: wir haben ein Hauptrepository und dazugehöriges Zeug, das in SVN-Repos ist.
Es gibt ein buildsystem und da gibt es eine SVHCheckout.bat. Diese ist im git-Haupt-Repo versioniert. In dieser Batch stehen die SVN-Checkout-Kommandos drin mit den jeweiligen branches.