La scelta di usare un DVCS su un CVCS fa in realtà dei cicli di rilascio più brevi? In tal caso, cosa rende i cicli di rilascio del software più brevi e quali sono gli argomenti per questo?
What makes software release cycle shorter with DVCS, compared to CVCS?
Non penso che ci sia necessariamente una differenza tra DVCS e CVCS qui, ma piuttosto una differenza nel modello di ramificazione a cui le persone aderiscono.
Da quello che ho raccolto qui e dalla mia esperienza, le persone che usano DVCS tendono a utilizzare più filiali rispetto a chi usa CVCS. E se sviluppi ciascuna caratteristica in una branca, è più facile iniziare a preparare una versione con la nuova funzione X, ma non la funzione Y, il cui sviluppo è iniziato ma che non è ancora pronto per un rilascio.
Tutti qui sembrano concordare sul fatto che i progetti che usano DVCS abbiano cicli di rilascio più brevi, ma non è ancora sicuro che l'adozione di un DVCS causi i cicli più brevi: la correlazione non è causalità!
I VCS distribuiti e i cicli di rilascio brevi sono entrambe tecnologie relativamente nuove. I progetti che ne comprendono uno sono in grado di abbracciare l'altro, mentre i gruppi che preferiscono il provato e il vero, o che hanno un flusso di lavoro consolidato da molto tempo, saranno più conservatori e seguiranno CVCS e rilasci meno frequenti.
Una domanda migliore da porsi sarebbe: "In che modo l'uso di un DVCS facilita il modello del ciclo a rilascio breve?" Questo è ciò che la maggior parte delle risposte sta affrontando, in realtà. L'uso di un DVCS non impedisce a nessuno di avere cicli di rilascio lunghi; l'adozione di brevi è una scelta e implica metodologie di sviluppo, modelli di ramificazione, revisioni del codice, ecc .-- non solo VCS.
Buona domanda!
Il CVCS crede nel principio fondamentale che tutto debba continuare a fondersi / sincronizzarsi con il "tronco". Inoltre, ci aspettiamo che man mano che ci evolviamo, il tronco dovrebbe essere il punto più stabile prima della realizzazione. Quindi le persone mettono il loro lavoro in copia di lavoro, aggiornano e testano prima del check-in. In alternativa, puoi lavorare su rami privati / feature e quindi unire le altre modifiche del tronco, testare prima di reintegrarti.
Il pattern DVCS può essere significativamente diverso. Continui a ramificarti e a forgiare te stesso. Potresti sperimentare e infine fondere rami che hanno senso. Di tanto in tanto hai sentito delle correzioni di sicurezza che devono uscire immediatamente, quindi vuoi che quella patch si trovi anche nel tuo ramo, ma non vuoi molte altre cose del bagagliaio! Quindi, per impostazione predefinita, continui a lavorare nel tuo spazio, continui a prendere e integrare le cose - e arriva il momento in cui tutti ti siedono e decidi su cosa prendere.
Vedi questo: link
Quindi la differenza essenziale è questa: CVCS chiede cosa dice la madre ai loro figli piccoli - non andare lontano oltre un punto in cui posso trovarti - continua a sincronizzare con il tronco. Il DVCS funziona presupponendo che tutto il lavoro sia design per essere indipendente a meno che non vi sia la necessità esplicita di unire (ad es. Creare un rilascio).
Ora vieni alla tua domanda -
La spiegazione sopra sembra effettivamente più contraria a ciò che hai osservato / chiesto. La vera sfida è definire ciò che è stabile! quando il numero di utenti è molto grande, e mentre le persone continuano a versare i loro delta - ognuno di essi potrebbe avere una controproducente rispetto ad altri cambiamenti paralleli fino a quando tutti sono sistemati al loro meglio e l'integrazione e le dipendenze sono ok. Quindi, quando stai provando a rilasciare, devi veramente scuotere le cose, impedire alle persone di riversare nuove funzionalità - identificare eventuali problemi di integrazione quando le cose si fondono e così via. Tutto questo, implica che CVCS ti chieda sempre di fare "pause di rilascio" tra lo sviluppo!
Quando il numero di contributori diventa grande, arrivare a questo punto di "pause di rilascio" diventa difficile e meno; e quindi CVCS in realtà ti costringerà a fare dei "festival per la creazione di versioni" dopo uno molto significativo.
In DVCS: continui a lavorare, a testare, a testare il tuo spazio. La creazione e l'integrazione di release è un'attività abbastanza parallela e può anche permettersi di fare tentativi ed errori vedendo quali patch-set funzionano insieme e cosa no (da qui in poi verranno presi o abbandonati dalle versioni). In DVCS è possibile disaccoppiare lo sviluppo individuale e, di tanto in tanto, è sufficiente introdurre un rilascio se ciò ha senso.
What makes software release cycle shorter with DVCS, compared to CVCS?
Sono d'accordo con Bart sul fatto che il motivo principale è il modello di branching usato, ma il tipo di sistema di controllo della versione influenza direttamente quali modelli di branching sono validi. Quindi abbiamo due sotto-domande. Quale modello di ramificazione supporta meglio i sistemi distribuiti e perché rende il ciclo di rilascio più veloce?
La differenza fondamentale tra controllo di versione centralizzato e distribuito è che, senza l'autorità centrale, non è possibile applicare la linea temporale lineare. Quindi, per rendere possibile il controllo della versione distribuita, questi sistemi dovevano necessariamente definire la cronologia come grafico aciclico diretto, dove ogni revisione ha semplicemente un identificatore univoco, una o più revisioni dei genitori e può avere arbitrarie revisioni di molti bambini di cui non si è nemmeno a conoscenza, perché non sei ancora sincronizzato con il sistema in cui sono stati creati.
Si scopre che questo approccio si presta molto bene alla ramificazione. Non devi fare nulla per ottenere un ramo, semplicemente ne hai sempre uno. In questo modo puoi tuffarti direttamente al lavoro per prima cosa e lasciare decidere dove e quando fonderlo o anche dove tenerlo e sotto quale nome fino a quando non sai se sta effettivamente andando come ti serve.
Al contrario, tutti i sistemi centralizzati conservano la storia come insieme di rami con una sequenza lineare di revisioni. Quindi devi decidere in anticipo se hai bisogno di un ramo, dargli un nome e averlo creato esplicitamente. Questo è un bel rompicapo quando non sai ancora cosa vale l'idea e spesso non lo sai prima di iniziare a programmare. Complicato dal fatto che nella maggior parte dei sistemi centralizzati i nomi delle filiali sono globali, significativi, spesso persistenti e non facilmente modificabili, mentre in tutti i principali sistemi distribuiti sono solo moniker locali che possono essere modificati per capriccio e riciclati liberamente. E dal fatto che tutte le operazioni di ramificazione e unione sono di solito un po 'più lente in CVCS.
Quindi DVCS rende le filiali più facili e quindi i team che utilizzano le filiali DVCS per tutto il tempo mentre i team che utilizzano CVCS le eviteranno la maggior parte del tempo.
Ora perché utilizzare le filiali consente rilasci più frequenti? Bene, ogni squadra sottostimerà un compito di tanto in tanto, spesso quando appare difficile trovare un bug. I team che utilizzano sistemi centralizzati di solito eseguono tutto il debug e la maggior parte dello sviluppo, sul trunk, perché i rami sono scomodi. Quindi non possono rilasciare fino a quando non eliminano la maggior parte dei bug e devono interlacciare fasi di sviluppo e debugging.
Al contrario nei sistemi distribuiti in cui tutto il lavoro viene svolto sui rami questi possono essere uniti per test, testati, bug corretti e solo il lavoro che passa i test uniti separatamente al trunk. Risultante nel trunk che ha pochissimi bug e quindi può essere rilasciato più spesso, di solito ogni volta che una caratteristica importante atterra.
Aiuta anche che ogni volta che c'è un cambiamento nelle priorità, i lavori in corso possono essere banalmente accantonati con l'approccio di ramificazione usato con i sistemi distribuiti. Nella maggior parte dei progetti reali, i cambiamenti nelle priorità avvengono continuamente.
Leggi altre domande sui tag release-management dvcs cvcs