wo man Build-Schnappschüsse in svn aufbewahrt

Question

Wir müssen die Build-Ausgabe unseres Projekts (in unserem Fall eine einzelne ausführbare Datei von ca. 1 MB Größe) auf kontrollierte Weise archivieren.

注 Die praktische Konsequenz daraus ist, dass ich für jede freigegebene Build-Ausgabe eine unveränderliche Kopie davon auf unbestimmte Zeit archivieren muss. (z.B. wenn wir von r993, r1014, r1205 und r1293 unseres Quellbaums bauen, muss ich für jeden eine Build-Ausgabe aufbewahren).

Für uns ist es selbstverständlich, Subversion dafür zu verwenden, da wir einen Server haben. Was unnatürlich ist, ist die Frage, wo wir die Build-Ausgabe ablegen.

1. Einen Bereich des Quellbaums überprüfen --> nicht gut, weil es Aktualisierungen/Zusammenführungen/etc. erschwert.

2. Erstellen eines speziellen Bereichs im Repository, der mit dem Quellbaum verbunden ist z.B.:

   project-foo/
     branches/
     tags/
     trunk/
     build/        <-- released executables go here
                   (along with metadata containing source references)

   Wir brauchen eigentlich keine Zweige oder Tags für die ausführbare Ausgabe; ich brauche nur einen Ort, der ein unveränderlicher Schnappschuss ist, auf den ich verweisen kann (im Fall von SVN durch Pfad und Rev #)

3. Erstellen eines speziellen Bereichs im Repository, der lose mit dem Quellbaum verbunden ist z.B.:

   project-foo/
     branches/
     tags/
     trunk/
   project-foo-build/          <-- released executables go into a subdir:
     branches/
     tags/
     trunk/

4. Verwenden Sie ein anderes Programm als SVN. ??? Was auch immer es ist, es muss die Ideen von

   • unveränderbare Daten
   • mit den Daten verbundene Metadaten
   • mehrere Versionen derselben Sache (z. B. die ausführbare Datei für das Projekt foo)

Irgendwelche Vorschläge?

Ich tendiere zu Idee Nr. 2, wollte aber einen Schritt zurücktreten und ein besseres Gefühl für die verschiedenen Vor- und Nachteile bekommen.

---

*Wir müssen dies tun, weil wir die genau Build-Ausgabe, die unter bestimmten Umständen verwendet wurde. Dabei handelt es sich um eingebetteten Code, der in die Hardware geladen wird. Im Idealfall ist die Build-Ausgabe eine wiederholbare Funktion des Quellbaums, d. h. wenn Sie zweimal mit demselben Quellbaum bauen, wird die gleiche Ausgabe erzeugt. Leider besteht das Risiko, dass dies nicht der Fall ist, z. B. wenn Compiler oder andere Build-Tools aktualisiert werden.

Answer 1

Sie müssen die Daten nicht speichern. aktuell Dateien im Subversion-Repository, um sie mit einem angemessenen Maß an Vertrauen zu verfolgen. Sie können die Ausgabedatei(en) erstellen, einen Hash (z. B. SHA1) des Dateiinhalts berechnen und dann den Dateinamen und den Hash-Wert im Projektarchiv speichern.

Solange Ihre Ausgabedateien mindestens auf dem gleichen Niveau wie Ihr Subversion-Repository gesichert sind, so dass Sie sie nicht verlieren, können Sie (in einem vernünftigen Rahmen) sicher sein, dass die angegebene(n) Datei(en) die vom Build erzeugte Ausgabe zu dem Zeitpunkt war(en), als Sie den Hash aufgezeichnet haben.

Answer 2

Mehrere Ihrer Optionen würden gut funktionieren, aber ich würde für Nr. 4 stimmen.

Mein Unternehmen erstellt und veröffentlicht auch eingebettete SW-Pakete, und wir benötigen die Speicherung der tatsächlichen Binärdateien, die wir liefern (zusammen mit der Build-Dokumentation, verschiedenen Ausgabedateiformaten usw.), zusätzlich zur Kennzeichnung der SW-Revision im Repository.

Ich stimme der Antwort von Greg Hewgill zu, sie auf einem Dateiserver in einem eigenen Verzeichnis abzulegen. Wenn Sie jedoch ein umfassenderes SCM-Tool suchen, sollten Sie sich für ein anderes entscheiden, Redmine ist eine großartige Open-Source-Option. Redmine bietet SVN (oder Hg, Git, etc...) Bindungen, Problemverfolgung, Dateiverwaltung, und so weiter. Es ist nicht nur ein Datei-Repository, sondern ein umfassenderes SCM-Tool.

Außerdem hat wikipedia eine umfassende Liste von SCM-Tools , von denen viele leicht als Instrument zur Speicherung von Lieferungen konfiguriert werden können.

Answer 3

Sie können den Bau durchführen, svn add die Binärdateien in Ihre Arbeitskopie, und markieren Sie dann direkt von Ihrer Arbeitskopie :

build.bat
svn add bin\*
svn cp . http://example.com/svn/myproject/tags/x.y -m "tagging release x.y"
svn revert -R .

Auf diese Weise erscheinen die Binärdateien in Ihren Release-Tags, aber niemals im Stamm.

Beachten Sie die svn revert am Ende. Dies ist notwendig, weil svn status zeigt weiterhin die Änderungen, die durch svn add . Sie wollen diese Änderungen im Stammverzeichnis nicht.

Answer 4

Wie Sie sagen, ist es unnatürlich, SVN für Build-Produkte zu verwenden, da es gute Praxis ist, nur den Quellcode in Ihrem Repository zu haben. Sie sollten die Build-Ausgabe besser eindeutig benennen (project-branch-revision), benannt nach Ihrem Build-Prozess, und die Build-Ausgabe auf klassische Weise archivieren (Dateiserver).