Il commit / il check-in nel codice di tutti i giorni è una buona pratica?

Ho letto la nota di Martin Fowler sull'integrazione continua ed elenca come un must "Tutti si impegnano quotidianamente sulla linea principale".

Non mi piace impegnare il codice a meno che la sezione su cui sto lavorando non sia completa e che in pratica commetto il mio codice ogni tre giorni: un giorno per indagare / riprodurre l'attività e apportare alcune modifiche preliminari, un secondo giorno per completare le modifiche e un terzo giorno per scrivere i test e ripulirlo ^ per l'invio. Non mi sentirei a mio agio a inviare il codice prima.

Ora, estraggo le modifiche dal repository e le integro localmente di solito due volte al giorno, ma non lo commetto spesso a meno che non riesca a ritagliare un lavoro più piccolo.

Domanda: commettere ogni giorno una buona pratica che dovrei cambiare il mio flusso di lavoro per adattarlo, o non è consigliabile?

Modifica: Immagino che avrei dovuto chiarire che intendevo "impegnare" nel significato di CVS (noto anche come "push") poiché questo è probabilmente ciò che Fowler avrebbe significato nel 2006 quando ha scritto questo.

^ L'ordine è più arbitrario e dipende dal compito, il mio punto era quello di illustrare il lasso di tempo e le attività, non la sequenza esatta.

Non sono d'accordo con questa regola e sono d'accordo con quanto affermato da Mason Wheeler . Vorrei aggiungere alcune idee.

Cerco di impegnarmi ogni volta che ho una modifica significativa da impegnare: questo può essere più volte al giorno se correggo diversi piccoli bug, o una volta alla settimana se sto lavorando su un software più grande che non può essere utilizzato dal resto di il codice in qualsiasi modo significativo fino a quando non raggiunge uno stato coerente.

Inoltre, interpreto il commit come pubblicazione di una revisione significativa che contribuisce con nuove funzionalità alla base di codice. Penso che si dovrebbe provare a ripulire il codice prima di impegnarsi in modo che altri sviluppatori possano capire il significato e lo scopo del cambiamento quando guardano la cronologia delle revisioni. Meno cambiamenti vedono altri sviluppatori nella storia, meglio è: quando guardo la cronologia delle revisioni voglio vedere incrementi che aggiungono alcune funzionalità significative; Non mi interessa ogni piccola idea che ogni sviluppatore aveva e voleva provare prima di raggiungere la soluzione.

Inoltre, non credo sia una buona idea usare il server SVN (o qualunque sistema di controllo versione) come una funzione di backup in cui è impegnata l'istantanea corrente del codice (a condizione che sia compilata): è possibile utilizzare una chiavetta USB o un'unità USB esterna o un disco di rete per eseguire il mirroring del codice corrente in modo da non perderlo in caso di guasto del computer. Controllo delle revisioni e backup dei dati sono due cose diverse. La pubblicazione di una revisione non equivale a salvare un'istantanea del codice.

Infine, penso che non dovrebbe essere un problema impegnarsi di tanto in tanto (cioè solo quando si è veramente soddisfatti dello stato attuale del codice) ed evitare conflitti di unione non è una buona giustificazione per impegnarsi (troppo) spesso. Molti conflitti di unione si verificano quando persone diverse lavorano contemporaneamente sugli stessi file, il che è una cattiva pratica (vedere ad esempio questo articolo , punto 7). Unire i conflitti dovrebbe essere ridotto suddividendo un progetto in moduli con interfacce chiare e il minor numero possibile di dipendenze e coordinando il lavoro degli sviluppatori in modo che il codice su cui lavorano si sovrapponga il meno possibile.

Solo i miei 2 centesimi.

MODIFICARE

Un altro motivo per cui mi è venuto in mente un impegno prematuro è che una versione (molto) buggy non può essere testata. Se stai impegnando sul bagagliaio e il tuo team di test sta eseguendo test ogni giorno, potrebbero non avere una versione testabile per alcune ore (o per un giorno). Anche se non provi a correggere il bug e ripristini le modifiche, una ricostruzione può richiedere un paio d'ore. Con, diciamo, cinque tester che lavorano nella tua squadra, hai perso 5 x 2 = 10 ore di tempo della squadra a causa dell'inattività. Mi è successo una volta, quindi cerco davvero di evitare il più presto possibile i commit prematuri in nome del commit .

Commetto codice più volte al giorno . Ogni volta che raggiungo un punto in cui il codice è abbastanza completo da compilare e non rompe altre cose, entra.

Dovresti cercare di interrompere il tuo lavoro in modo da poter effettuare il check-in in sicurezza un paio di volte al giorno.

I razionali per questo sono due:

1. Qualsiasi lavoro non archiviato potrebbe andare perso - il tuo computer potrebbe avere un errore catastrofico. In questo caso, più a lungo aspetti, più lavoro perdi.
2. Più lavoro fai senza fare il check-in, più codice gli altri dovranno integrare quando deciderai finalmente che viene eseguito. Ciò introduce maggiori possibilità di conflitti e si fondono problemi.

Aderire in modo slavato a qualsiasi metodologia o pratica senza comprendere i motivi alla base non è mai una buona idea. Ecco da dove viene la programmazione cargo-cult.

Pertanto, "dovrei impegnarmi ogni giorno perché lo diceva Martin Fowler" è semplicemente stupido. E a volte è anche poco pratico. Se stai lavorando su una nuova funzionalità complicata, potresti non raggiungere un punto in cui valga la pena effettuare il check-in fino a quando non ci hai già lavorato per alcuni giorni.

Questo non significa che dovresti assicurarti che tutto sia perfetto prima di registrarlo. È un buon modo per perdere lavoro se qualcosa va storto. La cosa giusta da fare è sviluppare e usare il buon senso in materia. Le regole empiriche possono solo aiutarti così tanto.

Oded ha fornito due importanti motivi per impegnare il codice il più frequentemente possibile. Ne aggiungerò altri:

1. Mentre lavori sul tuo pezzo di codice, altri potrebbero aver bisogno di alcune funzioni su quel codice. Non dovrebbero aspettare 6 giorni per ottenerlo. In questo caso i miei colleghi di solito creano un prototipo nel mio pezzo di codice, lo commetto, aggiungo il corpo e lo commetto di nuovo. E questo di solito viene fatto in poche ore.

2. Il codice "comune" è per tutti di vedere ogni cambiamento il più presto possibile. Se il pezzo di codice su cui stai lavorando è totalmente separato dal lavoro degli altri e non li farai aspettare, allora si consiglia di creare un ramo su cui lavorare, quindi, se tutto ha successo, uniscilo a la linea principale.

Sono fermamente convinto a commettere ogni cambiamento logico che vale la pena mantenere. Effettuare il commit spesso e se il codice non vale la pena conservare, ripristinarlo in uno stato pulito. Più attendi per inviare / pubblicare il codice, più è difficile da implementare e maggiori saranno i problemi. Riceverai anche feedback sui tuoi contributi molto più rapidamente:

• rompono la costruzione?
• stai duplicando gli sforzi di un altro membro del team?
• stai facendo qualcosa di sbagliato?
• o la gente ti sta aspettando qualcosa?

Le piccole modifiche sono molto più facili da gestire.

Inoltre, vale la pena notare la differenza tra i diversi sistemi di controllo della versione. Alcuni, come Git (distribuito), ti permetteranno di eseguire il commit e il controllo dell'intera cronologia a livello locale, spingendo solo quando sei pronto per la pubblicazione. Altri, come SVN (centralizzato), combineranno i due passaggi rendendo i piccoli commit molto inefficienti.

Non dimenticare che i tuoi commit sono essenzialmente documenti di modifica. Quando le cose andranno male, sarai felice di avere più storia che non abbastanza. Un singolo impegno per settimane di lavoro mi sembra inutile. Finirei per leggere ogni singola riga di codice modificata anziché il riepilogo di ogni blocco logico.

Penso che la maggior parte delle risposte qui manchi uno dei punti principali nella dichiarazione di Martin Fowlers. Questo è legato all'integrazione continua . Il codice che non è archiviato (inserito / pubblicato / unito) nella linea principale non viene testato.

Questo non dovrebbe essere letto come un incoraggiamento a impegnare tutto il codice che hai nel tuo computer locale ogni volta che è il momento di lasciare l'ufficio. Come sottolineato da molti altri qui che sarebbe male, avrebbe rotto la build e causato una linea principale instabile.

Tuttavia, è incoraggiante cercare di apportare le modifiche in piccoli passaggi che possono essere registrati sulla linea principale senza causare problemi. Questo incoraggia l'evoluzione del codice invece di strappare tutto e riscrivere.

