Mi dispiace per questo lungo post, ma penso che ne valga la pena.
Ho appena iniziato con un piccolo negozio .NET che funziona in modo un po 'diverso rispetto agli altri posti in cui ho lavorato. A differenza di una qualsiasi delle mie precedenti posizioni, il software qui scritto è destinato a più clienti e non tutti i clienti ottengono l'ultima versione del software allo stesso tempo. In quanto tale, non esiste una "versione di produzione corrente". Quando un cliente ottiene un aggiornamento, ottiene anche tutte le funzionalità aggiunte al software dal loro ultimo aggiornamento, che potrebbe essere molto tempo fa. Il software è altamente configurabile e le funzionalità possono essere attivate e disattivate: i cosiddetti "commutatori di funzionalità". I cicli di rilascio sono molto stretti qui, in effetti non sono in programma: quando una funzionalità è completa, il software viene distribuito al cliente pertinente.
Il team solo l'anno scorso è passato da Visual Source Safe a Team Foundation Server. Il problema è che usano ancora TFS come se fosse VSS e impongono blocchi di Checkout su un singolo ramo di codice. Ogni volta che una correzione di bug viene messa in campo (anche per un singolo cliente), semplicemente costruisce ciò che è in TFS, verifica che il bug sia stato risolto e distribuito al cliente! (Proveniente da uno sfondo di software per dispositivi farmaceutici e medicali è incredibile!). Il risultato è che il codice dev half-cotto viene messo in produzione senza essere nemmeno testato. I bug stanno sempre scivolando nelle build di rilascio, ma spesso un cliente che ha appena ottenuto una build non vedrà questi bug se non usano la funzionalità in cui si trova l'errore. Il regista sa che questo è un problema dato che la società sta iniziando a crescere all'improvviso con alcuni grandi clienti a bordo e altri più piccoli.
Mi è stato chiesto di esaminare le opzioni di controllo del codice sorgente al fine di eliminare la distribuzione di codici bacati o non terminati, ma di non sacrificare la natura un po 'asincrona delle versioni dei team. Ho usato VSS, TFS, SVN e Bazaar nella mia carriera, ma TFS è dove la maggior parte della mia esperienza è stata.
In precedenza la maggior parte dei team con cui ho lavorato utilizza una soluzione a due o tre rami di Dev-Test-Prod, dove per un mese gli sviluppatori lavorano direttamente in Dev e quindi le modifiche vengono unite a Test e poi a Prod, o promosse "al termine". piuttosto che su un ciclo fisso. Sono state utilizzate build automatiche, utilizzando Cruise Control o Team Build. Nel mio precedente lavoro, Bazaar è stato utilizzato in vetta a SVN: gli sviluppatori hanno lavorato nelle proprie filiali di funzionalità, quindi hanno trasferito le loro modifiche a SVN (che era collegato a TeamCity). Questo è stato bello in quanto è stato facile isolare i cambiamenti e condividerli con altre branche della gente.
Con entrambi questi modelli c'era un ramo centrale di sviluppo e di prova (e talvolta di prova) attraverso il quale il codice veniva spinto (e le etichette venivano usate per contrassegnare le build nei prodotti da cui venivano rilasciati i rilasci ... e questi venivano trasformati in rami per correzioni di bug alle versioni e uniti nuovamente a dev). Questo però non si addice perfettamente al modo di lavorare qui: non c'è un ordine in cui verranno rilasciate varie funzionalità, che vengono spinte quando sono complete.
Con questo requisito l'approccio di "integrazione continua" quando lo vedo si rompe. Per ottenere una nuova funzionalità con l'integrazione continua deve essere spinto tramite dev-test-prod e questo catturerà qualsiasi lavoro incompleto in dev.
Sto pensando che per superare questo problema dovremmo andare su un modello ramificato pesantemente con NO rami di sviluppo-test, piuttosto la sorgente dovrebbe esistere come una serie di feature branch che quando il lavoro di sviluppo è completo sono bloccati, testati, risolto, bloccato, testato e quindi rilasciato. Altre ramificazioni di feature possono prendere modifiche da altri rami quando hanno bisogno / vogliono, quindi alla fine tutte le modifiche vengono assorbite da tutti gli altri. Questo si adatta molto a un modello di Bazaar puro da quello che ho sperimentato nel mio ultimo lavoro.
Per quanto flessibile come sembra, sembra strano avere un ramo di sviluppo o un ramo di produzione da qualche parte, e sono preoccupato che i rami non si reinseriscano mai, o piccoli cambiamenti tardivi fatti che non vengono mai trascinati in altri rami e gli sviluppatori si lamentano di unire i disastri ...
Quali sono i pensieri delle persone su questo?
Una seconda domanda finale: sono un po 'confuso circa la definizione esatta del controllo del source distribuito: alcune persone suggeriscono che si tratta semplicemente di non avere un repository centrale come TFS o SVN, alcuni dicono che si tratta di essere disconnessi (SVN è Il 90% è disconnesso e TFS ha una modalità offline perfettamente funzionante) e altri dicono che si tratta di Feature Branching e facilità di fusione tra filiali senza relazione genitore-figlio (TFS ha anche una fusione senza fondamento!). Forse questa è una seconda domanda!