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

Sto cercando di pensare a un modo migliore per controllare la versione dei progetti del nostro sito 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 ogni sito Web.

L'ambiente di sviluppo (meno file, js non compressi, immagini, ecc.). L'ambiente di costruzione "gulpificato" (tutto compresso e non leggibile dall'uomo).

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

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

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

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

Una regola di base del controllo del codice sorgente è che è necessario solo inserire artefatti scritti manualmente nel repository (i file di origine originali), non è necessario archiviare tutto ciò che può essere "compilato" o "generato", poiché produrrà ridondanza . È possibile (facoltativamente) archiviare output / parti intermedi di un processo di compilazione in un repository (a volte chiamato anche artefatti), quando i passaggi per riprodurli non sono completamente automatici o per scopi di memorizzazione nella cache, quando i passaggi di compilazione 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. Assicurarsi che nessuno debba armeggiare manualmente con i file di produzione dopo che sono stati generati dall'origine. Se vuoi distribuire "direttamente" dal tuo VCS, assicurati di avere uno script deploy che tira i file sorgente dev fuori dal controllo del codice sorgente, esegua la "gulpificazione" e trasferisca i file risultanti alla produzione in un solo passaggio.

Naturalmente, se si desidera utilizzare il controllo del codice sorgente anche come "backup mans scadente" o come cache per i file di produzione, è possibile impostare un secondo repository a tale scopo e inserire una copia della struttura del file di produzione dopo la generazione. Questo repository non servirà allo sviluppo e, dopo essere stato impostato, non è necessario mantenerlo manualmente. Quindi assicurati che non ci siano passaggi manuali per eseguire i backup in questo "repository di prodotti" - includi i passaggi necessari nello script di distribuzione che esegue automaticamente il backup. Pensare di aggiungere uno script di backup separato se non è possibile vietare le modifiche manuali alla produzione dopo la distribuzione. In questo modo, puoi mantenere il processo mantenibile anche se disponi di risorse limitate.

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