Pianificazione della distribuzione per lo sviluppo basato su funzionalità

Question

Un prodotto viene sviluppato e distribuito come funzionalità anziché come rilasci, il che significa che una volta completata una funzionalità, viene inviato allo stage e quindi alla produzione.Possono esserci più funzionalità in fase di sviluppo e sovrapposizioni nella sequenza temporale di consegna.Pertanto, in qualsiasi momento il database di sviluppo e il controllo del codice sorgente hanno più di una funzionalità in fase di sviluppo.Quando una funzionalità è completata, vorrei inviare allo staging solo il codice specifico della funzionalità e le modifiche al database.Questo processo si sta rivelando soggetto a errori e dispendioso in termini di tempo per i motivi:

• Le entità DB di una funzionalità specifica non sono indipendenti, ma dipendenti e intrecciate con altre funzionalità.Pertanto, separare le entità specifiche della funzionalità richiede tempo e talvolta è difficile da ottenere.C'è un modo migliore per farlo?
• Sul codice lato server, separare in modo simile il codice specifico della funzionalità è altrettanto complicato del file db.Con .NET Entity Framework sovrapposto al DB e altre ottimizzazioni delle prestazioni come le visualizzazioni pregenerate, esiste un modo migliore per distribuire lo sviluppo basato su funzionalità?

L'ambiente di sviluppo comprende SQL Server 2008, .NET, Entity Framework con SVN per il controllo del codice sorgente.

Il termine funzionalità qui non è correlato al modello agile FDD.

Qualcuno ha vissuto un'esperienza simile?

Grazie molto!

Answer 1

Gestisco un progetto che funziona in modo molto simile a quello che hai appena descritto.

Ottieni la configurazione di SVN e CruiseControl.NET il prima possibile.È un piacere di vita/tempo

Al momento il mio team lavora fuori dai rami in SVN e si unisce al trunk, quindi tagga quando è pronto per la produzione.

Mantieni il tuo database sotto controllo delle versioni e associa i numeri di versione ai tag (release)

Ho derivato i miei metodi di controllo delle versioni DB basati su questo ottimo articolo ciò suggerisce la creazione di alcune tabelle/vincoli/trigger per aiutare il controllo della versione del tuo DB.

Il controllo delle versioni del database è la parte più difficile.Prima che sviluppassimo una rigorosa routine per la modifica del DB, tutto era un incubo

ovviamente non c'è abbastanza spazio per spiegare tutti i dettagli, ma sono passato dal trascorrere le mie intere giornate a gestire/unire il codice ad ora semplicemente controllare le build automatizzate per stare tranquillo e avere tempo per contribuire al progetto.