Quali sono alcune buone pratiche prima di effettuare il check in del codice sorgente? [chiuso]

Il mio team utilizza Team Foundation Server per il controllo del codice sorgente e oggi ho corretto alcuni bug e l'applicazione test fumo prima di effettuare il check-in, ma ho dimenticato di commentare del codice. (Questo codice ha reso l'interfaccia utente un po 'strana.)

Voglio sapere quali sono le buone pratiche prima di effettuare il check-in del codice - Non voglio ripetere questo tipo di errore.

Una cosa che ho preso l'abitudine di fare è sempre guardare le differenze di ogni file che sto per fare il check-in, proprio prima di fare il check-in.

Non devi mai effettuare il check-in del codice commentato. Se hai del codice che deve essere commentato prima del check-in, stai sbagliando.

Per quanto riguarda le regole:

1. Ricevi le ultime
2. Risolvi i conflitti di unione

3. Costruire

   3.1 Correggere errori di compilazione

4. Esegui test

   4.1 Correggere i test rotti

5. Vai a 1 (fino a quando non c'è nulla di nuovo da ottenere)

Effettua il check-in solo quando tutti i passaggi sono completi.

Vedi la danza del check-in .

Altre buone pratiche:

• Rivedere l'elenco dei file da archiviare per assicurarsi che siano i file previsti.
• Rivedere le modifiche per ciascun file (eliminazioni / aggiunte / differenze)

Non sto cercando di essere troppo un pantofola qui, ma il presupposto in questa domanda (e tutte le risposte tranne una) si applica principalmente ai VCS centralizzati, come TFS, SVN, Perforce, ecc.
Abbastanza giusto, è quello che l'OP sta usando.

D'altra parte, tuttavia, quando si utilizza DVCS (come Mercurial e Git), di solito non si deve attendere il check-in e la maggior parte delle cose menzionate nelle risposte - come diff, get latest, merge, ecc. - non sono necessarie . Anche cose come le revisioni del codice e i test sono meglio fare dopo il check-in (anche se forse prima di spingere, a seconda ...)
L'unica eccezione che ho visto qui (finora) è quella di associare un oggetto di lavoro. Naturalmente, anche commentare il check-in è buono ...

Tre cose che non ho visto in altre risposte:

Includi nuovi file

• Cerca nuovi file che non fanno parte della tua lista dei cambiamenti
• Può essere specifico per gli SCM come Perforce: devi dirlo a tutto ciò che sta cambiando.

Ripristina file invariati

• Odio quando guardo i cambiamenti degli altri e c'è un elenco di modifiche con nove file, ma solo tre di questi sono stati modificati.
• Ripristino anche i file con spazi bianchi o modifiche altrimenti prive di significato.

Controlla il commit inviato

• Assicurati che la build rimanga verde dopo il commit.
• Avevo una seconda macchina che sincronizzavo, costruivo ed eseguivo dopo i miei commit, quindi se qualcosa fosse andato storto, avrei potuto facilmente saltare e sistemarlo.

Due cose quando uso Git:

Atomic si impegna:

• Mettere in scena solo modifiche funzionali individuali per il commit.
• Impegnati il ​​più piccolo possibile. Renderli facili da correggere, ripristinare e capire.
• Uso git add --patchper dividere la mia modifica in più parti se necessario.

Visualizza le differenze durante il riepilogo

• Controllo sempre in git commit --verbosemodo da poter vedere un diff della mia modifica mentre sto digitando il mio messaggio di commit. (O uso il mio git-vim patchato per mostrare il diff.)
• Ciò rende molto più semplice esaminare le modifiche e descrivere l'intero commit. Occasionalmente, in questa fase prendo cambiamenti non intenzionali. (Descrivere la modifica ti aiuta a pensarci.)

Alcuni elementi di "buone pratiche" che impongo sui server del mio team sono piuttosto semplici. Innanzitutto, prima di effettuare il check-in, dovresti sempre ottenere le ultime ed eseguire una build locale, per assicurarti che nessun altro abbia controllato qualcosa con cui il tuo codice si scontrerà. Inoltre, prenditi cura di eventuali conflitti di codice sul tuo computer locale, non sul server. Una volta che il tuo codice, con l'ultimo codice scaricato, è stato confermato per compilare e funzionare correttamente, sei pronto per il passaggio successivo. Esegui eventuali test automatici, quindi avvia il check-in per assicurarti che funzionino correttamente. Quindi, per essere sicuro, torna di recente.

È possibile, come amministratore TFS, imporre commenti su tutti i check-in. Consiglio di inserire sempre i commenti relativi al check-in per il proprio lavoro, indipendentemente dal fatto che venga applicato o meno. Se hai la possibilità di farlo, applicalo. Assicurati che i commenti siano, almeno, un riepilogo generale di ciò che hai modificato dall'ultima volta che hai eseguito il check-in del codice. In questo modo, se qualcosa va storto, puoi guardare attraverso i check-in e vedere, approssimativamente, ciò che è stato modificato in quel check-in. Rende molto più semplice il debug di una build non funzionante.

Inoltre, se disponi dei privilegi di amministratore di TFS, imponi build cumulative sui check-in (per assicurarti che tutti gli altri sappiano immediatamente se il loro check-in interrompe qualcosa) e puoi impostare il server per eseguire un check-in gated ( se il codice archiviato interrompe la compilazione, il server lo rifiuta), oppure puoi semplicemente farlo creare un bug e assegnarlo a chiunque abbia interrotto la compilazione.

Ci sono alcune altre opzioni che puoi attivare o disattivare per mantenere tutto in ordine, o suggerire al tuo amministratore TFS di attivare per mantenere le cose belle e pulite ... ma sono in gran parte delle preferenze

Cerca e sostituisci le parolacce ;-)

