Modo efficace di mantenere i progetti passati con il loro ambiente di sviluppo lavorativo?

Trovo che ogni volta che voglio andare a eseguire un progetto passato, ci vorrà molto tempo prima che riesca a trovarlo e prima che abbia di nuovo impostato tutto per poterlo eseguire.

Ad esempio, ho progetti Python che ho creato in Linux e dipende da pacchetti software che possono essere facilmente installati in Linux, ma non ho più la VM Linux che stavo usando. E alcuni dei miei altri progetti dipendono da altre variabili come la configurazione del web server, le variabili PATH, sdk, IDE, versione del sistema operativo, dispositivo, ecc.

Qualcuno ha un modo efficace di gestire questo problema? Finora mi sono preoccupato solo di mantenere il codice sorgente di backup, ma è difficile ristabilire l'ambiente di sviluppo lavorativo ed è anche difficile mantenere l'ambiente di sviluppo lavorativo .

Quello che ho fatto in passato è convertire la macchina di sviluppo fisico in una macchina virtuale o, se è già una macchina virtuale, conservarla per un uso futuro. Non è efficiente quanto vorrei per l'utilizzo dello spazio su disco, ma lo spazio è economico. Inoltre, questo processo è molto meno costoso in termini di tempo rispetto al tentativo di riconfigurare un ambiente in futuro in caso di necessità.

La mia attuale metodologia preferita è quella di mantenere uno script che installa TUTTE le dipendenze necessarie per un progetto, scarica la fonte e collega tutto. Alcuni script hanno due modalità: una per la produzione, che di solito è praticamente un sottoinsieme dell'altra modalità: sviluppo.

Alcuni ambienti richiedono solo circa 5 minuti per l'installazione con uno script - in tal caso mantengo una VM locale con una nuova installazione del sistema operativo di destinazione su cui distribuisco lo script del progetto quando arrivo al lavoro al mattino - e quindi eseguo tutta la codifica lavori correlati su quell'istanza di VM. Prima di partire, invio tutte le modifiche tramite git alla mia macchina fisica o al nostro repository centrale e termino la VM.

Se l'ambiente richiede più tempo per l'installazione (installazioni di lunga durata, download di file di grandi dimensioni, qualcosa del genere) eseguo la procedura sopra descritta una volta alla settimana.

Il vantaggio è che è molto facile da implementare su una nuova macchina e / o server di produzione, è tutto documentato nello script e lo script viene verificato molto spesso.

Il concetto che stai descrivendo è la gestione della configurazione. Questo è come sembra, un modo per identificare, registrare, versione / traccia e segnalare un ambiente. Spesso è un'attività fortemente correlata al controllo della versione e alla gestione della build, ma è abbastanza distinta che spesso richiede una strategia separata, anche se utilizza alcuni degli stessi concetti e stessi meccanismi di elaborazione e archiviazione.

La gestione della configurazione oltre a aiutare a mantenere un ambiente di lavoro sotto controllo aiuta anche a stabilire un registro dei diversi ambienti di lavoro in cui viene utilizzato il software (sviluppo come detto, oltre a test / QA, distribuzione ai clienti di routine, distribuzione ai clienti che richiedono una considerazione speciale o una configurazione speciale o costruire proprietà e così via).

Come ho detto, spesso si tratta di un'attività che coincide con il controllo della versione di origine e spesso i dati di gestione della configurazione risiedono accanto all'origine sia nella documentazione che nel repository di origine. Non deve essere, ma spesso è per comodità.

L'automazione di alcuni aspetti della gestione della configurazione è notevolmente migliorata negli ultimi anni. Alcune risposte e commenti hanno suggerito che gli script sono un modo per promuovere la gestione della configurazione e gli script sono una buona risposta per aiutare a ottenere risultati riproducibili, ma spesso gli script fatti a mano da soli sono incoerenti e incompleti. Uno di questi modi è migliorato attraverso il provisioning automatico. Sistemi come burattini o chefaiutare a specificare componenti e sistemi software per un particolare utente o macchina o per un particolare profilo di attività e fornire "ricette" che consentano un approccio pratico alla creazione di una macchina o un ambiente completi. Praticamente prende il concetto di un repository di distribuzione software e lo estende e lo generalizza fornendo non solo i pacchetti di software necessari per un sistema, ma anche i profili di configurazione specifici per ciascun pacchetto in modo che sia pronto per l'uso nel modo appropriato per il tuo situazione.

