C'est un problème sur lequel je passe beaucoup de temps. A quoi @VonC a déjà écrit permettez-moi d'ajouter quelques réflexions.
Je pense que le sujet de la gestion de configuration logicielle est bien compris et souvent pratiqué avec soin dans des environnements commerciaux. Cependant, cette approche générale fait souvent défaut dans les environnements de traitement de données scientifiques, dont beaucoup restent dans le milieu universitaire ou en sont sortis. Cependant, si vous êtes dans un tel environnement de travail, il existe des sources d'informations et de conseils facilement disponibles et beaucoup d'outils pour vous aider. Je ne vais pas m'étendre là-dessus.
Je ne pense pas que votre suggestion d'inclure tout le code source dans un exécutable soit, même si cela est faisable, nécessaire.En effet, si vous obtenez SCM correctement, l'un des tests essentiels que vous avez effectués, et continuez à le faire, est votre capacité à reconstruire des «anciens» exécutables à la demande. Vous devriez également être en mesure de déterminer quelle révision des sources a été utilisée dans chaque exécutable et version. Ceux-ci devraient rendre inutile le code source dans un exécutable.
Le sujet de l'association des résultats aux calculs est également, comme vous le dites, essentiel. Voici quelques-uns des composants de la solution que nous construisons:
Nous nous éloignons du fichier texte non structuré traditionnel qui caractérise la sortie de nombreux programmes scientifiques vers des fichiers structurés, dans notre cas, nous sommes regardant HDF5 et XML, dans lequel à la fois les données d'intérêt et les métadonnées sont stockées. Les métadonnées comprennent l'identification du programme (et de la version) qui a été utilisé pour produire les résultats, l'identification des ensembles de données d'entrée, les paramètres du travail et un tas d'autres choses.
Nous avons examiné l'utilisation d'un SGBD pour stocker nos résultats; nous aimerions aller dans cette direction mais nous n'avons pas les ressources pour le faire cette année, probablement pas la prochaine fois non plus. Mais les entreprises utilisent des SGBD pour diverses raisons, et l'une des raisons est leur capacité à faire marche arrière, à fournir une piste de vérification, ce genre de chose.
Nous étudions également de près quels ensembles de résultats doivent être stockés. Une approche intéressante serait seulement de stocker les ensembles de données originaux capturés à partir de nos capteurs de champ. Malheureusement, certains de nos calculs prennent 1000s de CPU-heures à produire donc il est impossible de les reproduire ab-initio sur demande. Cependant, nous stockerons beaucoup moins de données intermédiaires à l'avenir que par le passé.
Nous rendons également beaucoup plus difficile (je voudrais penser impossible, mais je ne suis pas sûr que nous y sommes encore) pour que les utilisateurs éditent les ensembles de résultats directement. Une fois que quelqu'un fait cela, toutes les informations de provenance dans le monde sont fausses et inutiles. Pour finir, si vous voulez en savoir plus sur le sujet, essayez Google pour les sujets similaires 'workflow scientifique' et 'provenance des données'.
EDIT: On ne sait pas de ce que je l'ai écrit ci-dessus, mais nous avons modifié nos programmes afin qu'ils contiennent leur propre identification (nous utilisons les capacités de mots-clés de Subversion pour cela avec une extension ou deux de nos propres) et d'écrire ce dans toute sortie qu'ils produisent.