Ciao Gian Maria,
commento qui
il tuo post perche' dai commenti il sito mi risponde con un bel 500 !
ti condivido queste riflessioni sul argomento che ho approfondito recentemente.
Per chi e' interessato ci sono due capitoli sul tema nel libro
Continuous Delivery di Addison Wesley (sul Cap.3 e Cap.14).
I DVCS come Git (o BitKeeper, Mercurial o Baazar, e altri ancora) nascono e sono preferibili ai tradizionali VCS nei casi di team di sviluppo
distribuiti remoti, ancora di piu se in time-zone differenti (per cui puo succedere che il team che ha il controllo del repository o quello da cui viene un check-in che sta creando un problema puo essere offline quando serve).
Ecco
i 2 aspetti chiave dei DVCS per team distribuiti remoti:
- in caso di temporanei problemi di linea/connessione ogni team (ognuno) puo continuare a lavorare in locale perche' dispone in locale tutto il repository con tutta la storia
- e' piu facile gestire i casi di problemi (es. build rotta, merge con errori, etc.) causati da check-in remoti da team (dev) che ora non sono immediatamente raggiungibili, ad esempio lavorando sul proprio repo locale fino a quando il problema e' risolto o aggiungendo dei contolli prima di fare il merge da team/dev remoti che sono offline (come ad es. le pull-requests in bitbucket e github).
Il terzo aspetto chiave e' per progetti open-source:
- abilita la formazione spontanea di team perche' chiunque ha un interesse a fixare un bug o aggiungere una feature puo fare un fork, implementare la cosa e poi mandare la pull-request con il lavoro fatto. Niente a che vedere con il laborioso invio di patch via mail che si usava una volta.
Sul Branching e il Merging
E' facile fraintendere l'utilita dei DVCS all'inizio, il punto di forza sembra in branching e il merging evoluto che in realta' serve per gestire meglio il pull dei commit dai vari repository distribuiti remotamente.
Creare branch ad eccezzione di casi rari e per tempi molto brevi resta un antipattern, causato da cattiva modularita' della code-base o da una carenza di buone pratiche di sviluppo. In quei casi usare i branch va nella direzione contraria della Continuous Integration che e' considerata una pratica moderna necessaria per lavorare in modo professionale, in team Agili e non.
I Dev e i responsabili di Change Management che fanno questo errore sono gli stessi che abusano dei branch anche nei normali VCS quindi non considererei questo un punto a favore dei DVCS o dei VCS.
Alcuni patiti di git preferiscono la linea di comando e anche per questo all'inizio puo sembrare piu complicato di quanto in realta' e', esistono GUI anche per i DVCS che gli rendono molto piu semplici da usare nella stragrande maggioranza delle situazioni.
Nel post
confronti TFVC con i DVCS/Git. Aggiungo questi punti alla tua lista :
- DVCS/Git supporta scenari di team distribuiti meglio di VCS/TFVC
- Con DVCS/Git ogniuno ha la storia completa del repo in locale. In alcuni casi queste possono essere info sensibili, in altre alcune aziende tradizionali hanno la filosofia di limitare l'accesso alle informazioni e questo potrebbe essere un problema e in questi casi VCS/TFVC sono preferibili. Per aziende piu moderne che ritengono sia un valore dare accesso ai dipendenti alle info, questo e' un vantaggio supportato dai DVCS/Git.
- DVCS/Git permette di abusare dell'uso distribuito dei branch&merge (tipo fare il merge in locale tra 2 dev prima di fare il push al repo principale) e della possiblita' di cambiare la storia in locale (es. riordinare i commit locali o cambiare il commento del commit locale) e questo non e' possiblice coi VCS/TFVC. Quindi aziende che sono piu inclini al controllo, VCS/TFVC non permette queste cose e per questo potrebbe essere preferibile.
- Il Plugin TFVC per VS e' integrato a VS e questa e' una caratteristica distintiva primaria di TFS (anche se esistono altri modi di accedere a TFS e TFVC senza plugin ne VS).
Di conseguenza ci sono dipendenze di compatibilita' tra versioni di TFVS plugin e Visual Studio e TFS e .NET Framework (vedi ad es. la Compatibility Support Matrix qui). Cambiarne la versione di uno puo richiedere di aggiornare a domino le versioni anche degli altri componenti (un esempio qui), in alcuni casi richiedendo per un certo tempo lo stop della linea di produzione.
In alcune realta aziendali serve poter fare modifiche graduali e incrementali al ambiente di sviluppo senza interrompere lo sviluppo, per quelle aziende TFVC con plugin non e' adatto.
- TFVC e' molto simile a Perforce in fatto di funzionalita e supporto dei tool, il secondo ha scalabilita e prestazioni superiori adatte anche a organizzazioni molto grandi