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:
- 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.
- 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.
- 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.