Ora, cosa c'è di buono in questo modo di lavorare?

1. Non impegnare grossi blocchi di codice o cambiamenti rivoluzionari riduce la possibilità di interrompere la build.
2. Se il tuo commit interrompe la build, è abbastanza banale identificare quali sono i problemi, ripristinarlo e quindi eseguire il commit di una versione fissa rapidamente.
3. Assicurandoti che tutti i test vengano eseguiti su ogni piccola modifica nel codice, ti assicuri di non introdurre bug o regressioni sottili che possono derivare dalla crescita del codice al di fuori dello schema di integrazione continua.

Naturalmente non tutti i cambiamenti si prestano a questo approccio. Come altri hanno sottolineato, nessuna regola è assoluta. Tuttavia, per i cambiamenti che dovrebbero rimanere fuori dalla linea principale per lungo tempo, impostare una linea principale alternativa con il proprio schema di integrazione continua e seguire lo stesso approccio nei suoi confronti. Con i VCS distribuiti di oggi è una cosa abbastanza facile da fare.

Argomenti per il check-in tutti i giorni:

• Il codice viene archiviato e sottoposto a backup in caso di guasto del disco rigido
• L'attività può essere registrata nelle note di commit ( cosa ho fatto giovedì ...? )
• L'integrazione con la base di codice esistente avviene prima e in blocchi più piccoli, sperando di identificare conflitti o unire i problemi prima
• Il tuo team ha visibilità su ciò su cui hai lavorato
• I tuoi colleghi possono lavorare prima con le tue interfacce, dando loro più tempo per integrarsi con il tuo "grande bit di codice complesso"
• Il tuo codice verrà testato nel mondo reale prima o almeno esposto a un uso maggiore di quello che fornirai, portando a una precedente identificazione di bug o omissioni.

Argomenti contro il check-in tutti i giorni:

• Non è necessario o non si desidera
• Non ho ancora "ripulito" il mio codice, è un casino
• Non ho tempo

Non credo che ci siano buone ragioni per effettuare il check-in meno del quotidiano a parte la pigrizia o la disorganizzazione. Niente di peggio di vedere il codice in esecuzione nell'ambiente di sviluppo non corrisponde al codice nel ramo di sviluppo perché qualcuno "non ha ancora finito" e quindi non ha effettuato il check-in.

Mi piacerebbe sbagliarmi su questo, quindi per favore fatemi sapere qualsiasi argomento legittimo contro il check-in giornaliero.

Se intendi "impegnare" come "unire in mainline", sicuramente non dovresti farlo ogni giorno su un progetto software che viene rilasciato ai clienti. Dovresti unire le modifiche apportate e testate, in modo che la linea principale sia sempre funzionante e rilasciabile, e non in uno stato interrotto con funzionalità semifinite.

Tuttavia, il lusso di lavorare con il controllo della versione distribuita di oggi è che puoi mantenere stabile la linea principale e allo stesso tempo fare git/hg/whatever committutto ciò ogni volta che senti di voler preservare lo stato delle cose. Lo faccio una volta ogni poche ore e sicuramente alla fine di ogni giorno.

Con DVCS puoi pubblicare il tuo lavoro, collaborare con altri nel tuo team e tenerlo aggiornato con le modifiche nel ramo principale. Puoi fare tutto ciò senza inquinare la stabilità del codice da cui dipendono i tuoi clienti e / o altri team.

In tempi in cui Subversion era la tecnologia più recente e non c'era modo di biforcarsi e unire i rami delle caratteristiche senza il dolore estremo, avere una linea principale in cui diverse caratteristiche erano in costruzione simultanea avrebbe potuto essere l'approccio migliore. Ma questa superiorità non si estende oltre il 2010.

In Team Foundation Server puoi 'Shelve' che non è lo stesso di un check-in, ma effettua solo un backup del tuo codice in modo che se la tua macchina muoia non hai perso le modifiche.

Ho anche visto case di software che hanno una "linea di sviluppo" e una "linea principale". Gli sviluppatori sono liberi di accedere alla linea degli sviluppatori ogni volta che lo ritengono opportuno e solo il caposquadra ha accesso alla linea principale, quindi sono responsabili della copia del codice dallo sviluppatore alla rete principale quando è pronta per la produzione.