TFS - My Work or Branch

4

Il mio team è recentemente passato da VSS a TFS 2013. In passato, c'era una regola "no check-in fino al completamento dell'elemento", difficile ma veloce, ma questo è impegnativo da parte di un paio di membri del team più recenti, con esperienza con Agile.

Al momento, sto lavorando a un cambiamento piuttosto ampio. In passato, secondo la nostra regola esistente, non effettuavo il check-in finché non era completamente completo (circa due mesi di lavoro). Con TFS, tuttavia, abbiamo alcune altre opzioni disponibili e ci sforziamo di ottenere un processo Agile. Parlando di questo con il team l'altro giorno, i due nuovi membri erano fermamente convinti che avrei appena controllato le mie modifiche (al trunk, che è il nostro ramo dev). Il mio problema con questo è che molti dei file che ho cambiato sono comunemente modificati in ogni ciclo di rilascio. Se effettuo il check-in prima che la funzione sia pronta per il rilascio, e poi uniscono le modifiche con le mie modifiche, non possiamo rilasciare nessuna modifica finché la mia non è pronta.

Le soluzioni attuali sulla tabella per questo problema sono:

  1. Crea un ramo specifico per questa funzione. Questo non si sposa con la nostra strategia di ramificazione scelta (promozione del codice), ma è considerato un caso speciale.
  2. Usa una mensola. In questo modo, almeno il mio codice viene eseguito il backup sul server, e posso unirlo in un secondo momento quando ho finito.
  3. Usa il mio lavoro (onestamente, ho appena scoperto questa funzione un paio d'ore fa). Lo stesso principio base di una mensola, anche se sembra essere una "pratica migliore".

Quale di questi (o forse # 4?) è la migliore soluzione al nostro attuale problema? Siamo consapevoli del fatto che in generale i nostri processi hanno problemi, e stiamo lavorando su di essi, ma ci vorrà del tempo per implementare un processo Agile reale in cui il lavoro è suddiviso in modo tale da effettuare il check-in anticipato e spesso è facile e causa zero problemi.

    
posta Dave Johnson 08.02.2015 - 17:52
fonte

1 risposta

3

Potresti chiederti perché è impossibile fare un rilascio finché le modifiche non sono state completate.

Nei progetti Agile, non è insolito rilasciare più volte al giorno, e tuttavia alcune funzionalità potrebbero richiedere giorni, settimane o mesi. L'approccio abituale consiste nell'avere interruttori che abilitano o disabilitano la funzione di pre-rilascio durante il runtime, in modo che tu , uno sviluppatore, possa eseguire la funzione, ma gli utenti ordinari non possono farlo.

In sistemi più complessi, uno switch simile ha un ulteriore vantaggio: consente di testare una funzionalità con alcuni utenti prima di abilitarla per tutti. Possono essere utenti che sono attivamente interessati a funzioni che non sono ancora disponibili per il pubblico in generale (e accettano il rischio di bug, perdita di informazioni, ecc.), O solo un gruppo di utenti casuali (miserabilmente fallendo con poche migliaia di utenti ancora meglio che con centinaia di migliaia di utenti).

Ovviamente, questo ti costringe a commettere un codice che compila, e meglio passare tutti i test. Questo non è necessariamente un inconveniente: come la pratica ha mostrato in passato, utilizzando build notturne (che possono accadere più frequentemente di una volta al giorno, tra l'altro) come un palpito del progetto e cercando di evitare di portare un progetto in uno stato in cui non compilare per settimane è vantaggioso sia per il progetto che per il team.

Se sembra troppo difficile lavorare in questo modo nel tuo contesto, sceglierei il tuo primo suggerimento: un ramo per feature con un'unione al tronco una volta terminata la funzione, e forse alcuni si uniscono tra il ramo e il tronco in nel frattempo.

Le mensole hanno uno scopo diverso. Sono lì per essere in grado di memorizzare lo stato attuale del progetto al fine di lavorare su cose completamente diverse. Ad esempio, hai implementato una funzione di due ore quando è stato scoperto un bug critico in produzione e dovresti correggerlo adesso . Gli scaffali sono cittadini di seconda classe. Il problema principale è che si integrano male, se non del tutto, con tutti gli strumenti di visualizzazione e data mining per TFS. Se qualcuno vuole conoscere la progressione della squadra sulla base delle informazioni disponibili in TFS, potrebbe non essere in grado di utilizzare scaffali per questo. Allo stesso modo, i commit di due mesi sarebbero troppo grandi per essere utili: come, ad esempio, si diff un commit che ha cambiato metà dei file del code base, dato che molti file non hanno nemmeno l'aspetto delle loro precedenti revisioni ?

Per quanto riguarda My Work, sfortunatamente non sono a conoscenza di questa funzione.

    
risposta data 08.02.2015 - 18:35
fonte

Leggi altre domande sui tag