Se esegui il check-in da Windows, controlla se il tuo codice non ha quei caratteri ^ M invisibili - gli editor in UNIX spesso forniscono errori / avvisi a causa di ciò.

Prova anche a sostituire le schede: diversi utenti finiranno per vedere le schede in modo diverso alcune con 4 spazi, altre 8 e non buone per la leggibilità del codice.

Il miglior approccio IMHO è fare in modo che uno script predefinito verifichi il codice in base alle linee guida di codifica della propria organizzazione. Un sacco di sistemi di controllo del codice sorgente ha questa funzionalità.

Nella mia azienda utilizziamo le recensioni per il check-in. Questi non devono essere dettagliati, ma solo mostrare a qualcuno le differenze nella tua lista dei cambiamenti e parlare attraverso di loro a volte evidenzierà lo strano errore che hai perso nei test.

Il nostro server di controllo del codice sorgente non ti consentirà di effettuare il check-in se non annoti il ​​nome del revisore nei commenti (nel modulo! Iniziali, ad esempio! BW se Bruce Wayne ha fatto la tua recensione). Il revisore riceve un'email in cui rileva che ha contribuito alla revisione. Questo è aperto allo sfruttamento evidente ma sembra funzionare abbastanza bene.

Quando possibile, mi piace associare un check-in a un oggetto di lavoro. Questo ti dà alcune informazioni contestuali su PERCHÉ questo è stato cambiato, non solo COSA è stato cambiato. TFS ha un sistema di tracciamento degli oggetti di lavoro abbastanza decente, quindi è piuttosto banale da fare al momento del check-in.

(questo è in aggiunta alla revisione delle differenze delle mie modifiche)

Una piccola cosa che faccio è non fare il check-in dei file che non sono realmente cambiati. Questi file potrebbero essere stati modificati inavvertitamente, oppure potrebbero essere stati coinvolti in refactoring che sono stati sottoposti a rollback o che sono stati altrimenti sottoposti a moot.

In questo modo, il changeset (associato a un oggetto di lavoro) contiene esattamente i file necessari per soddisfare l'oggetto di lavoro.

Per combinare tutte le risposte qui e dare una lista di controllo completa

1. [check in / check out] non dovresti effettuare il check-in direttamente allo stream su cui stanno lavorando gli altri. Dovresti avere una strategia di streaming: ad esempio per sviluppatore uno stream in cui puoi effettuare il check-in e il check-out in modo indipendente senza disturbare gli altri: il tuo lavoro sarà essere al sicuro ma nel proprio flusso di sviluppo, quindi [solo nel proprio flusso di sviluppo]. Ad ogni check in lo associ ad un record di modifica in modo che le tue modifiche siano atomiche rispetto a quella modifica chiamata set di modifiche (in modo da poter distribuire singoli rfc / bug ecc ... senza dover consegnare "tutto").

