Quali criteri di check-in devono essere considerati per il controllo della versione?

Question

Ho il compito di aiutare a configurare i modelli di processo e le politiche di check-in per l'installazione TFS 2008 della mia azienda.

Oltre a tre criteri di check-in (un'azione di archiviazione deve contenere commenti, un file di codice deve essere sottoposto a peer-review, deve esserci un elemento di lavoro associato a un check-in), mi è stato chiesto considerare e implementare qualsiasi altro.

Quali sono alcune delle politiche più importanti o utili da applicare per il controllo della versione?

Answer 1

Meno sono e meglio è.

Di solito in un'organizzazione si desidera facilitare l'attrito del check-in per garantire che si incoraggino gli sviluppatori a effettuare frequenti piccoli check-in discreti anziché effettuare il check-in di un carico di cose contemporaneamente. Poi di nuovo vuoi assicurarti di avere una base di codice funzionante per tutti coloro che ne hanno bisogno e stai acquisendo i dati di cui hai bisogno per migliorare il processo di consegna del software.

Personalmente, una politica per applicare i commenti di changeset e una politica di associazione degli articoli di lavoro sono accettabili, poiché acquisiscono metadati facili da ricordare in quel momento ma difficili da trovare in seguito. Incoraggia inoltre gli sviluppatori a prendere l'abitudine di avere un oggetto di lavoro per tenere traccia di tutti i pezzi di lavoro, anche di sviluppo sperimentale o picchi.

Il processo di revisione tra pari potrebbe essere eseguito meglio utilizzando la ramificazione o un altro processo piuttosto che forzare una revisione tra pari ad ogni check-in, tuttavia ciò dipende dal processo.Ricorda inoltre che puoi avere note di check-in obbligatorie in TFS per acquisire metadati come il revisore del codice. Una nota per il check-in è leggermente diversa da quella per il check-in ed è spesso confusa.

Se vuoi leggere ulteriori discussioni sulle politiche di check-in, dai un'occhiata a blog post I did on the balancing act a while ago. Anche per ascoltare qualche discussione in più sulle politiche di check-in, ho registrato un podcast di recente con un altro MVP di Team System che parla del loro utilizzo di TFS e potrebbe essere interessante (Radio TFS, Using TFS with Ed Blankenship). Alla fine abbiamo anche fatto un Radio TFS episode all about check-in policies nel 2008 che potrebbe essere di interesse.

Answer 2

Alcune regole che seguiamo nella nostra azienda:

• impegnare tutte le modifiche relative alla stessa attività in una sola volta (che aiuterà rivedere le modifiche e rollback futuri o si fonde, se necessario).
• commenti basati su modello (ad esempio: prefisso tutti i commenti con un codice che rappresenta ciò che è stato fatto, + per gli aggiunti, - per i rimuovi, * per gli aggiornamenti,! Per le modifiche importanti, ecc.).
• Ovviamente sempre il codice di check-in che viene compilato e completato il lavoro sulla linea principale.
• check-in lavoro quotidiano non finito alle filiali.

Answer 3

Non rompere la build! Certo, trovare la soluzione automatica per controllarlo e rifiutare il check-in è la sfida.

Answer 4

Francamente, meno politiche, meglio è. Più politiche hai, maggiore è l'incentivo per NON usare il controllo di versione. Quello che succede allora è:

• Il codice è sviluppato su sistemi di controllo di origine paralleli e incontrollati, e solo la revisione finale va a quella ufficiale.
• Le persone ritardano il più possibile, diminuendo la visibilità di ciò che stanno facendo agli altri sviluppatori.
• Le persone eviteranno davvero di commettere qualcosa se possono farla franca, e alcuni troveranno un modo per farla franca.

In effetti, penso che le vostre tre politiche di check-in siano già troppo. Ad esempio:

• Il codice sottoposto a peer-review prima del check-in rende molto più difficile l'archiviazione del lavoro in corso. Invece, se il sistema di controllo del codice sorgente lo consente (e molti lo fanno), controlla se l'origine è sottoposta a peer review o meno. Con alcuni sistemi puoi creare un ciclo di vita per una revisione, con altri che potresti creare rami e altri ancora che potresti usare tag.
• Avere un elemento di lavoro associato a un check-in rende impossibile agli sviluppatori di fare programmi di esplorazione o avere iniziative su possibili miglioramenti. Soffoca gli sviluppatori. Invece, assicurati che ogni revisione che va ai test di integrazione o ai test di accettazione degli utenti, per non parlare della produzione stessa, sia associata a un oggetto di lavoro.

Questo potrebbe sembrare anti-Enterprise, ma sono solo alcune cose che abbiamo appreso in alcuni decenni di sviluppo del software. La maggior parte delle organizzazioni imprenditoriali non sono state incluse in questo, ma, alla fine, lo faranno. Quindi potresti andare nella direzione opposta, ma non dire che nessuno te l'abbia mai detto.

Raccomando il Agile Manifest e, in particolare, Lean Software Development per i principi generali.

Oppure, tenendo in considerazione la filosofia di progettazione Stack Overflow, rendere il sistema premiare il comportamento desiderato.

Answer 5

Cerca di mantenere basso il numero di sviluppatori che lavorano sullo stesso ramo. In questo modo il ramo rimane stabile rispetto alla compilazione, ai test unitari e alle regressioni. È un incubo se uno sviluppatore esegue un controllo in cui compila, ma il suo codice interrompe un'area chiave dell'applicazione (come il login).

Se è necessario avere più di 10 sviluppatori che controllano il codice nello stesso ramo, abbiamo avviato un criterio di posta elettronica in cui lo sviluppatore che effettua il check in avvisa tutti che stanno effettuando il check-in, in modo che nessuno tenti di aggiornare i loro copia della filiale nel bel mezzo di un check-in. A volte, abbiamo dovuto fare il contrario, dove abbiamo messo da parte un tempo nella data per proibire i check in, in modo che gli aggiornamenti siano sicuri.

Answer 6

Quelli che usiamo dove lavoro sul TFS sono:

• analisi del codice
  • Questo assicura che tutto il codice è stato compilato sulla macchina sviluppatori prima di essere verificata in
• Elemento di lavoro Associazione
  • Se hai fatto una modifica, dovrebbe esserci stato un compito assegnato!
• Ultima generazione corretta
  • Utilizzando il TFS Costruire Server per verificare che il codice corrente nel controllo del codice sorgente compilato su una macchina indipendente
• Arrivo Commenti (parte degli Utensili TFS - http://msdn.microsoft.com/en-us/teamsystem/bb980963.aspx
  • È bello poter vedere un riepilogo del check in senza dover andare all'oggetto/i di lavoro