Was Artefakte zu speichern für einen nightly-build?

https://stackoverflow.com/questions/230595

04-07-2019
|

Frage

Davon ausgehen, dass ich ein automatische nightly-build.Welche Artefakte von der build sollte ich sparen?

Zum Beispiel:

Input source code
Ausgabe von Binärdateien

Auch, wie lange sollte ich speichern Sie Sie, und wo?

Machen Sie Ihre Antworten ändern, wenn ich tun die Kontinuierliche Integration?

Lösung

Hier sind einige Artefakte / Informationen, die ich gewohnt bin bei jedem Build zu halten:

Der Tag-Name des Schnappschusses Sie bauen (Tag und machen einen sauberen Kasse vor Sie bauen)
Die Build-Skripte themselfs oder deren Versionsnummer
Die Ausgabe des Build-Skript: Protokolle und Endprodukt
Eine Momentaufnahme Ihrer Umgebung:
- Compiler-Version
- Build-Tool Version
- Bibliotheken und DLL / libs Versionen
- Datenbankversion (Client & Server)
- ide Version
- Skript-Interpreter Version
- OS-Version
- Quellcodeverwaltung Version (Client und Server)
- Versionen anderer Werkzeuge in den Prozess und alles andere verwendet, die könnte , um den Inhalt Ihrer Build-Produkte beeinflussen. Ich tue dies in der Regel mit einem Skript, das alle diese Informationen abfragt und protokolliert sie in eine Textdatei, die mit den anderen Build-Artefakte gespeichert werden sollen.

Stellen Sie sich diese Frage: „Wenn etwas ganz mein build / Entwicklungsumgebung zerstört, welche Informationen würde ich ein neuen erstellen müssen, damit ich meine Build # 6547 wiederholen und mit dem exakt gleichen Ergebnis am Ende ich das erste Mal bekam? „

Ihre Antwort ist, was Sie bei jedem Build halten sollen, und es wird eine Untergruppe oder über die Dinge, die ich bereits erwähnt sein.

Sie können alles in Ihrem SCM speichern (ich würde ein separates Repository empfehlen), aber in diesem Fall Ihre Frage auf, wie lange Sie die Einzelteile halten sollen verliert Sinn. Oder sollten Sie sie speichern, Ordner Reißverschluss oder eine CD / DVD mit dem Build-Ergebnis und Artefakte zu verbrennen. Was auch immer Sie wählen, haben Sie eine Sicherungskopie.

Sie sollten sie speichern, so lange, wie Sie sie benötigen. Wie lange, hängt von Ihrem Entwicklungsteam Tempo und Ihre Release-Zyklus.

Und nein, ich glaube nicht, es ändert sich, wenn Sie Kontinuierliche Integration zu tun.

Andere Tipps

Sie sollten nicht alles sparen um des Sparens Willen ist es.speichern Sie es, weil Sie es brauchen (D. H., QA verwendet nightly builds zu testen).An dem Punkt, "wie lange speichern" wird jedoch lange QA-Sie haben will.

ich würde nicht "save" source code so viel wie der tag/das Etikett.Ich weiß nicht, was die Quellcodeverwaltung Sie verwenden, aber die Markierung ist trivial (performance und Speicherplatz), für jede Qualität-source-control-system.Sobald Ihr build wird markiert, es sei denn, Sie müssen die Binärdateien, es gibt wirklich keinen Vorteil, nur mit Ihnen um, denn Sie können einfach neu kompilieren, wenn nötig, von der Quelle.

Die meisten CI-tools können Sie Tags auf jedem erfolgreichen build.Dies kann problematisch werden, für einige Systeme, wie Sie können leicht haben 100+ tags ein Tag.Für solche Fälle empfehle ich, die immer noch ein nightly-build und nur taggen, dass.

Dies ist keine direkte Antwort auf Ihre Frage, aber vergessen Sie nicht auf der Version selbst den Nightly-Build-Setup steuern. Wenn die Projektstruktur ändert, können Sie den Erstellungsprozess ändern müssen, die brechen ältere von diesem Punkt baut auf.

Neben den Binärdateien wie alle anderen erwähnt würde ich empfehlen, eine Symbolserver und ein Quellserver und sicherstellen, dass Sie erhalten die richtigen Informationen aus und in diese. Es wird enorm bei der Fehlersuche unterstützen.

Wir speichern die Binärdateien, gestrippt und unstripped (so haben wir die genau gleiche binäre, einmal mit und einmal ohne Debug-Symbole). Weiterhin bauen wir alles zweimal, einmal mit aktiviertem Debug-Ausgabe und einmal ohne (wieder abgezogen und unstripped, so jedes Build-Ergebnis in 4 Binaries). Der Build wird in einem Verzeichnis gespeichert nach SVN-Revisionsnummer. Auf diese Weise können wir die Quelle aus der SVN-Repository immer behalten, indem Sie einfach diese sehr Revision Check-out (auf diese Weise die Quelle als auch archiviert wird).

Eine überraschende, den ich über vor kurzem gelernt. Wenn Sie in einer Umgebung sind, die Sie wollen, werden geprüft könnte werden alle die Ausgabe des Builds zu speichern, die Skript-Ausgabe, der Compiler-Ausgang, etc

Das ist die einzige Art und Weise Sie Ihre Compiler-Einstellungen überprüfen können, bauen Schritte, etc.

Auch, wie lange sie für speichern, und wo sie zu retten?

Sie sparen, bis Sie das Build nicht wissen, die Produktion gehen, IOW, solange Sie die kompilierten Bits um.