2. [quindi rebase con lo stream del tuo team] significa che ricevi le modifiche dagli altri nel tuo stream. Durante tale operazione è possibile visualizzare nella finestra di dialogo di unione tutti i "diff" e analizzarli o ... se ce ne sono migliaia e / o non si utilizza il codice ma anche, ad esempio, modelli di dati / progetti siebel ecc ... fare affidamento su fusioni non banali, fusioni banali-automatiche e banali manuali, l'ultima categoria contiene quelle difficili. Ricorda che stai ancora lavorando nel tuo stream.

3. [rebase completo] Se tutto va bene, controlla tutte le modifiche che hai appena ricevuto dallo stream del team: il tuo stream è ora aggiornato

4. [consegna] ora consegna il tuo lavoro allo stream del team. Se non si desidera fornire tutto ciò che è possibile selezionare, ad esempio 1 RFC specifico con le versioni specifiche dei file o una serie di RFC / difetti risolti.

5. [test di consegna] dovrebbe andare bene, ma dato che esiste la possibilità che qualcuno nel frattempo abbia consegnato anche delle modifiche: puoi testare se il tuo lavoro funziona con le ultime modifiche nel flusso del team. Con le stesse finestre di dialogo di unione che mostrano le differenze.

6. [consegna completa] completa la consegna e il tuo lavoro è ora nel flusso del team.

Per renderlo più complesso: poiché esiste ancora la possibilità che il lavoro che hai consegnato = ok MA stai già lavorando su un'altra versione, devi basare sempre dopo la consegna e indicare quale baseline è quella preferita per gli altri utenti . Ciò garantisce che altri sviluppatori ne ottengano una consigliata e non l'ultima versione sullo stream (se si lavora in quello scenario). Questo è anche un triplo controllo in modo che anche se le ultime versioni nello stream del team sono "cattive", non sono ancora quelle a cui gli altri si rifanno o guardano e il tuo gestore della configurazione può unire la versione precedente alla versione successiva per annullare la tua consegna.