Vagrant prende questo in una direzione leggermente diversa e fornisce un modo per far girare rapidamente le definizioni delle macchine virtuali, in modo che una VM possa disporre automaticamente del proprio software e hardware virtuale e possa rivelarsi un modo conveniente per riprodurre una particolare rappresentazione di un hardware ambiente utilizzato dall'utente del software.

Ogni sistema (e variazioni) richiede un po 'di tempo per essere configurato, ma ha un certo valore se trovi che il compito di ricaricare e riconfigurare sia un compito comune.

docker sarebbe una buona opzione. È possibile utilizzare un file docker per agire come manifest per la VM desiderata. Non è necessario memorizzare alcuna immagine, verrà scaricata quella richiesta. Inoltre, può utilizzare le tue immagini, in modo da poter creare la tua immagine di base e quindi aggiungere i componenti richiesti dall'ambiente.

Utilizzando la finestra mobile questo può anche migliorare altre parti del flusso di lavoro:

• L'ambiente creato può essere inserito nello stesso CVS del tuo progetto, il che ti dà un ambiente con versione (pulito!)
• La finestra mobile può essere utilizzata per eseguire il provisioning dell'ambiente live, riducendo il mal di testa dell'avvio dei progetti in produzione.
• Se altri iniziano a lavorare con te, tutto ciò di cui hanno bisogno è il file docker per caricare l'enorme configurazione dell'ambiente.

Quindi le idee qui sull'uso di una VM sono solo in parte giuste, so che gli HDD stanno diventando sempre più grandi, ma non è un motivo per utilizzare tutto lo spazio che hai. Inoltre, quando un ambiente VM ha bisogno di più spazio su disco fisso internamente, questo può essere un po 'complicato e probabilmente avrai bisogno di ricostruirne uno. Anche se la dimensione del file potrebbe non essere un problema, la velocità di Internet diventa ancora il collo di bottiglia quando è necessario inviare oltre 5Go su una normale connessione DSL.

La maggior parte dei sistemi (lingue, runtime o sistemi operativi) ha un modo standardizzato di installare software e configurazioni, quindi prova a usarli. Ad esempio:

• Maven o Gradle per Java
• CPAN per Perl
• rpm per RedHat / Fedora
• dpkg / apt-get per Linux
• Pacchetti MSI per Windows

Quindi, fai le istruzioni di installazione spiegando esattamente cosa deve essere installato / quali passaggi sono necessari:

• Fornire brevi istruzioni su ciò che si presume sia installato (sistema operativo di base, runtime di base come Java / Perl / Python ...)
• Scrivi uno script breve che esegua le installazioni richieste (idealmente solo un singolo invocazione di uno strumento come Maven)
• Prova questo su una nuova installazione (come su una VM)

Quindi dovresti essere in grado di ricreare l'ambiente e altri dovrebbero essere in grado di farlo (il che può essere importante se non è un progetto solista).

Potrebbe essere necessario archiviare i pacchetti di installazione necessari da qualche parte, oppure includere semplicemente le istruzioni per il download (a meno che il sistema non tenga traccia di questi, come apt-get o Maven). Dipende da quanto ti fidi dei fornitori dei pacchetti - probabilmente non è necessario archiviare i pacchetti Debian di base, ma con qualche piccolo progetto di software libero, potrebbe essere una buona idea.

La soluzione VM funzionerà anche, e probabilmente sarà meno lavoro a breve termine (basta mantenere la VM). Tuttavia, ritengo che questa soluzione offra maggiore flessibilità, ad esempio quando si cambia l'ambiente.