Ein logischer Ort zu speichern, um sie Ihr SCM-System. Eine weitere Option ist ein Werkzeug zu verwenden, die sie automatisch für Sie sparen, wie AnthillPro und seine ilk.

Wir tun etwas in der Nähe „embedded“ Entwicklung hier, und ich kann Ihnen sagen, was wir speichern:

die SVN-Revisionsnummer und Zeitstempel sowie die Maschine auf und von wem (auch verbrannt in die Build-Binärdateien)
ein vollständiges Buildprotokoll, das zeigt, ob es eine vollständige / inkrementelle Build war, all interessante (STDERR) Ausgabe der Daten Backenwerkzeuge hergestellt, um eine Liste von Dateien kompilierten und alle Compiler-Warnungen (diese komprimieren sehr gut, wobei Text)
die eigentlichen Binärdateien (für überall von 1 bis 8 Build-Konfigurationen)
Dateien als Nebeneffekt erzeugen die Verknüpfung: eine Linker Befehlsdatei, Adresse Karte, und eine Art „manifest“ Datei angibt, was in die letzten Binärdateien (CRC und Größe für jeden) verbrannt wurde, sowie die Debug-Datenbank (PDB-Äquivalent)

Wir versenden auch über das Ergebnis der einige Werkzeuge über die „Nebeneffekt“ Dateien an interessierte Benutzer ausgeführt wird. Wir archiviere nicht eigentlich diese, da wir sie später nicht wiedergeben kann, aber diese Berichte enthalten:

Gesamt und Delta von Dateisystemgröße, aufgeschlüsselt nach Dateityp und / oder das Verzeichnis
Gesamt und Delta Codeabschnittsgrößen (.text, .data .rodata, .bss, .sinit, etc.)

Wenn wir Unit-Tests oder Funktionstests haben (zum Beispiel Rauchversuche) läuft, zeigen diese Ergebnisse im Buildprotokoll auf.

Wir haben noch nichts weggeworfen -. Gegeben, unser Ziel in der Regel Builds bei ~ 16 oder 32 MiB pro Konfiguration am Ende, und sie sind ziemlich komprimierbar

Wir tun halten unkomprimierte Kopien der Binärdateien um für 1 Woche für einen leichten Zugang; Danach halten wir nur die leicht komprimierte Version. Etwa einmal im Monat haben wir ein Skript, das jeden .zip extrahiert, dass der Build-Prozess produziert und 7-Reißverschluss ein ganzer Monat von Build zusammen ausgibt (der Vorteil dauert nur mit geringen Unterschieden pro Build).

Ein durchschnittlicher Tag vielleicht ein Dutzend oder zwei Builds pro Projekt ... Die Build wacht über alle 5 Minuten für relevante Unterschiede zu überprüfen und baut. Eine vollständige .7z auf einem großen sehr aktives Projekt für einen Monat könnte 7-10GiB sein, aber es ist sicherlich erschwinglich.

In den meisten Fällen haben wir in der Lage gewesen, alles auf diese Weise zu diagnostizieren. Gelegentlich gibt es einen Schluckauf auf dem Buildsystem und eine Datei ist nicht wirklich eine der Revision es angenommen hat, zu sein, wenn ein Build passiert, aber es gibt in der Regel genügend Beweise für diese in den Protokollen. Manchmal müssen wir ein Werkzeug, ausgraben, die das Debugging-Datenbank-Format versteht und ihn ein paar Adressen einen Absturz zu diagnostizieren (wir haben automatische stackdumps in das Produkt eingebaut). Aber in der Regel die alle erforderlichen Informationen, um da ist.

Wir haben nicht zu knacken die .7z Archive noch zu erwähnen haben. Aber wir haben die Informationen dort, und ich habe einige interessante Ideen, wie Bit Nutzdaten von ihm verminen.

Speicher, was nicht leicht reproduziert werden. Ich arbeite auf FPGAs, wo nur das FPGA-Team die Werkzeuge und einige Kerne (Bibliotheken) des Designs auf nur eine Maschine zu kompilieren sind lizenziert hat. Also haben wir die Ausgabe Bitströme speichern. Aber versuchen, sie über eine überprüfen andere statt mit einem Datum / Zeit / Versionsstempel.

Speichern unter in Schach in Quellcodeverwaltung oder einfach nur auf der Festplatte? Speichern Sie nichts zu Quellcodeverwaltung. Alle abgeleiteten Dateien im Dateisystem und für Entwickler sichtbar. Nicht checkin Binärdateien, Code aus XML-Dateien erzeugt, Nachricht verdaut etc. Ein separater Verpackungsschritt werden diese Endprodukte zur Verfügung stellen. Wie Sie die Änderungsnummer haben, können Sie immer die Build reproduzieren, wenn nötig natürlich alles vorausgesetzt, Sie benötigen ein Build ist vollständig in dem Baum zu tun und ist für alle verfügbar von Syncing baut.

würde ich Ihre gebaut Binärdateien für genau so lange speichern, wie sie eine Chance, in Produktion zu gehen oder von einem anderen Team verwendet werden (wie eine QA-Gruppe). Sobald etwas Produktion verlassen hat, was man damit tun viel variieren kann. Für viele Teams, werden sie halten gerade ihre neuesten Stand zu bauen um (für Rollback) und ansonsten verwerfen ihre Builds.

Andere haben regulatorischen Anforderungen etwas zu halten, die in die Produktion so lange wie 7 Jahre ging um (Banken). Wenn Sie ein Produkt-Unternehmen sind, würde ich um jede binäre halten ein Kunde könnte ein Tech-Support-Typ im Fall installiert haben möchte, die gleiche Version installieren.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow