Quale parte del progetto dovrebbe essere nel controllo del codice sorgente?

Un collega sviluppatore ha iniziato a lavorare su un nuovo progetto Drupal e l'amministratore di sistema ha suggerito che dovrebbero solo mettere la sottodirectory siti / predefinita nel controllo del codice sorgente, perché "renderà gli aggiornamenti facilmente scriptabili". Mettendo da parte quell'affermazione alquanto dubbia, solleva un'altra domanda: quali file dovrebbero essere sotto il controllo del codice sorgente? E c'è una situazione in cui dovrebbero essere esclusi alcuni grossi pezzi di file?

La mia opinione è che l'intero albero del progetto dovrebbe essere sotto controllo, e questo sarebbe vero per un progetto Drupal, rotaie o qualsiasi altra cosa. Questo sembra un gioco da ragazzi: hai chiaramente bisogno di un controllo delle versioni per il tuo framework tanto quanto lo sei per qualsiasi codice personalizzato che scrivi.

Detto questo, mi piacerebbe avere altre opinioni su questo. Ci sono argomenti per non avere tutto sotto controllo?

Direi che il minimo che dovrebbe contenere il controllo del codice sorgente è tutti i file necessari per ricreare una versione in esecuzione del progetto. Ciò include anche i file DDL per impostare e modificare qualsiasi schema di database e anche nella sequenza corretta. Meno, ovviamente, gli strumenti necessari per compilare ed eseguire il progetto, nonché tutto ciò che può essere automaticamente derivato / generato da altri file nel controllo del codice sorgente (come i file JavaDoc generati dai file Java nel controllo del codice sorgente).

È meglio mettere praticamente tutto sotto il sole nel controllo del codice sorgente.

• Codice

• biblioteche

• risorse

• Costruire / distribuire script

• Creazione di database e script di aggiornamento

• Determinata documentazione

• File di configurazione specifici dell'ambiente

L'unica cosa che non dovrebbe essere messa nel controllo del codice sorgente sono gli artefatti da costruire per il tuo progetto.

Direi che;

• qualsiasi file necessario per eseguire la compilazione passa al controllo versione
• qualsiasi file (che può essere) generato dalla build no

Tenderei a mettere grossi binari come pacchetti di installazione di strumenti da qualche parte al di fuori del trunk, ma dovrebbero comunque essere sotto il controllo della versione.

E non dimenticare di mettere anche tutto il codice del database nel controllo del codice sorgente! Ciò includerebbe gli script di creazione originali, gli script per alterare le tabelle (che sono contrassegnati da quale versione del software li utilizza, in modo da poter ricreare qualsiasi versione del database per qualsiasi versione delle applicazioni) e script per popolare qualsiasi tabella di ricerca.

L'esperienza vinta duramente mi ha insegnato che quasi tutto appartiene al controllo del codice sorgente. (I miei commenti qui sono colorati da un decennio e mezzo in via di sviluppo per sistemi embedded / telecom su hardware proprietario con strumenti proprietari, e talvolta difficili da trovare.)

Alcune delle risposte qui dicono "non mettere i binari nel controllo del codice sorgente". È sbagliato. Quando lavori su un prodotto con un sacco di codice di terze parti e molte librerie binarie dei fornitori, controlli nelle librerie binarie . Perché, in caso contrario, a un certo punto eseguirai l'aggiornamento e potresti riscontrare problemi: la build si interrompe perché la macchina di build non ha l'ultima versione; qualcuno dà al nuovo ragazzo i vecchi CD da installare; il wiki del progetto contiene istruzioni obsolete su quale versione installare; eccetto ancora peggio, se devi lavorare a stretto contatto con il fornitore per risolvere un problema specifico e ti inviano cinque set di librerie in una settimana, deviessere in grado di tracciare quale serie di binari ha mostrato quale comportamento. Il sistema di controllo del codice sorgente è uno strumento che risolve esattamente quel problema.

Alcune delle risposte qui dicono "non mettere la toolchain nel controllo del codice sorgente". Non dirò che è sbagliato, ma è meglio mettere la toolchain nel controllo del codice sorgente a meno che tu non abbia un solido sistema di gestione della configurazione (CM) . Ancora una volta, considera il problema di aggiornamento come menzionato sopra. Peggio ancora, ho lavorato a un progetto in cui c'erano quattro diversi tipi di toolchain che fluttuavano intorno quando sono stato assunto - tutti in uso attivo ! Una delle prime cose che ho fatto (dopo che sono riuscito a far funzionare una build) è stata mettere la toolchain sotto il controllo del codice sorgente. (L'idea di un solido sistema CM era oltre ogni speranza.)

E cosa succede quando progetti diversi richiedono toolchain diversi? Caso in questione: dopo un paio d'anni, uno dei progetti è stato aggiornato da un fornitore e tutti i Makefile si sono rotti. Si è scoperto che si basavano su una versione più recente di GNU make. Quindi ci siamo tutti aggiornati. Whoops, i Makefile di un altro progetto si sono tutti rotti. Lezione: eseguire il commit di entrambe le versioni di GNU make ed eseguire la versione fornita con il checkout del progetto.

Oppure, se lavori in un posto dove tutto il resto è sfrenatamente fuori controllo, hai conversazioni come "Ehi, il nuovo ragazzo sta iniziando oggi, dov'è il CD per il compilatore?" "Non so, non li vedo da quando Jack ha smesso, era il guardiano dei cd." "Uhh, non è stato prima che salissimo dal 2 ° piano?" "Forse sono in una scatola o qualcosa del genere." E poiché gli strumenti hanno tre anni, non c'è speranza di ottenere quel vecchio CD dal venditore.

Tutti gli script di compilazione appartengono al controllo del codice sorgente. Qualunque cosa! Fino alle variabili d'ambiente. Il tuo computer di generazione dovrebbe essere in grado di eseguire una build di uno qualsiasi dei tuoi progetti eseguendo un singolo script nella radice del progetto. ( ./buildè uno standard ragionevole; ./configure; makeè quasi altrettanto buono.) Lo script dovrebbe impostare l'ambiente come richiesto e quindi lanciare qualunque strumento costruisca il prodotto (marca, formica, ecc.).

Se pensi che sia troppo lavoro, non lo è. In realtà consente di risparmiare un sacco di lavoro. Commetti i file una volta all'inizio del tempo e poi ogni volta che esegui l'aggiornamento. Nessun lupo solitario può aggiornare la propria macchina e commettere un sacco di codice sorgente che dipende dall'ultima versione di alcuni strumenti, interrompendo la creazione per tutti gli altri. Quando assumi nuovi sviluppatori, puoi dire loro di controllare il progetto ed eseguirlo ./build. Quando la versione 1.8 ha un sacco di ottimizzazione delle prestazioni e si modifica il codice, i flag del compilatore e le variabili di ambiente, si desidera assicurarsi che i nuovi flag del compilatore non vengano accidentalmente applicati alle build della patch della versione 1.7, perché hanno davvero bisogno del codice cambiamenti che li accompagnano o vedi alcune condizioni di gara pelose.

Meglio di tutti , sarà un giorno salvare il culo: immaginate di spedire la versione 3.0.2 del prodotto su un Lunedi. Evviva, festeggia. Martedì mattina, un cliente VIP chiama la hotline dell'assistenza, lamentandosi di questo bug urgente e supercritico nella versione 2.2.6 che è stato spedito 18 mesi fa. E contrattualmente devi ancora supportarlo e si rifiutano di aggiornarsi fino a quando non puoi confermare con certezza che il bug è stato corretto nel nuovo codice e sono abbastanza grandi da farti ballare. Esistono due universi paralleli:

• Nell'universo in cui non hai librerie, toolchain e build di script nel controllo del codice sorgente e non hai un sistema CM solido come una roccia .... Puoi controllare la versione corretta del codice, ma dà tutti i tipi di errori quando provi a creare. Vediamo, abbiamo aggiornato gli strumenti a maggio? No, quelle erano le biblioteche. Ok, torna alle vecchie librerie - aspetta, c'erano due aggiornamenti? Ah sì, sembra un po 'meglio. Ma ora questo strano crash del linker sembra familiare. Oh, è perché le vecchie librerie non funzionavano con la nuova toolchain, ecco perché abbiamo dovuto aggiornare, giusto? (Ti risparmierò l'agonia del resto dello sforzo. Ci vogliono due settimane e alla fine nessuno è contento, non tu, non il management, non il cliente.)

• Nell'universo in cui tutto è nel controllo del codice sorgente, dai un'occhiata al tag 2.2.6, hai una build di debug pronta in circa un'ora, trascorri un giorno o due a ricreare il "bug VIP", rintraccia la causa, risolvilo in la versione corrente e convincere il cliente ad aggiornare. Stressante, ma non così grave come quell'altro universo in cui l'attaccatura dei capelli è 3 cm più alta.

Detto questo, puoi andare troppo lontano:

• Dovresti avere un'installazione standard del sistema operativo di cui hai una "copia d'oro". Documentalo, probabilmente in un README che è nel controllo del codice sorgente, in modo che le generazioni future sappiano che la versione 2.2.6 e precedenti si basano solo su RHEL 5.3 e 2.3.0 e successivamente solo su Ubuntu 11.04. Se è più facile gestire la toolchain in questo modo, provaci, assicurati solo che sia un sistema affidabile.
• La documentazione del progetto è ingombrante da mantenere in un sistema di controllo del codice sorgente. I documenti di progetto sono sempre in anticipo rispetto al codice stesso e non è raro lavorare sulla documentazione per la versione successiva mentre si lavora sul codice per la versione corrente. Soprattutto se tutti i tuoi documenti di progetto sono documenti binari che non puoi diffondere o unire.
• Se hai un sistema che controlla le versioni di tutto ciò che viene utilizzato nella build, usalo ! Assicurati solo che sia facile sincronizzare tutto il team, in modo che tutti (inclusa la macchina di costruzione) stiano tirando fuori dallo stesso set di strumenti. (Sto pensando a sistemi come il pbuilder di Debian e l'uso responsabile di virtualenv di python.)

Le uniche cose che non metto sotto il controllo del codice sorgente sono file che puoi facilmente rigenerare o che sono specifici per gli sviluppatori. Ciò significa eseguibili e binari composti dal codice sorgente, dalla documentazione generata dalla lettura / analisi dei file sotto il controllo del codice sorgente e da file specifici dell'IDE. Tutto il resto passa al controllo della versione ed è gestito in modo appropriato.

Il caso d'uso per il controllo del codice sorgente è: cosa succede se tutte le macchine dei nostri sviluppatori e tutte le nostre macchine di distribuzione fossero colpite da una meteora? Volete che il recupero sia il più vicino possibile al checkout e al build. (Se è troppo sciocco, puoi scegliere "assumi un nuovo sviluppatore").

In altre parole, tutto ciò che non sia il sistema operativo, le app e gli strumenti dovrebbe essere in VCS e nei sistemi embedded, dove può esserci una dipendenza da una versione binaria di uno strumento specifico, ho visto gli strumenti mantenuti anche in VCS!

Il controllo incompleto del codice sorgente è uno dei rischi più comuni che vedo durante la consulenza: ci sono tutti i tipi di attrito associati all'avvio di un nuovo sviluppatore o alla creazione di una nuova macchina. Insieme ai concetti di integrazione continua e consegna continua dovresti avere un senso di "sviluppo continuo": una persona IT può impostare una nuova macchina di sviluppo o distribuzione essenzialmente automaticamente, in modo che lo sviluppatore possa guardare il codice prima che finisca la loro prima tazza di caffè?

Tutto ciò che contribuisce al progetto e per il quale si desidera tenere traccia delle modifiche.

Le eccezioni possono includere grandi BLOB binari come le immagini, se si utilizza uno scm che non gestisce molto bene i dati binari.

Drupal usa git quindi userò la terminologia di git. Userei i sottosposi per ogni modulo per essere in grado di abbattere gli aggiornamenti dei moduli dai repository ufficiali di drupal, pur mantenendo la struttura delle singole implementazioni. In questo modo ottieni i vantaggi della scriptabilità senza perdere i vantaggi di avere tutto sotto il controllo del codice sorgente.

Tutto dovrebbe essere sotto il controllo del codice sorgente, tranne:

• File di configurazione, se includono opzioni di configurazione diverse per ogni sviluppatore e / o ciascun ambiente (sviluppo, test, produzione)
• File di cache, se si utilizza la memorizzazione nella cache del filesystem
• File di registro, se si accede a file di testo
• Tutto ciò che piace file cache e file di registro viene generato contenuto
• (Molto) File binari di grandi dimensioni che difficilmente cambieranno (ad alcuni sistemi di controllo di versione non piacciono, ma se stai usando hg o git a loro non importa molto)

Pensala in questo modo: ogni nuovo membro del team dovrebbe essere in grado di effettuare il checkout di una copia funzionante del progetto (meno gli elementi di configurazione).

E non dimenticare di mettere anche le modifiche dello schema del database (semplici dump sql di ogni modifica dello schema) sotto il controllo della versione. È possibile includere la documentazione utente e API, se ha senso per il progetto.

@maple_shaft solleva un problema importante con la mia prima affermazione relativa ai file di configurazione dell'ambiente nei commenti. Vorrei chiarire che la mia risposta è alle specifiche della domanda, che riguarda Drupal o progetti CMS generici. In tali scenari, in genere si dispone di un database locale e di una produzione e un'opzione di configurazione dell'ambiente è rappresentata dalle credenziali di questi database (e credenziali simili). È consigliabile che questi NON siano sotto il controllo del codice sorgente, in quanto ciò creerebbe diversi problemi di sicurezza.

In un flusso di lavoro di sviluppo più tipico, tuttavia, concordo con maple_shaft sul fatto che le opzioni di configurazione dell'ambiente dovrebbero essere sotto il controllo del codice sorgente per consentire la creazione e la distribuzione in un unico passaggio di qualsiasi ambiente.

Tutto ciò che genera la tua build automatizzata non va nel controllo del codice sorgente. Tutto ciò che richiede alcuna modifica durante la costruzione non andare in controllo del codice sorgente. È così semplice.

Ad esempio, quanto segue non va nel controllo del codice sorgente:

• codice generato
• binari generati
• qualsiasi cosa creata dalla tua build
• qualsiasi cosa creata in fase di esecuzione dal tuo servizio, processo, applicazione web

Cosa succede nel controllo del codice sorgente:

• qualsiasi cosa crea un essere umano
• tutto ciò che viene creato da un'altra persona o gruppo (ad esempio una libreria interna di terze parti in cui è distribuito il controllo del codice sorgente o i file binari di un progetto open source).
• script e altre fonti che creano cose come un database (cioè come ricreare il db se tutti i DBA diventassero AWOL).

Queste regole empiriche sono basate sull'idea che qualsiasi cosa sia nel controllo del codice sorgente potrebbe essere modificata da un essere umano e potrebbe richiedere del tempo prezioso a qualcuno per capire perché è lì.

Tutto ciò di cui hai bisogno per lavorare e che puoi cambiare deve essere aggiornato in un modo o nell'altro. Ma raramente è necessario che due sistemi indipendenti ne tengano traccia.

Qualunque cosa generata in modo affidabile può in genere essere collegata a una versione di origine, pertanto non è necessario che sia tracciata in modo indipendente: sorgente generata, binari che non vengono passati da un sistema a un altro, ecc.

Costruisci registri e altre cose di cui probabilmente nessuno si preoccupa (ma non lo sai mai per certo) di solito sono meglio tracciati da chiunque lo stia generando: jenkins, ecc.

Costruire prodotti che passano da un sistema a un altro deve essere monitorato, ma un repository maven è un buon modo per farlo - non è necessario il livello di controllo fornito da un controllo del codice sorgente. I risultati finali sono spesso nella stessa categoria.

Qualunque cosa rimanga (e a questo punto, dovrebbe esserci poco più di file sorgente e configurazione del server) passa al controllo del codice sorgente.

La mia risposta è piuttosto semplice: non binari. Di conseguenza, quasi tutto il resto.

(Sicuramente non backup di database o migrazioni di schemi o dati utente, però.)

Il controllo del codice sorgente è un meccanismo di rilevamento delle modifiche. Usalo quando vuoi sapere chi ha cambiato cosa e quando.

Il controllo del codice sorgente non è gratuito. Aggiunge complessità al flusso di lavoro e richiede formazione per i nuovi colleghi. Pesare i benefici a fronte del costo.

Ad esempio, può essere difficile controllare i database. Avevamo un sistema in cui dovevi salvare manualmente le definizioni in un file di testo e quindi aggiungerle al controllo del codice sorgente. Ciò ha richiesto molto tempo ed era inaffidabile. Poiché non era affidabile, non è stato possibile utilizzarlo per configurare un nuovo database o per verificare a che ora è stata apportata una modifica. Ma l'abbiamo tenuto per anni, perdendo innumerevoli ore, perché il nostro manager ha pensato "tutto dovrebbe essere sotto il controllo del codice sorgente".

Il controllo del codice sorgente non è magico. Provalo, ma abbandonalo se non aggiunge abbastanza valore per compensare il costo.

Roba che non metterei nel controllo del codice sorgente:

• Chiavi e password segrete
• L'SDK anche se è la stessa directory e se creo una patch per l'SDK, allora dovrei renderlo un altro progetto poiché sarebbe per framework anziché per app
• Librerie di terze parti come. Rimanenze da migrazione, backup, codice compilato, codice con altra licenza (forse)

Quindi non lo faccio hg addremoveper esempio da quando faccio un nuovo clone ogni tanto quando l'SDK si aggiorna. Questo mi fa anche fare un backup completo ogni volta che SDk si aggiorna e controlla che una nuova versione clonata dal repository stia bene.

Consiglio vivamente il seguente libro che affronta le vostre preoccupazioni:

Consegna continua: rilasci di software affidabili tramite automazione di build, test e distribuzione . In particolare, il capitolo 2 tratta degli elementi da sottoporre al controllo del codice sorgente, che come molti hanno già detto, è praticamente tutto tranne il contenuto generato principalmente a seguito di una build.

Non sono d'accordo con una parte della risposta accettata fornita da @FrustratedWithFormsDesigner in quanto sostiene che non mette in controllo della versione gli strumenti necessari per costruire il progetto. Da qualche parte nel controllo del codice sorgente (adiacente al codice in fase di creazione) dovrebbero esserci gli script di compilazione per compilare il progetto e creare script eseguiti solo da una riga di comando. Se con strumenti intende, IDE ed editor, non dovrebbero essere tenuti a costruire il progetto in alcun modo. Questi sono buoni per lo sviluppo attivo / rapido per gli sviluppatori e l'installazione di questo tipo di ambiente potrebbe anche essere copiata o scaricata da un'altra sezione di SCM o da un qualche tipo di server di gestione binaria e l'installazione di tali IDE dovrebbe essere il più automatizzata possibile.

Sono anche in disaccordo con quanto afferma @Yannis Rizos riguardo al posizionamento delle configurazioni per gli ambienti nel controllo del codice sorgente. Il motivo è che dovresti essere in grado di ricostruire qualsiasi ambiente a piacimento usando nient'altro che script e non è gestibile senza avere le impostazioni di configurazione nel controllo del codice sorgente. Non esiste inoltre una storia di come si siano evolute le configurazioni per vari ambienti senza mettere queste informazioni nel controllo del codice sorgente. Ora, le impostazioni dell'ambiente di produzione potrebbero essere confidenziali o le aziende potrebbero non volerle inserire nel controllo della versione, quindi una seconda opzione è quella di metterle ancora nel controllo della versione in modo che abbiano una cronologia e dare a questo repository un accesso limitato.

Tieni tutto il codice nel controllo della versione e tutte le configurazioni e i dati utente fuori. Per essere specifici di drupal, devi mettere tutto nel controllo versione tranne i file e settings.php