Come si tira qualcosa da una release?

Subversion sarà il killer per te.

Stavo per dire di inserire ciascuna caratteristica nel suo ramo e unire i rami per produrre il candidato alla release. Quindi, se il cliente decide di estrarre una o più funzionalità, è possibile ricomporle escludendo i rami delle funzionalità rifiutate.

Questo non sarà comunque un esercizio banale con Subversion dato che la sua "ramificazione" non è apparentemente così bella. Potresti passare a Mercurial? O Git?

• Config : puoi disabilitare la funzionalità, renderla non disponibile o nasconderla dal proprietario del prodotto e pianificare nello sprint successivo ciò che verrà effettivamente fatto con questa (correzione completa o completa) . Ciò richiede un po 'di pianificazione, alcuni config e ha un impatto sul modo in cui codificare la funzionalità. Conosciuto anche come funzione switch o attiva / disattiva .

• Isolamento del codice: come molti hanno dichiarato che i rami delle funzionalità saranno utili, e per questo git sarebbe utile, ma è perfettamente fattibile anche in SVN. Fino a voi per decidere quanto lavoro cambierà il VSC e l'impatto sul vostro team. Con funzionalità nel proprio ramo, potrebbe essere più facile estrarre codice indesiderato, ma non è una panacea. A seconda di come è strutturata la tua app, può passare da banale a quasi impossibile anche con i branch delle funzionalità.

• Architettura : se il tuo sistema è costruito attorno a un gruppo di moduli o plugin liberamente accoppiati, rimuovere una funzionalità significa semplicemente non includere una DLL o un JAR (o qualsiasi altra cosa abbia lo stack per questo) . Con questo approccio le caratteristiche sarebbero effettivamente sviluppate come i propri progetti separati (molto probabilmente).

Ancora nulla può davvero sostituire una buona comunicazione con il prodotto / proprietario, e anche con questa situazione è destinato ad accadere ad un certo punto in qualche forma o forma. Dovrai negoziare per trovare il miglior compromesso.

Come gestisci SubVersion / Repositories

Normalmente ciò che faccio per qualcosa di simile è che in realtà ottengo tutti gli sviluppatori di scrivere feature in rami separati e quindi eseguirò un merge to trunk, ma taggalo come pre-release.

Questo mi dà anche la possibilità di rivedere ogni funzionalità per correttezza, se un ramo o una funzione fallisce il mio QA iniziale, allora non lo unisco. Se una funzione viene eliminata dopo essere passata al QA, è quindi banale ripristinare una revisione specifica dal trunk e quindi re-tag e re-test.

Devi davvero programmare in anticipo, a meno che le funzionalità non tocchino mai alcun codice comune.

Se utilizzi rami separati, se più rami necessitano di modifiche nello stesso codice, otterrai una serie di risultati casuali lasciando cadere un particolare ramo.

È molto meglio costruire qualcosa nelle tue esigenze e nel tuo codice, che ti consente di disattivare funzionalità specifiche secondo necessità. A volte ciò richiede di avere il codice per il vecchio e il nuovo comportamento; altre volte avrà solo bisogno di un modo per bloccare un nuovo comportamento.

Se ti stupisci di questo alla fine degli sprint, direi che devi ripensare al modo in cui progetti le tue architetture. Ci sono 2 filosofie che ho incontrato e ti consiglio di dare un'occhiata a: Sviluppo guidato dalle funzionalità e Linee prodotto software .

Con FDD, penserai all'architettura dell'applicazione come a una raccolta di funzionalità. Ogni funzione dovrebbe essere in grado di stare da solo o essere estratta dal progetto se necessario.

Con le linee di prodotti software, la premessa è che realizzerete una serie di prodotti diversi con caratteristiche di alcune in comune e alcune diverse. Ciò comporta un design più avanzato per il refactoring delle cose comuni in librerie di funzioni separate.