Questo è un problema a cui dedico molto tempo a lavorare. A ciò che @VonC ha già scritto lasciatemi aggiungere alcune considerazioni.
Penso che il tema della gestione della configurazione del software sia ben compreso e spesso praticato con cura in ambienti commerciali. Tuttavia, questo approccio generale è spesso carente negli ambienti di elaborazione dei dati scientifici, molti dei quali rimangono o sono cresciuti nel mondo accademico. Tuttavia, se ci si trova in un ambiente di lavoro simile, ci sono fonti di informazioni e consigli prontamente disponibili e molti strumenti per aiutare. Non mi espanderò ulteriormente su questo.
Non penso che il tuo suggerimento di includere l'intero codice sorgente in un eseguibile sia, anche se fattibile, necessario.Infatti, se ottieni SCM, allora uno dei test essenziali che hai fatto e continui a farlo è la tua capacità di ricostruire "vecchi" eseguibili su richiesta. Dovresti anche essere in grado di determinare quale revisione delle fonti è stata utilizzata in ogni eseguibile e versione. Questi dovrebbero rendere superfluo includere il codice sorgente in un eseguibile.
Anche il tema del risultato della legatura è fondamentale per i calcoli, come dici tu. Ecco alcuni dei componenti della soluzione che stiamo costruendo:
Ci stiamo allontanando dal tradizionale file di testo non strutturato che è caratteristico dell'output di molti programmi scientifici verso file strutturati, nel nostro caso siamo guardando HDF5 e XML, in cui sono memorizzati sia i dati di interesse che i meta-dati. I meta-dati includono l'identificazione del programma (e della versione) che è stato usato per produrre i risultati, l'identificazione dei set di dati di input, i parametri di lavoro e un mucchio di altre cose.
Abbiamo cercato di utilizzare un DBMS per archiviare i nostri risultati; ci piacerebbe andare in questo modo ma non abbiamo le risorse per farlo quest'anno, probabilmente neanche il prossimo. Ma le aziende usano i DBMS per una serie di motivi, e uno dei motivi è la loro capacità di eseguire il rollback, fornire una traccia di controllo, quel genere di cose.
Stiamo anche esaminando attentamente quali set di risultati devono essere memorizzati. Un buon approccio sarebbe sempre e solo per memorizzare i set di dati originali catturati dai nostri sensori di campo. Sfortunatamente alcuni dei nostri calcoli richiedono migliaia di ore di CPU da produrre, quindi è impossibile riprodurli su richiesta ab-initio. Tuttavia, in futuro memorizzeremo molti meno set di dati intermedi rispetto a quelli che abbiamo in passato.
Stiamo rendendo anche molto più difficile (mi piacerebbe pensare impossibile ma non sono sicuro che ci sia ancora) per gli utenti di modificare direttamente i set di risultati. Una volta che qualcuno fa tutte le informazioni sulla provenienza nel mondo è sbagliato e inutile.
Infine, se vuoi saperne di più sull'argomento, prova a cercare su Google argomenti simili a "flusso di lavoro scientifico" e "provenienza dati".
EDIT: Non è chiaro da quello che ho scritto sopra, ma abbiamo modificato i nostri programmi in modo che contengano la loro identificazione (usiamo le capacità di parole chiave di Subversion per questo con un'estensione o due del nostro) e scrivere questo in qualsiasi output che producono.