Controllo della versione di un sito Web: dev / produzione di file front-end

8

Sto cercando di pensare a un modo migliore per controllare la versione dei nostri progetti di siti web. Tieni presente che sono solo uno sviluppatore front-end, quindi non ho una profonda conoscenza di VCS.

I flussi di lavoro stanno cambiando e le abitudini di controllo delle versioni precedenti diventano obsolete. Il problema principale è che ci sono 2 array di file front-end per ciascun sito Web.

L'ambiente di sviluppo (meno file, js non compressi, immagini, ecc.). L'ambiente di costruzione, "gulpified" (tutto compresso e non leggibile dagli umani).

Ma non puoi vendere un sito web con i suoi file sorgente. Beh, non sembra giusto.

C'è la soluzione di avere 2 repository: una build, un dev, con gulp che invia i file dev per creare la directory. Ma è una seccatura da mantenere, con le piccole aziende non penso sia così bello. Crea un sacco di repository e le persone devono gestire con diversi repository, a volte anche con un repository SVN, i problemi sorgono.

Quindi c'è anche la soluzione per avere 1 repository: i file sorgenti e i file prod con lo stesso svn. Ma poi è necessario rimuovere i file di origine quando il sito va dal server di sviluppo locale al server di produzione (quindi ci sono diversi file in un singolo repository, in base alla sua posizione, dev o produzione ..). Da quello che ho sentito, non va bene

Qual è il modo corretto di gestire un flusso di lavoro front-end per quanto riguarda il sistema di controllo della versione?

    
posta Antonin Cezard 09.09.2015 - 17:53
fonte

1 risposta

13

Una regola di base del controllo del codice sorgente è che è necessario solo inserire manualmente artefacts nel repository (i file di origine originali), tutto ciò che può essere "compilato" o "generato" non ha bisogno da conservare lì, perché produrrà ridondanza. Uno può (facoltativamente) memorizzare le uscite / parti intermedie di un processo di compilazione in un repository (talvolta chiamato anche artefatti), quando i passaggi per riprodurle non sono completamente automatici, o per scopi di memorizzazione nella cache, quando la build i passaggi per riprodurre l'output sono lenti.

Quindi, se hai un processo completamente automatizzato per generare i file di produzione dai tuoi file sorgente di sviluppo, devi solo mettere i file di sviluppo nel controllo del codice sorgente (insieme agli script per creare i file di produzione). In caso contrario, stabilire un tale processo. Assicurati che nessuno debba armeggiare con i file di produzione manualmente dopo che sono stati generati dalla fonte. Se vuoi distribuire "direttamente" dal tuo VCS, assicurati di avere uno script di distribuzione che estrae i file di origine del dev dal controllo del codice sorgente, esegua il "gulpification" e trasferisca i file risultanti alla produzione in un unico passaggio.

Naturalmente, se si desidera utilizzare il controllo del codice sorgente anche come "backup di mans mans" o come cache per i file di produzione, è possibile impostare un secondo repository per questo scopo e inserire una copia della struttura del file di produzione dopo la generazione. Questo repository non servirà per lo sviluppo e, una volta impostato, non dovrai mantenerlo manualmente. Quindi assicurati che non ci saranno passaggi manuali necessari per eseguire i backup in questo "repository" - includere i passaggi necessari nello script di distribuzione che esegue automaticamente il backup. Pensare all'aggiunta di uno script di backup separato se non è possibile proibire modifiche manuali alla produzione dopo la distribuzione. In questo modo, puoi mantenere il processo gestibile anche se disponi di risorse limitate.

E sì, questo dovrebbe essere un secondo repository strettamente separato, perché ha uno scopo completamente diverso e un ciclo di vita diverso da quello del repository. Lo usi solo per i backup, non per il controllo del codice sorgente, che è un processo diverso.

    
risposta data 09.09.2015 - 18:36
fonte