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

Quello che ho fatto in passato è convertire la macchina di sviluppo fisica in una VM, o se è già una VM, conservarla per un uso futuro. Non è efficiente come 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 è di mantenere uno script che installa TUTTE le dipendenze necessarie per un progetto, scarica la sorgente e aggancia tutto. Alcuni script hanno due modalità: una per la produzione, che di solito è praticamente un sottogruppo dell'altro modo: sviluppo.

Alcuni ambienti impiegano circa 5 minuti per l'installazione con uno script - in questo caso tengo una VM locale con una nuova installazione del SO di destinazione su cui dispongo lo script del progetto quando arrivo al lavoro al mattino - e poi eseguire tutti i lavori relativi alla codifica su quell'istanza VM. Prima di andarmene, sposto 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, file di grandi dimensioni da scaricare, qualsiasi cosa del genere) eseguo la procedura sopra descritta una volta alla settimana.

Il vantaggio è che è molto semplice 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 compito strettamente correlato al controllo della versione e alla gestione della build, ma è abbastanza distinto che spesso richiede una strategia separata, anche se utilizza alcuni degli stessi concetti e gli stessi meccanismi di elaborazione e memorizzazione.

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

Come ho detto, spesso questo è un compito che coincide con il controllo della versione di origine, e spesso i dati di gestione della configurazione risiedono accanto al sorgente sia nella documentazione che nel repository sorgente. Non deve essere, ma spesso è una questione di convenienza.

L'automazione di alcuni aspetti della gestione della configurazione è notevolmente migliorata negli ultimi anni. Alcune risposte e commenti hanno suggerito script come un modo per promuovere la gestione della configurazione e gli script sono una buona risposta per ottenere risultati riproducibili, ma spesso gli script fatti manualmente da soli sono incoerenti e incompleti. Uno di questi è migliorato grazie al provisioning automatico. Sistemi come burattino o chef consente di specificare componenti e sistemi software per un particolare utente o macchina o per un particolare profilo di attività e fornisce" ricette "che consentono un approccio a mani libere per l'impostazione di una macchina o di un ambiente completo. Prende fondamentalmente il concetto di un repository di distribuzione software e si estende e 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 vostro situazione.

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

Ogni sistema (e variazioni) richiede un po 'di tempo per essere impostato, ma ha qualche valore chiaro se si trova che il compito di ricaricare e riconfigurare sia un'attività comune.

Docker sarebbe una buona opzione. Puoi usare un file di dock per agire come manifest per la VM che desideri. Non è necessario memorizzare alcuna immagine, verrà scaricato quello richiesto. Inoltre, può utilizzare le tue immagini, in modo da poter creare la tua immagine di base e quindi aggiungere i componenti richiesti dall'ambiente.

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

• L'ambiente creato può essere messo sullo stesso CVS del tuo progetto, che ti dà un ambiente con versione (pulito!)
• La finestra mobile può essere utilizzata per eseguire il provisioning dell'ambiente live, riducendo i mal di testa dell'avvio dei progetti in produzione.
• Se gli 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'utilizzo di una VM sono solo parzialmente corrette, 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 richiede più spazio per l'HDD internamente, questo può essere un po 'complicato e probabilmente è necessario ricostruirne uno. Anche se le dimensioni del file potrebbero non essere un problema, la velocità di Internet continua a diventare il collo di bottiglia quando devi 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 cerca di 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 passi sono necessari:

• Fornire brevi istruzioni su ciò che si suppone sia installato (sistema operativo di base, runtime di base come Java / Perl / Python ...)
• Scrivi uno script breve che esegue le installazioni richieste (idealmente solo una singola chiamata di uno strumento come Maven)
• Provalo su una nuova installazione (come su una VM)

Quindi dovresti essere in grado di ricreare l'ambiente, e anche gli altri dovrebbero essere in grado di farlo (che potrebbe essere importante se non è un progetto solista).

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

La soluzione VM funzionerà anche, e probabilmente è meno lavoro nel breve correre (basta tenere la VM). Tuttavia, ritengo che questa soluzione offra di più flessibilità, ad esempio quando si cambia l'ambiente.