Implementazione basata su feature con ambienti multipli

Se ti trovi di fronte a un tale problema in un ambiente del genere, sconsiglio di perseguire una granularità così piccola.

1. Quando hai abbandonato il controllo qualità, una nuova versione con cinque funzioni è stata creata per un motivo. Gli uomini d'affari vogliono che vengano consegnati insieme, l'implementazione sia strettamente accoppiata, ecc. E questi motivi non sono influenzati dal fatto che il sottoinsieme delle funzionalità di rilascio non è pronto. Cioè di solito non c'è bisogno di consegnare sottoinsieme del rilascio.
2. Questa pratica incoraggia l'accumulo di elementi non finiti lungo tutta la catena invece della concentrazione alla consegna. Invece di rendere visibile il collo di bottiglia crea una falsa spinta a migliorare tutto.
3. In genere l'accesso a una funzione non è sufficiente, è necessario firmare l'intera applicazione per passare alla fase successiva ed eseguire anche la configurazione di questa fase. Feature-by-feautre moltiplicherà questi sforzi.
4. Per mitigare la necessità occasionale di posticipare particolari funzionalità fastidiose, inserisci in primo piano i cavicchi.

Che cosa potresti fare

1. Prova le versioni di varie dimensioni per vedere cosa offre il massimo throughput.
2. Riorganizzare le priorità dall'aggiunta di funzionalità alle funzionalità di pubblicazione.
3. Riguardo al 'ramo singolo' potresti voler avere la stessa catena di rami degli ambienti. L'unione da QA a INT non è consentita finché il QA non supera tutti i criteri per essere pronto per INT e non implica l'unione immediata da DEV a QA se DEV non è pronto.

Non hai spiegato quanti rami hai attualmente in TFS. Non sono sicuro del processo corrente che segui per la versione. Perdonami, ripeto lo stesso di seguito.

Quello che penso che tu possa fare è avere quattro rami DEV, QA, INT e PROD. Il ramo QA dovrebbe essere l'ultima linea di garanzia della qualità del lavoro completato dev.

Una funzionalità può avere più checkin per lo sviluppo nel ramo DEV ma dovrebbe unirsi tutti insieme e creare un changeset una volta uniti al ramo QA. Ci possono essere ulteriori modifiche da DEV a QA per la stessa funzionalità se i bug sono corretti o se vengono richieste modifiche. In breve il ramo QA dovrebbe avere il codice dev completato e testato e pronto per il rilascio.

Quando le funzionalità devono essere rilasciate, tutti i changeset di quella funzione dal ramo QA devono essere uniti come un singolo changset al ramo INT. Dopo essere stato convalidato correttamente nell'ambiente INT, dovrebbe essere unito al ramo PROD e distribuito nell'ambiente PROD da lì. Presumo qui che il tuo ambiente INT sia il luogo in cui una volta implementata la funzione, resta lì per un po 'a controllare la stabilità di essa prima che vada a prod.

L'unione principale da un ramo all'altro è l'idea principale qui.  È inoltre necessario disporre di script di compilazione separati per ciascun ambiente.

Anche gli script di compilazione dovrebbero essere configurati per prendere il codice dal rispettivo ramo.

Se non hai filiali in VCS, sarà molto difficile ottenere ciò che desideri e sarà più un lavoro manuale che automatizzato.

Non puoi promuovere selettivamente il codice per le singole funzioni a meno che non tieni quel codice su rami separati.

Sono d'accordo sul fatto che i rami delle caratteristiche siano meglio evitati. Se si esegue il test del codice su rami di funzionalità separati, non si saprà che il codice viene eseguito correttamente quando si uniscono e il refactoring diventa molto difficile quando più rami coesistono perché il codice refactored in un ramo potrebbe non funzionare con il codice non refactored in un altro ramo .

Non hai detto perché è necessario mantenere il codice per alcune funzioni lontano da determinati ambienti. Piuttosto che tenere il codice lontano, proverei a utilizzare le opzioni di configurazione per attivare o disattivare le funzionalità come richiesto in ogni ambiente.

Vorrei anche provare a eseguire test automatizzati completi per qualsiasi funzione prima che sia approvata. Ciò dovrebbe dare la certezza che non verrà interrotto in modo silenzioso dal codice dalle funzionalità da distribuire in futuro.