Was genau sind „wirklich reproduzierbare Builds“?

Was genau sind sie? Warum sind sie im Bereich der kontinuierlichen Lieferung wichtig?

Kontext: Ich habe in einem der Kommentare von (ich denke reddit) gesehen, dass wirklich reproduzierbare Builds immer noch eine unterforschte Technologie sind und sehr schwer zu erstellen sind.

Also wollte ich wissen, warum sie so schwer zu erstellen sind?

Was genau sind sie?

Hier ist ein Zitat von reproducible-builds.org :

Reproduzierbare Builds sind eine Reihe von Softwareentwicklungsmethoden, die einen überprüfbaren Pfad vom lesbaren Quellcode zum von Computern verwendeten Binärcode erstellen.

Warum sind sie wichtig?

IMO Der einfachste Weg, ihre Bedeutung zu erklären, besteht darin, sie als Variation eines Sicherungsvorgangs zu betrachten.

Als Beispiel:

• Angenommen, ein Unternehmen verwendet (hängt davon ab) ein Softwarepaket, das von einem Softwareanbieter lizenziert wurde. Während das Unternehmen nur die ausführbaren Dateien erhält, nicht die Quellen usw., die zum Erstellen dieser ausführbaren Dateien verwendet wurden.

• Alles läuft gut, aber irgendwann geht etwas mit dem Softwareanbieter schief, z. B. gehen sie aus dem Geschäft (z. B. Bankrott).

• Dies kann (auf lange Sicht) ein Risiko für das Unternehmen darstellen. Dh wenn es kein Verfahren / keine Vereinbarung für das Unternehmen gibt, um (legalen) Zugriff auf alle erforderlichen Quellen, Dokumentationen, Erstellungsverfahren usw. zu erhalten, die sich auf irgendetwas vom Softwareanbieter beziehen, der (damals) verwendet wurde, als die ausführbaren Dateien (von das Geschäft) wurden erstellt (und an das Geschäft geliefert).

• Hier kommt " Software Escrow " zum Einsatz: Wenn eine solche Vereinbarung besteht, könnte man meinen, dass das Unternehmen über einen Dritten immer noch Zugang zu " was auch immer verwendet wurde " erhält , um reproduzieren zu können die ausführbaren Dateien, so dass das Unternehmen von nun an möglicherweise die Möglichkeit hat, diese Software weiter zu verwenden, und wo es angemessen ist, sie selbst zu warten (nur um sein eigenes Unternehmen zu führen).

• Das " was auch immer verwendet wurde " in der vorherigen Kugel ist jedoch der schwierigste Teil, um diese Arbeit zu machen. Es erfordert, dass der Dritte im Voraus entsprechende Validierungen durchführt. Und glauben Sie mir, es dauert eine Weile, bis Sie eine ausführbare Datei neu erstellen können, für die Sie nachweisen können, dass sie, abgesehen von (z. B.) dem Linkdatum, perfekt zu dem passt, was der Softwareanbieter dem Software-Agenten liefert.

Und warum sind sie so schwer zu erstellen?

Wenn das obige Beispiel immer noch nicht klar genug ist, stellen Sie sich vor, Sie sind mein Software-Treuhandagent, und teilen Sie mir mit, was Sie als Eingabe benötigen, um eine Kopie der von meinem Kunden lizenzierten Software neu zu erstellen. Kapiert? Sie haben nicht vergessen zu überprüfen, welche Version meines Compilers, möglicherweise mein Betriebssystem, Kompilierungs- / Linkoptionen, Versionen wiederverwendbarer Komponenten (einschließlich), Bibliotheken usw.?

Um ein praktisches Beispiel für einen Versuch zu liefern, einen wirklich wiederholbaren Build zu erstellen, beachten Sie Folgendes:

Eine Build-Pipeline, die mit einem Git-Repository beginnt, für das kein Benutzer jemals einen Verlauf neu schreiben oder nicht zusammengeführte Zweige löschen kann.

Der erste "Build" -Schritt nach dem Auschecken des Quellcodes besteht darin, einen Container hochzufahren, der alle Build-Zeit-Abhängigkeiten enthält.

Die Ausgabe des laufenden Build-Time-Containers ist ein Container, der die kompilierte Binärdatei enthält.

Wichtiger für die Wiederholbarkeit des Builds sind die folgenden Tags, die dem endgültigen Container hinzugefügt werden:

• Der genaue Hash des Quellcodes im ursprünglichen Repository und die URL des Git-Repos sowie ein Teerball-Snapshot des Codes, der in ein Artefakt-Repository hochgeladen wird.
• Die genaue Version des Build-Containers, mit dem der Build ausgeführt wurde.
• Die genaue Version des ursprünglichen Basisabbilds, in das die Binärdatei geladen wurde.
• Die Werte aller Build-Time-Variablen, die zum Erstellen der Binärdatei verwendet werden.
• Die Docker-Version, mit der alle drei Container erstellt wurden, sowie die Version, unter der sie beim Erstellen ausgeführt wurden.

Durch Hinzufügen all dieser Metadaten können wir sicherstellen, dass wir zu jedem Zeitpunkt in der Zukunft den genauen Satz von Build-Abhängigkeiten (über den Build-Container) abrufen und die Binärdatei mit einem genau bekannten Satz von Schritten kompilieren können (der im Build-Container verankert ist) ) und packen Sie dies in ein anderes bekanntes Basis-Image mit allen Laufzeitabhängigkeiten (unter Verwendung des Basis-Image-Tags). Dies kann alles auf der exakt korrekten Version des Quellcodes basieren, basierend auf dem Tag auf dem Container.

Theoretisch sollte dies uns die Möglichkeit geben, eine Build-Version exakt zu reproduzieren.

Dies ist wichtig, damit wir sehen können, was in der Produktion läuft, und selbst wenn die Versionen erheblich weiterentwickelt wurden, die ursprünglich verwendete Version von Code, Basisimage und Build-Container zurückziehen können, damit wir dies beispielsweise können Wenden Sie vor dem erneuten Erstellen genau wie zuvor einen Hotfix auf diese Version an, damit wir erneut bereitstellen können, da wir wissen, dass es sich genau um dasselbe Artefakt handelt und das einzige Delta der Hotfix ist.