È assolutamente necessario che ignoriamo / cancelliamo tutti i file compilati prima di eseguire il commit?

Naviga le tue risposte
2

Sto lavorando su un tema Drupal. Utilizzerò linguaggi "intermedi" per svilupparlo, ovvero Stylus per gli stili e CoffeeScript per alcuni degli script front-end.

Ho intenzione di utilizzare un servizio di hosting git per poter condividere il codice tra le università. Lo userò anche per aggiornare il codice localmente e poi spingerò al servizio di hosting, per essere poi estratto dal sito di drupal dal vivo.

Questo rende le cose davvero eleganti.

Tuttavia, ho notato che molti sviluppatori tendono a .gitignore di tutto il codice compilato.

Se fosse una buona pratica, mi sarebbe piaciuto seguirla, se e solo se non ci fosse questo problema: ricompilare tutto il codice necessario affinché il tema si formasse correttamente.

Questo significa che quando eseguo un pull, dovrò ricompilare tutto il codice CSS e JavaScript. Ora, se dovessi fare un pull sul sito live, c'è il rischio che un utente entri nel sito proprio nel momento in cui faccio il pull. Nessuno stile e script verranno caricati sul lato utente, a condizione che il codice non sia stato compilato.

Naturalmente, la compilazione dura circa un secondo e l'utente potrebbe probabilmente pensare a se stesso "meh, era solo la mia connessione Internet."

Ma c'è anche il problema che il server non ha i compilatori installati per cominciare. Quindi ora farei un pull, ma non ci saranno stili e script.

È assolutamente necessario che elimini tutto il codice compilato, o posso andare avanti e includerli nel commit?

    
posta skizeey 02.05.2012 - 03:10
fonte

2 risposte

12

Sì, è necessario cancellare tutto il codice compilato. Il controllo del codice sorgente è, beh, il codice sorgente, non i file compilati. Lo scenario peggiore è quando gli sviluppatori eseguono il commit dei binari compilati. Il tuo caso non è lo stesso, dal momento che non stai eseguendo binari di grandi dimensioni che sono diff-unfriendly, ma comunque, tieni il controllo del codice sorgente libero da tutto ciò che non ti serve per eseguire l'applicazione.

Ciò che sembra sbagliato nel tuo caso è il processo di distribuzione. Invece di spingere il codice sul server di produzione direttamente dal controllo sorgente, dovresti piuttosto, nel caso più semplice:

  • Carica il codice sorgente,
  • Compilalo e / o ottimizzalo,
  • Spingi la versione compilata sul server.

Se il tuo sito web ha molte visite, potresti aver bisogno di un flusso più complicato, utilizzando due server, ad esempio:

  • Carica il codice sorgente,
  • Compilalo e / o ottimizzalo,
  • Spingi la versione compilata al server di staging,
  • Esegui una serie di test per accertarti che il sito web funzioni sul server di staging,
  • Inoltra tutte le richieste al server di produzione 2,
  • Una volta che il server di produzione 1 non ha richieste, spingere la versione compilata su di esso,
  • Inoltra tutte le richieste al server di produzione 1,
  • Una volta che il server di produzione 2 non ha richieste, spingere la versione compilata su di esso,
  • Utilizza nuovamente il server 1 e il server 2.
risposta data 02.05.2012 - 03:29
fonte
4

La risposta di MainMa è ottima, ma va notato che questo è il caso principale per l'integrazione continua. Configurare una macchina (una soluzione ospitata o una propria) che identificherà quando è arrivato un commit, compilare il codice, eseguire test appropriati e compilare il pacchetto di distribuzione se i test hanno esito positivo. Questo approccio potrebbe essere un ulteriore passo avanti e automatizzare una distribuzione pianificata quando i criteri per una distribuzione sono stati soddisfatti.

    
risposta data 02.05.2012 - 04:48
fonte

Leggi altre domande sui tag

Come faccio a fare riferimento al più piccolo valore non zero possibile? Non dovremmo contare i caratteri di codice e commenti invece delle righe di codice e commenti? [chiuso]