Test e progettazione dell'ambiente di distribuzione per piccoli team

Questo è un problema difficile.

Puoi provare a risolvere questo problema utilizzando la funzione di ramificazione: ogni nuova funzionalità viene sviluppata nel proprio ramo indipendentemente dalle altre funzionalità. È quindi possibile avere un ramo "test" in cui tutte queste filiali di funzionalità vengono unite in modo che il cliente possa testare tutte le funzionalità contemporaneamente. Quando la funzione A è pronta, ma B e C non lo sono, puoi creare una build solo da feature pronte, in questo caso A perché è indipendente dalle altre funzionalità.

Quindi questa è teoria, ma in pratica non funziona così bene. Il problema più piccolo è che si usa SVN che supporta la ramificazione, ma lavorare con loro in SVN è una specie di PITA. Alcuni VCS distribuiti sarebbero migliori (Git, Mercurial, ...). Il problema più grande è che le funzionalità spesso non sono indipendenti l'una dall'altra (potrebbero esserci alcune dipendenze tra di loro, diverse funzionalità toccano lo stesso codice ecc.) E non è possibile implementare solo la caratteristica A, specialmente senza test specifici per questa build - anche anche se A ha lavorato sul ramo con tutte le branch feature unite, esso (A) non deve necessariamente funzionare se distribuito in isolamento ...

Altre possibilità sono non tecniche - hanno un ciclo di sviluppo / rilascio - ad es. SCRUM richiede che dopo ogni sprint sia disponibile un prodotto potenzialmente consegnabile. Lavorare anche a stretto contatto con il cliente (proprietario del prodotto) per i test, assicurandosi che comprenda come lavori in modo da potersi allineare al processo di sviluppo per ottenere un guadagno maggiore ...

Come hai anche detto, è improbabile che l'efficienza del team venga migliorata se si dispone solo di un ambiente TEST, in cui tutti gli sviluppatori lavorano. Penso che questo sia il principale collo di bottiglia nel tuo processo di sviluppo.

Ogni sviluppatore dovrebbe avere il proprio ambiente DEV nel proprio computer locale, con un proprio database (forse un clone recente dall'ambiente TEST). Quindi, ogni sviluppatore può lavorare indipendentemente sulla propria funzione. Quando ciascuna funzione ha superato la fase DEV con test locale da parte del team DEV, deve essere confermata nel sistema di controllo della versione che si utilizza e quindi deve essere distribuita nell'ambiente TEST per essere visualizzata dal client.

Negli aspetti del controllo delle versioni, la migliore pratica è che ogni sviluppatore crea un nuovo ramo per ogni nuova funzione e quando la funzione deve essere distribuita in TEST, il ramo viene unito nel tronco. Quindi, tutti i conflitti tra le diverse funzionalità saranno facilmente osservabili e osservando la cronologia delle versioni, le funzioni aggiunte a ogni passaggio saranno facilmente notate, poiché dovrai solo cercare i rami uniti