pratica di controllo della versione

Question

Nel mio attuale lavoro la pratica del supervisore è quella di controllare solo il codice pronto per la produzione.Più recentemente, il progetto a cui stavo lavorando prevedeva il lavoro di 3 diversi sviluppatori con alcune sovrapposizioni di file.Ciò significava integrare manualmente le modifiche nonostante il fatto che alcune modifiche richiedessero un giorno e poi venissero completate.Volevo vedere se questa era una pratica comune e ottenere suggerimenti su come cambiare questa pratica con la consapevolezza che molte volte la mia opinione significa poco nel grande schema delle cose.

Answer 1

È possibile utilizzare vari modi per gestire questa situazione, a seconda del sistema di controllo del codice sorgente.

Filiali private:Ti consente di effettuare il check-in e di lavorare sul codice mentre sei in viaggio, unendoti avanti e indietro nei momenti appropriati.

Scaffali/set di modifiche confezionati:Ti consente di archiviare set di modifiche e inviarli per la revisione, assicurandoti che siano pronti per la produzione prima del check-in.

Per quanto riguarda se questo sia un modo appropriato di lavorare, non consentiamo il check-in alle filiali principali senza previa verifica.Per superare la revisione, il tuo codice deve superare vari strumenti automatizzati e quindi deve essere accettabile per il tuo revisore peer.Per alcune definizioni di "pronto per la produzione" - questo è tutto.Pertanto, facciamo qualcosa di simile a quello che fai tu.Tuttavia, utilizziamo filiali private per garantire che i check-in possano ancora essere effettuati mentre è in corso e che altri check-in non debbano interferire.

Se pronto per la produzione significa testato in un ambiente di integrazione, sembra che potresti aver bisogno di rami di gestione temporanea o qualcosa di simile.

Answer 2

Il codice archiviato dovrebbe essere sottoposto a test unitario, ma, per me, "pronto per la produzione" implica che sia stato sottoposto a integrazione e test di sistema.Non puoi farlo fino al blocco del codice, quindi non vedo come puoi farlo prima di ogni check-in.

Answer 3

Inizia passando da VSS a qualcosa di più affidabile e ricco di funzionalità.Vedere Come convincere un'azienda a cambiare il proprio controllo del codice sorgente

Quindi applicare le buone pratiche conosciute:

• Controlla spesso
• Raccogli spesso le modifiche degli altri, per semplificare l'unione
• Utilizzare velocemente test unitari per assicurarsi che ogni modifica soddisfi un livello minimo
• Richiedi che il codice archiviato venga sempre creato e superi sempre i test.

A questo punto non sarai "pronto per la produzione":avrai ancora bisogno di un paio di settimane per testare e correggere prima di poterlo implementare.Risparmiare quel tempo è fantastico per te e fantastico per il tuo cliente, quindi investi in:

• Test di accettazione automatizzati di alta qualità.

Answer 4

non sarebbe una buona idea avere un ramo di test del repository in cui sia possibile eseguire il check-in del "codice non pronto per la produzione" dopo che le modifiche sono state apportate e testate?

il trunk principale non dovrebbe mai avere un codice controllato che interrompa la build e non superi i test unitari, ma i rami non devono avere tutte queste restrizioni in atto.

Answer 5

Personalmente non lo approverei perché a volte questo è il modo migliore per individuare il codice problematico con sviluppatori meno esperti (vedendolo mentre ci stanno lavorando) e quando "effettui il check-in presto e spesso" puoi ripristinare le modifiche precedenti apportate (mentre stavi sviluppando) se decidi che alcune modifiche apportate in precedenza erano in realtà un'idea migliore.

Answer 6

Penso che potrebbe essere il controllo della versione che utilizziamo, VSS in combinazione con la mancanza di tempo per apprendere la ramificazione.Mi piace molto l'idea dei check-in notturni per aiutare con lo sviluppo ed evitare il "Going Dark".Lo vedo resistente ai trunk ma forse costruendo una SS di sviluppo e quando il codice è pronto per la produzione spostalo nella SS di produzione.

Answer 7

Dalle pratiche che ho visto il termine qualità della produzione viene utilizzato come "spaventoso" per garantire che le persone abbiano paura di rompere la cima dell'albero, non una brutta cosa a dire il vero perché la cima dell'albero dovrebbe sempre funzionare, se possibile.

Direi che la migliore pratica è che dovresti unire solo elementi distinti (ad es.separati) componenti funzionali sulla cima dell'albero.Se hai una sovrapposizione significativa sui delta degli stessi file sorgente, penso che questo "potrebbe" indicare che da qualche parte lungo la linea la gestione del progetto si è interrotta e che quegli sviluppatori avrebbero dovuto unire le loro modifiche in un ramo di integrazione separato prima di passare al sorgenti della linea principale.Un singolo sviluppatore che afferma di aver testato le proprie cose è irrilevante, perché la cosa che hanno testato è cambiata!

Cercare di risolvere i problemi di integrazione sulla linea di codice principale inevitabilmente bloccherà altri invii non correlati.

Answer 8

Supponendo che tu stia lavorando in un sistema di controllo della versione centralizzato (come Subversion) e presupponendo che tu abbia un concetto di "tronco" (dove risiede l'ultimo codice ben funzionante):

Se lavori su nuove funzionalità in "rami di funzionalità"/"rami sperimentali", allora è corretto eseguire il commit del codice che è lungi dall'essere finito.(Una volta completata la funzione, inserisci il risultato che si comporta bene nel "tronco".)

Ma non vincerai un concorso di popolarità se inserisci codice non compilabile/ovviamente non funzionante nel "trunk" o in un "ramo di rilascio".

I programmatori pragmatici fai intitolare un libro Controllo pragmatico della versione utilizzando Subversion che include una sezione con consigli sulle filiali.

Answer 9

Effettua il check-in in anticipo e fai il check-in spesso per due motivi principali:

1: potrebbe semplificare l'integrazione del codice

2 - nel caso in cui il tuo computer esploda le tue settimane di lavoro non sono perdute

Answer 10

Un approccio che mi piace particolarmente è quello di avere diverse versioni del ciclo di vita nel depot.Cioè, ad esempio, avere una versione di sviluppo del codice in cui gli sviluppatori archiviano il codice su cui si sta lavorando;quindi potresti avere una versione beta, in cui potresti aggiungere correzioni beta al tuo codice;e poi una versione di produzione.

C'è un ovvio sovraccarico in questo approccio, come il fatto che avrai uno spazio di lavoro più ampio sul tuo computer locale, il fatto che dovrai avere un processo di migrazione in atto per spostare il codice da una fase a quella successiva (il che significa un blocco del codice durante l'esecuzione dei test di integrazione associati alla migrazione) e che, a seconda della complessità dei progetti, potrebbe essere necessario disporre di strumenti che modificano impostazioni, variabili di ambiente, voci di registro, ecc.
Tutto questo è una seccatura da configurare, ma lo fai solo una volta e, una volta che hai tutto a posto, lavorare su diverse fasi del codice diventa un gioco da ragazzi.

Answer 11

@bpapa

I backup notturni delle cartelle di lavoro sui server impediranno di perdere più di una giornata di lavoro.

@tonyo

Vediamo che i documenti relativi ai requisiti sono stati completati il ​​giorno dopo aver terminato la codifica.Questo ti dice qualcosa sulla nostra gestione dei progetti?

Siamo un piccolo negozio quindi, anche se penseresti che il cambiamento sia facile, ce ne sono alcuni qui che non si piegano ai vecchi metodi.