Codice di scaffalatura in Team Foundation Server (TFS)

Personalmente ho diverse ragioni per accantonare:

• Voglio / devo andare a casa, ma il codice corrente becchierebbe la build quando verrebbe registrato.
• è un backup
• se mi ammalassi, gli altri membri della mia squadra sarebbero in grado di ottenere le mie modifiche e lavorarci sopra
• a volte sto facendo un cambiamento e voglio ricominciare da capo ma non perdere tutto il codice che ho scritto su sofar. Qualcosa potrebbe essere utile
• scambia il codice con un membro del team senza controllare il codice.

Spero che questo aiuti.

Non mi fido del mio disco rigido locale per non andare in crash durante la notte. Scaffalature = backup, per me personalmente.

Sono stato anche in team che usano la funzione shelving per la codifica esplorativa / proof of concept che potrebbe durare diversi giorni. Vediamo come qualcosa potrebbe adattarsi al software senza impegnarsi veramente troppo.

Tra gli altri usi già pubblicati (backup, condivisione, ecc.): lo usiamo per le revisioni del codice.

1. Il codice degli scaffali di sviluppo che desideri registrare
2. Dev crea la revisione del codice con nome shelfet
3. Revisore trasporta il codice in ultime recensioni / recensioni
4. Il revisore approva la revisione del codice
5. Dev il codice degli scali nell'ultima versione
6. Dev check in

Quindi, quando correggo un bug o una funzionalità o qualcosa del genere, lo accolgo e creo una revisione del codice per il mio lead, quindi annullo le modifiche in sospeso su sln e lavoro sull'attività successiva fino a quando la revisione non ritorna. Poi accolgo ciò su cui sto lavorando, tolgo il codice revisionato (cambio di tutto ciò che mi serve a seconda dei commenti del mio lead) e mi registro. Poi spoglio ciò a cui stavo lavorando e continuo.

Una volta che ci sei abituato, è un processo piuttosto piacevole.

Non so gli altri, ma a volte sto lavorando su un grande cambiamento che ha una priorità più bassa e un altro cambiamento è una priorità più alta e quindi accolgo il mio lavoro e faccio tutto il necessario prima. Inoltre, come ha sottolineato Fish, le scaffalature supportano il tuo codice. Niente di peggio che perdere tutto il tuo lavoro soprattutto prima che sia finito.

Il mio team inserisce il codice quando desidera condividere qualcosa con un altro sviluppatore senza dover controllare quel codice (vacanza, prototipo di vetting, creazione di un set di modifiche su più macchine, ecc.)

Ho anche alcuni sviluppatori che lo usano per creare alcuni set di modifiche (in genere indipendenti e di piccole dimensioni) in modo che possano chiedere a una persona di avere più revisioni di codici contemporaneamente.

nel nostro ambiente,

1. Uno sviluppatore prima ottiene l'ultima versione di SLN in TFS prima di apportare qualsiasi modifica.
2. modifica codice o / aggiungi una funzione & shelve cambia il numero di volte necessario durante il giorno.
3. Esegui test dell'unità
4. quando viene effettuato il test dell'unità per le modifiche / o le funzionalità aggiunte entro la fine della giornata, Dev crea uno scaffale finale impostato deselezionando la casella di controllo "mantieni le modifiche in sospeso localmente"
5. Dev invia un'email al capo del team sullo scaffale finale

6. Il team leader esaminerà il codice e, se approvato, applicherà lo shelf Dev e invierà una risposta invia un'email a DEV per verificare le modifiche nell'ambiente di test. se il codice non è approvato, Dev annullerà le modifiche e farà più modifiche per tornare a step4

7. Dev esegue test case nell'ambiente di test e se tutto è in accordo con i risultati desiderati, quindi Dev notifica al coordinatore dell'utente o all'analista aziendale per Progetto pronto per UAT.

8. a questo punto Dev vedrà le sue modifiche in TFS

e ricomincia il ciclo dal Passaggio 1.

è buona norma che lo sviluppatore possa accantonare le modifiche alla fine della giornata come backup. è anche una buona pratica per gli sviluppatori ottenere le ultime modifiche SLN più volte durante il giorno.

la comunicazione è importante tra gli sviluppatori per evitare di lavorare sullo stesso modulo e sovrascrivere ogni altro codice.

Penso che sia un po 'più complesso e sfumato rispetto alle altre risposte date qui, ma anche che c'è una buona discussione su StackOverflow: link

Sì, si tratta di essere in grado di controllare le cose e andare a casa, ma è anche in modo da poter impostare un nuovo lavoro in un punto in cui quel lavoro non è pronto per essere commesso, in modo da poter lavorare su altre cose nella stessa soluzione. L'esempio per questo è dover impostare un nuovo sviluppo per risolvere un bug. Puoi accantonare il nuovo sviluppo, raccogliere la versione rilasciata, risolvere il problema e tornare al tuo nuovo sviluppo.

Ho usato scaffalature nello stesso modo in cui utilizzo la memorizzazione in Git. Devo mettere da parte il mio attuale lavoro per sistemare qualcos'altro prima. Una volta che questa correzione è stata fatta, posso riprendere dove mi trovavo.

Questa correzione potrebbe essere una soluzione critica (dico "potrebbe essere", perché non ho mai dovuto farlo, ma sarebbe una valida ragione). Piuttosto, l'ho fatto principalmente perché ho identificato un refactoring che dovrebbe essere fatto. Non lavorerei mai su entrambi i refactoring e la nuova funzionalità contemporaneamente e li controlleremo nello stesso changeset. Dovrei sempre implementare innanzitutto il refactoring, controllarlo e quindi lavorare sulla funzionalità / funzionalità, quindi controllarlo.

Riguardo a molte altre risposte sull'utilizzo degli scaffali come misura di riserva, non mi preoccuperei. Negli ultimi 20 anni ho posseduto computer, ho avuto un crash del disco rigido solo una volta, e questo perché ho estratto il computer mentre era ancora acceso (e sono comunque riuscito a salvare i dati sostituendo la stampa tavola). Quindi, se questo evento improbabile dovesse accadere davvero, quanto lavoro dovresti ricreare? Se è una quantità significativa, direi che i set di modifiche sono troppo grandi.

Quindi, anche se non c'è nulla di sbagliato nel creare un shelve a scopo di backup, non mi preoccuperei affatto.