Hai delle politiche di commit?

Question

Il mio capo ha annunciato ieri una nuova politica di commit per i check-in nel repository. Queste politiche sono valide per gli commit in head / trunk e filiali.
Un messaggio di commit deve contenere i seguenti elementi:

• Motivo (ID bug, ID progetto o modifica non funzionale)
• Nome del revisore

Dopo il commit dobbiamo anche creare un post sul blog di modifica nel nostro CMS.

Non sono un grande fan di queste politiche di commit, perché normalmente non ho bisogno di un revisore quando sto facendo cose nuove o sperimentali in un ramo non produttivo.

Hai delle politiche di commit che devi seguire?

Penso che sia una buona idea cambiare il ramo produttivo solo a causa di un bug report, ma gli impegni nei rami di sviluppo dovrebbero essere meno restrittivi.

Answer 1

Impegno anticipato e impegno frequente.

In realtà usiamo / trunk come sviluppo e tag per ramificare diverse versioni. Solo i cambiamenti intrusivi strutturali vanno in / rami.

Utilizziamo attivamente i tag per le versioni di produzione e accettazione, in modo da poter tornare indietro nel tempo facilmente. Qualsiasi cosa impegnata nel trunk dovrebbe contenere solo un messaggio che descriva ciò che è stato modificato o aggiunto brevemente.

Non sono un grande fan dell'uso dello spazio dei messaggi per collegarsi agli ID bug, ma richiede comunque una ricerca dell'ID, nel qual caso potresti anche cercarlo nel software di tracciamento dei bug e chiuderlo lì, cosa per me è circa lo stesso sforzo.

Per non dire che non mi piace alcuna integrazione svn: - Usiamo più bontà degli script nant automatizzati per creare rilasci che li ramificano in / tag - I puntelli svn memorizzano effettivamente i nostri numeri di versione: p. - hook script per la notifica e-mail e la registrazione dei messaggi (ottimo per incollare le note di rilascio della copia).

Answer 2

Abbiamo una serie di criteri che vengono applicati tramite un plug-in interno a Visual Studio. Controlliamo che le compilazioni di codice e che i test unitari siano stati eseguiti correttamente. Al momento controlliamo anche la copertura del codice ed emettiamo avvisi per il codice che non ha abbastanza test. Eseguiamo inoltre vari controlli di coerenza e verifichiamo che sia presente un'attività appropriata nel nostro sistema di gestione delle modifiche al fine di garantire la tracciabilità di tutte le modifiche.

Il vantaggio del supporto degli strumenti è eccezionale, in quanto non spetta alle persone rispettare le politiche, ma ovviamente c'è uno svantaggio e questi controlli richiedono tempo per essere eseguiti. Tuttavia, con molti sviluppatori è difficile applicare gli standard senza un adeguato supporto degli strumenti.

Answer 3

Un revisore sembra inutile per i motivi che hai citato, perché non tutto deve essere rivisto da altri.

In passato l'unica politica di commit che avevamo (dove ero solito lavorare) era quella di includere un commento che indicava cosa hai cambiato e perché, ma è più buon senso di ogni altra cosa.

Answer 4

Una politica di commit comune consiste nell'associare un ID bug al commit su trunk come giustificazione. A volte, i sistemi di controllo della versione e di tracciamento dei bug sono configurati per applicare questa politica.

Answer 5

La nostra politica di commit suona un po 'come la tua, solo che non la imponiamo su rami di attività (dove un ramo di attività è come un sandbox di uno sviluppatore per la sperimentazione).

I nostri commenti di commit devono includere un ID controllo modifiche (nuova funzionalità, miglioramento) o un ID problema (correzione bug). Devi anche includere una breve spiegazione del perché hai apportato questa modifica; il controllo di versione tiene traccia di chi, cosa, quando e dove.

Answer 6

Il mio messaggio di commit include una breve descrizione di ciò che ho implementato o modificato nelle classi.

Il numero di bug e le descrizioni aggiuntive che ho inserito nei commenti sopra il nuovo codice. ID all'interno dei messaggi di commit che inseriamo quando uniamo le modifiche in una branche con tag.

Ogni notte una build automatica controlla le diverse funzionalità e prodotti per assicurarsi che la base di codice sia stabile.

Ma alla fine penso che non puoi avere troppe descrizioni per classi nuove o modificate ma troppe politiche che devi fare prima di un commit. Il nome del revisore è qualcosa che non vorrei inserire nel messaggio di commit.

Pensa che a volte devi capire il codice che hai implementato 2 anni fa. E poi sei felice del commit dei messaggi che non sono come " Aggiorna dopo il debug " ;.

Answer 7

Abbiamo filiali per ogni versione principale rilasciata del software che è ancora attivamente supportata. Il check-in in uno di questi rami richiede un ID bug - questo è imposto da scmbug , che non solo controlla che il commento sia preceduto dall'ID del bug, ma cerca anche questo bug nel database dei bug, si assicura che sia assegnato al committer e potenzialmente controlla altri criteri (es. che il campo "fix in branch" sia la filiale è impegnata a).

Uno dei prodotti ha più possibilità di fallire in modi imbarazzanti, e il check-in per questo richiede non solo un ID bug ma anche una revisione del codice. Tuttavia, i criteri per la revisione del codice sono gestiti nel nostro database dei bug - abbiamo campi personalizzati per questo e il bug non può essere accettato e chiuso fino a quando non è stato rivisto. Per me questo funziona da un livello concettuale - probabilmente è meglio controllare il codice che si ritiene funzioni nel repository senza rivedere, quindi riaprire il bug e modificarlo se necessario invece di trattenerlo fino a quando non si è sicuri è pronto per il rilascio.

A parte questo, non esiste una politica esplicita per il trunk (anche se ovviamente i principi generali del check-in spesso senza interrompere la build, inclusi buoni messaggi di commit descrittivi, il check-in delle unità di lavoro si applicano comunque atomicamente).