• la risposta dall'istumismo avviene 2 volte: nei passaggi 2 e 6
• la risposta di Oded al check-in dance: idem ma un ulteriore livello di consegna e rebase al check-in / check-out per assicurarsi di lavorare in modo isolato e gli errori possono sempre essere facilmente eliminati anche nelle fasi successive
• la risposta dalla risposta alla gilda: ottenere le ultime è il passaggio 2. Per la build: dipende davvero se HAI una build ... nel mio mondo hai input da modelli di dati, documenti di parole, fogli di requisiti, dati di configurazione da informatica, siebel, ecc., e sì anche codice java, codice .net ecc ... che tutti dovrebbero mescolarsi insieme. Quindi non c'è davvero "una build" qui ma più un'integrazione più in alto a seconda che quella singola build del tuo "codice" si integri con tutto il resto del roba dal momento che non puoi sapere con certezza se si tratta di roba di integrazione e dipende da i loro ambienti di test potrebbero essere compilati roba necessaria o alle consegne più alte un'altra build perché ha bisogno di qualcosa da un altro team.
• la risposta della gilda su commenti e richieste: penso che ogni ambiente in cui non si ha l'integrazione di VERSIONI e Modifiche nei set di modifiche (e tipo: difetti, RFC, hotfi) non sia maturo. Penso che sia un caos se non riesci ad esempio ad automatizzare le note di rilascio con la quantità di bug e rfcs inviati che sono cliccabili attraverso le esatte versioni che vengono toccate (poiché ad esempio la versione 1 e la versione 3 di hello.c potrebbero benissimo essere consegnate ma versione 2 non avrebbe dovuto essere consegnato perché quella roba lì dentro sarebbe parte di una versione successiva ma alcuni noob l'hanno già inserita) (quindi significa una decisione manuale SE vuoi anche eliminare la versione 3 di ciao. c MA togliere la versione 3 significa che devi anche eliminare tutte le altre versioni toccate da quel RFC / difetto, quindi devi essere in grado facilmente e velocemente con uno strumento per estrarre il tutto) (anche se più sviluppatori hanno lavorato su parti di lo stesso RFC) ma almeno hai bisogno di roba intorno per decidere su di esso ecc ...). La documentazione aggiuntiva è sempre utile ma associando i set di modifiche si ottiene il cerchio completo: una versione <- un set di modifiche <- elementi di lavoro <- un ticket / rfc / difetto <- un requisito. Significato: sai quali requisiti sono interamente o completamente consegnati: un requisito ha più RFC o bug o altro. RFC ha più oggetti di lavoro per più persone. quell'elemento di lavoro corrisponde a una serie di modifiche che esiste di una serie di versioni (ad esempio le versioni 1 e 3 di hello.c sul flusso di integrazione che sono ovviamente NON le versioni 1,
• il commento di luis.espinal: non interrompere la build è ricontrollato in rebase e consegnare ancora ... ci sono consegne più alte per i "gestori delle versioni e build meister" che dovrebbero vedere i set di modifiche e le linee di base come le loro informazioni. "Non lavorare mai direttamente sul ramo principale" sì, la struttura del flusso può essere grande o semplice ma in sostanza: gli sviluppatori hanno il loro flusso, consegnano a un flusso di squadra che consegna a un flusso di rilascio. -> in modo che le consegne da tutti i team (ad esempio team di documentazione, team di requisiti, team di sviluppo,

Nel tuo esempio dai che hai dimenticato di commentare il codice. Gli errori accadono. Il sistema di gestione della configurazione che lo circonda dovrebbe occuparsene. Può davvero essere che, ad esempio, avvengano migliaia di modifiche e che "build" e "integrazioni" avvengano in una gerarchia di flussi su server diversi concatenati ed elaborati nel tempo. Quindi, anche se dopo 5 mesi il tuo codice commentato viene testato su un server di integrazione perché il tuo codice necessita di integrazione con altri codici e sistemi, dovrebbe comunque essere possibile eliminare atomicamente il tuo set di modifiche e continuare. Quindi la migliore pratica è più o meno ad un livello superiore. La progettazione generale dei flussi di gestione della configurazione dovrebbe occuparsene. Per i singoli sviluppatori è buona prassi naturalmente convalidare / unit test. Ma dal quadro generale a "

Alcuni dei seguenti si applicano più di altri (o in forme diverse) a seconda del tuo SCM, quindi eccoli qui:

1. Non interrompere la compilazione: controlla solo il codice che viene compilato.
2. Commenta i tuoi check-in (e possibilmente i tuoi check-out se SCM ti offre questa opzione).
3. Non tenere le cose deselezionate per lunghi periodi di tempo.
4. Effettua il check-in spesso (se possibile più volte al giorno).
5. Etichetta in modo significativo.
6. Etichetta regolarmente.
7. Non lavorare mai direttamente sul ramo principale.
8. Ogni rilascio alla produzione deve avere una propria etichetta (e un ramo di sola lettura fuori dal ramo principale, se possibile). Se possibile, fare lo stesso per le versioni di test UAT / Integration / Pre-production.
9. Dovresti essere in grado di costruire esattamente ciò che è in produzione da ciò che è nel tuo SCM e da un'etichetta.

NOTA : alcuni degli articoli sopra sembrano piuttosto ovvi, ma non crederesti a quante persone effettivamente lavorano sul ramo principale o apportano prima delle modifiche alla produzione e poi creano manualmente delta per passare al controllo della versione ... direttamente sul ramo principale. .. e con etichette. Dolce come la bile fermentata mescolata con succo di ascella non lavato ... sì, così.

Avere una lista di controllo personale. Avvialo vuoto quando sbagli, a una voce. Quando diventa una seconda natura rimuoverlo dall'elenco.

Esegui i test. Se passano, controllalo. Se sbagli e qualcosa supera i test, allora scrivi un test.

Facciamo il seguente ...

1. Test: vogliamo assicurarci che funzioni. Per lo meno, vogliamo sapere che non rompe nulla.

2. Revisione del codice, o almeno un controllo degli amici - Questo è un ottimo modo per garantire che le conoscenze vengano diffuse e che le persone siano tenute aggiornate. Aiuta anche a catturare i bug prima di controllare.

3. Invia un preavviso: un avviso anticipato viene inviato al gruppo prima del check-in. Lo scopo non è solo quello di far sapere agli altri quali file o aree stanno cambiando, ma dà loro un avvertimento (se dovessero scegliere di prenderne atto) nel caso in cui si prevede che tali cambiamenti li influenzeranno.

4. Alcune ore dopo l'invio dell'avviso, viene eseguito il check-in e il gruppo viene informato via e-mail. Tutti nel gruppo possono sapere quando viene eseguito il lavoro particolare su un bug o una funzione.

5. Una copia dell'avviso di check-in viene incollata nel record di correzione associato al bug o alla funzione. Durante la ricerca tra i record, scopriamo che è molto utile avere un'idea di cosa comportava la correzione / funzionalità.

Esegui i tuoi test unit su cui hai lavorato così diligentemente. Il verde è buono.

Assicurati che il tuo codice sia formattato correttamente (ad es. Per Java: seleziona il tuo codice e premi Ctrl-Shift-F in Eclipse). Ma fai attenzione a fare lo stesso per un intero documento.

Verifica sempre, sempre, sempre , che qualunque modifica tu abbia apportato non interrompa la creazione. Soprattutto piccoli cambiamenti che possono sembrare banali.

Una volta ho apportato una modifica molto piccola che non pensavo potesse causare problemi prima di lasciare il lavoro per il fine settimana. Abbastanza sicuro, quel piccolo cambiamento ha rotto la costruzione e non sono state eseguite prove notturne per il nostro progetto. Il capo delle domande e risposte non era molto contento di ciò, e giustamente.

Cerca parti delle modifiche che possono essere visualizzate come unità autonome.

Spesso, quando ho una correzione funzionante o un miglioramento del codice, ci sono alcune modifiche. Alcuni di loro sono specifici per il cambiamento di comportamento che sto cercando; altri sono refactoring che ho fatto per rendere più pulito quel cambiamento.

Preferisco controllare ciascun refactoring separatamente, con la sua descrizione del cambiamento, in questo modo:

REFATTORAZIONE: Rinomina da X a Y

X aveva senso prima perché ... ma ora dovrebbe essere Y. Questo è legato al lavoro per il numero 9.

Quindi, una volta verificato ogni buon refactoring, il cambiamento di comportamento finale è spesso banale.

Inoltre, alcune modifiche influiscono su molte righe di codice ma non sono molto interessanti, mentre altre sono molto localizzate ma hanno un impatto importante. Se queste modifiche vengono registrate insieme, può essere difficile leggere le differenze. Quindi, li tengo separati.

Più tardi, quando qualcuno sta leggendo la storia del cambiamento, è ovvio come le cose sono arrivate allo stato attuale delle cose e perché sono così. È anche banale annullare il mio cambiamento di comportamento perché non è aggrovigliato con tonnellate di altre modifiche.

Fai quello che faresti quando restituisci qualcosa che hai preso in prestito da qualcuno. Assicurarsi che sia pulito e in buona forma. Se hai fatto un pasticcio, assicurati di pulire prima di restituire il codice al suo proprietario (nella maggior parte dei casi, il tuo datore di lavoro).

Tengo un repository hg locale per il mio lavoro.

• Ogni volta che eseguo il check in, guardo il diff e mi assicuro che tutte le modifiche siano accettabili.
• Provo a notare la caratteristica chiave del check-in.
• Cerco di mantenere ogni dimensione di commit su una caratteristica chiave.

Non pretendo che questi siano i migliori, ma funzionano per me.

Quando scrivo un codice che so che non è destinato al check in, aggiungo una riga prima che contenga "// TEMP:" e dopo con "// END TEMP.". Questo, insieme a fare diff prima del check-in, promette che non controllerò quel codice per errore.

Testa a fondo tutto ciò che hai aggiunto o modificato. Prova ogni possibile caso che ti viene in mente di provare. Non lasciare i test al QA. Se avessi un sandwich per ogni volta che ho apportato alcune piccole modifiche, e poi ho provato alcuni casi di test solo per essere al sicuro, e ho subito visto i problemi, avrei molti sandwich. Di solito mi dico ad alta voce "Sono davvero felice di averlo provato ..."

Dici che l'interfaccia utente è diventata strana dopo la modifica. Se avessi solo eseguito il programma e guardato l'interfaccia utente prima del check-in, avresti notato il problema?