Cosa sono esattamente le "build veramente riproducibili"?

Che cosa sono esattamente? Perché sono importanti nel dominio della consegna continua?

Contesto: ho visto in uno dei commenti di (immagino reddit) che le build veramente riproducibili sono ancora una tecnologia sotto ricerca ed è molto difficile da creare.

Quindi, volevo sapere perché sono così difficili da creare?

Che cosa sono esattamente?

Ecco una citazione da riproducible-builds.org :

Le build riproducibili sono un insieme di pratiche di sviluppo software che creano un percorso verificabile dal codice sorgente leggibile dall'uomo al codice binario utilizzato dai computer.

Perché sono importanti?

L'IMO il modo più semplice per spiegarne l'importanza è considerarli come una variazione di una procedura di backup.

Come esempio:

• Supponiamo che un'azienda utilizzi (dipende) da alcuni pacchetti software concessi in licenza da alcuni fornitori di software. Considerando che l'azienda ottiene solo gli eseguibili, non le fonti, ecc. Che sono stati utilizzati per creare tali eseguibili.

• Tutto va bene, ma a un certo punto qualcosa va storto con il fornitore del software, ad es. Falliscono (es. Bancarotta).

• Ciò può esporre un rischio per l'azienda (a lungo termine). Vale a dire se non è in atto alcuna procedura / accordo per consentire all'azienda di ottenere (legale) l'accesso a tutte le fonti richieste, la documentazione, le procedure di creazione, ecc. Relative a qualsiasi cosa proveniente dal fornitore del software utilizzato (nei giorni precedenti) quando gli eseguibili (utilizzati da l'attività) sono stati creati (e spediti all'azienda).

• Ecco dove " Software Escrow " viene in soccorso: se esiste un accordo di questo tipo, si potrebbe pensare che tramite una terza parte, sarebbe ancora possibile per l'azienda avere accesso a " tutto ciò che è stato usato " per poter riprodurre gli eseguibili, in modo che da quel momento in poi l'azienda possa avere la possibilità di continuare a utilizzare quel software e laddove appropriato inizia a gestirlo da solo (solo per gestire la propria attività).

• Tuttavia, " qualunque cosa sia stata usata " nel proiettile precedente è la parte più difficile per farlo funzionare. Richiede che la terza parte esegua in anticipo le convalide appropriate. E credetemi, ci vuole un po 'di tempo prima di poter ricreare un eseguibile per il quale è possibile dimostrare che, a parte (ad esempio) la data del collegamento, è una corrispondenza perfetta con ciò che il fornitore del software consegna all'agente software.

E perché sono così difficili da creare?

Se l'esempio sopra non è ancora abbastanza chiaro, immagina di essere il mio agente di deposito a garanzia del software, dimmi di cosa hai bisogno come input per ricreare una copia del software concesso in licenza dal mio cliente. Prendilo? Non hai dimenticato di verificare quale versione del mio compilatore, forse il mio sistema operativo, le opzioni di compilazione / collegamento, le versioni dei componenti riutilizzabili (include), le librerie, ecc.?

Per fornire un esempio pratico di un tentativo di creare una build veramente ripetibile, considerare quanto segue:

Una pipeline di build che inizia con un repository git per il quale nessun utente può mai riscrivere la cronologia o eliminare i rami non uniti.

Il primo passo "build" dopo aver verificato il codice sorgente è far girare un container che contiene tutte le dipendenze del tempo di build.

L'output del contenitore del tempo di compilazione in esecuzione è un contenitore che contiene il file binario compilato.

Più importante per la ripetibilità della build, i seguenti tag vengono aggiunti al contenitore finale:

• L'hash esatto del codice sorgente nel repository originale e l'URL sia del repository git che di un'istantanea tar ball del codice che viene caricato in un repository di artefatti.
• La versione esatta del contenitore build utilizzato per eseguire la build.
• La versione esatta dell'immagine di base originale in cui è stato caricato il file binario.
• I valori di tutte le variabili di build-time utilizzate per creare il binario.
• La versione della finestra mobile con cui sono stati creati tutti e tre i contenitori, nonché la versione in cui erano in esecuzione durante la creazione.

Aggiungendo tutti questi metadati possiamo garantire che in qualsiasi momento in futuro possiamo estrarre l'esatta serie di dipendenze di compilazione (tramite il contenitore di compilazione), compilare il binario con un esatto set di passaggi noti (racchiuso nel contenitore di compilazione ) e impacchettarlo in un'altra immagine di base nota con tutte le dipendenze di runtime (utilizzando il tag immagine di base) e tutto ciò può basarsi sull'esatta versione corretta del codice sorgente in base al tag sul contenitore.

Teoricamente questo dovrebbe darci la possibilità di riprodurre esattamente una versione di build.

L'importanza di ciò è che ci consente di guardare a ciò che è in esecuzione in produzione e, anche se tutto ha progredito significativamente le versioni, tornare indietro ed estrarre la versione del codice, l'immagine di base e il contenitore di compilazione originariamente utilizzato in modo che possiamo, ad esempio , applica una correzione rapida a quella versione prima di ricostruire esattamente come prima in modo che possiamo ridistribuire sapendo che è esattamente lo stesso artefatto con l'unico delta che è la correzione rapida.