Que sont exactement les «versions vraiment reproductibles»?

Que sont-ils exactement? Pourquoi sont-ils importants dans le domaine de la livraison continue?

Contexte: J'ai vu dans l'un des commentaires (je suppose reddit) que les versions vraiment reproductibles sont encore une technologie en cours de recherche et sont très difficiles à créer.

Donc, je voulais savoir pourquoi ils sont si difficiles à créer?

Que sont-ils exactement?

Voici une citation de reproductible-builds.org :

Les versions reproductibles sont un ensemble de pratiques de développement logiciel qui créent un chemin vérifiable du code source lisible par l'homme vers le code binaire utilisé par les ordinateurs.

Pourquoi sont-ils importants?

OMI, la façon la plus simple d'expliquer leur importance est de les considérer comme une variante d'une procédure de sauvegarde.

Par exemple:

• Supposons une entreprise qui utilise (dépend) certains progiciels sous licence d'un fournisseur de logiciels. Alors que l'entreprise obtient uniquement les exécutables, pas les sources, etc. qui ont été utilisées pour créer ces exécutables.

• Tout se passe bien, mais à un moment donné, quelque chose ne va pas avec le fournisseur de logiciels, par exemple, ils font faillite (par exemple, la faillite).

• Cela peut présenter un risque pour l'entreprise (à long terme). C'est-à-dire s'il n'y a pas de procédure / accord en place pour que l'entreprise obtienne un accès (légal) à toutes les sources requises, à la documentation, aux procédures de construction, etc. liées à quoi que ce soit du fournisseur de logiciels utilisé (à l'époque) lorsque les exécutables (utilisés par l'entreprise) ont été créés (et expédiés à l'entreprise).

• C'est là que " Software Escrow " vient à la rescousse: si un tel accord est en place, on pourrait penser que via une tierce partie, il serait toujours possible pour l'entreprise d'avoir accès à " ce qui a été utilisé " pour pouvoir se reproduire les exécutables, de sorte qu'à partir de là, l'entreprise puisse avoir la possibilité de continuer à utiliser ce logiciel et, le cas échéant, commencer à le maintenir lui-même (pour gérer uniquement sa propre entreprise).

• Cependant, " ce qui a été utilisé " dans la puce précédente est la partie la plus difficile à faire fonctionner. Cela nécessite que le tiers effectue au préalable les validations appropriées. Et croyez-moi, il faut un certain temps avant de pouvoir recréer un exécutable pour lequel vous pouvez prouver que, en dehors (par exemple) de la date du lien, il correspond parfaitement à ce que le fournisseur de logiciels livre à l'agent logiciel.

Et pourquoi sont-ils si difficiles à créer?

Si l'exemple ci-dessus n'est toujours pas assez clair, imaginez que vous êtes mon agent d'entiercement de logiciels, dites-moi ce dont vous avez besoin comme entrée pour recréer une copie du logiciel sous licence par mon client. Tu piges? Vous n'avez pas oublié de vérifier quelle version de mon compilateur, peut-être mon système d'exploitation, les options de compilation / lien, les versions des composants réutilisables (inclus), les bibliothèques, etc.?

Pour fournir un exemple pratique d'une tentative de création d'une construction vraiment reproductible, considérez ce qui suit -

Un pipeline de construction qui commence par un référentiel git pour lequel aucun utilisateur ne pourra jamais réécrire l'historique ou supprimer des branches non fusionnées.

La première étape de "build" après avoir extrait le code source consiste à faire tourner un conteneur qui contient toutes les dépendances de temps de build.

La sortie du conteneur de construction en cours d'exécution est un conteneur qui contient le binaire compilé.

Plus important pour la répétabilité de la construction, les balises suivantes sont ajoutées au conteneur final:

• Le hachage exact du code source dans le référentiel d'origine et l'url du référentiel git et d'un instantané tar ball du code qui est téléchargé dans un référentiel d'artefacts.
• La version exacte du conteneur de build qui a été utilisée pour exécuter la build.
• La version exacte de l'image de base d'origine dans laquelle le binaire a été chargé.
• Les valeurs de toutes les variables de construction utilisées pour créer le binaire.
• La version de docker avec laquelle les trois conteneurs ont été construits ainsi que la version sous laquelle ils fonctionnaient lorsqu'ils ont construit.

En ajoutant toutes ces métadonnées, nous pouvons nous assurer qu'à tout moment dans le futur, nous pouvons extraire l'ensemble exact des dépendances de génération (via le conteneur de génération), compiler le binaire avec un ensemble exact d'étapes connues (inscrit sur le conteneur de génération ) et l'intégrer dans une autre image de base connue avec toutes les dépendances d'exécution (en utilisant la balise d'image de base) et tout cela peut être basé sur la version exacte exacte du code source basé sur la balise sur le conteneur.

Théoriquement, cela devrait nous donner la possibilité de reproduire exactement une version de build.

L'importance de cela est qu'il nous permet de regarder ce qui fonctionne en production et, même si tout a progressé de manière significative, de revenir en arrière et de retirer la version de code, l'image de base et le conteneur de construction initialement utilisés pour que nous puissions, par exemple , appliquez un correctif à cette version avant de reconstruire exactement comme avant afin que nous puissions redéployer en sachant qu'il s'agit exactement du même artefact, le seul delta étant le correctif.