Quale controllo del codice sorgente ho bisogno per un grande progetto in un'azienda media? [chiuso]

So che Git è ottimo per progetti open source. Ma mi chiedevo: per un'azienda con 20 programmatori che lavorano su un progetto di 1 anno, quale sistema di controllo del codice sorgente è desiderabile? Da quello che ho sentito Git usa tirare; non sarebbe meno desiderabile dover consultare qualcun altro per ottenere i cambiamenti nel bagagliaio principale? Soprattutto quando tutti lavorano allo stesso tempo?

Questo è solo un esempio di cui mi stavo chiedendo. So come usare SVN ma anche nel mio ultimo lavoro non l'abbiamo usato nei nostri progetti, dato che tutto è stato fatto in PHP e quelli erano in genere progetti indipendenti di 1 settimana. Avevo appena SVN per il mio codice locale e non avevo bisogno di usarlo con gli altri.

Quindi quali sono i buoni controlli del codice sorgente, e in particolare perché è buono per questo?

Usa tutto ciò che la tua squadra è a tuo agio. Tutti i sistemi di controllo versione fanno più o meno la stessa cosa in modi simili; non c'è motivo di reinventare la ruota perché "potrebbe funzionare meglio". Se il tuo team non è a proprio agio con nulla, scegli l'opzione che ha l'integrazione più semplice con l'IDE standard del tuo team.

Mercurial è eccellente, distribuito e gratuito.

Penso che dipenda dal livello di supporto di cui hai bisogno.

Uso git a casa per i miei progetti divertenti quando un problema mi costa tempo, ma posso passare il tempo a imparare ciò di cui ho bisogno per risolverlo.

Al lavoro utilizziamo Perforce perché avere un supporto tecnico 24/7 è indispensabile. Abbiamo persone che lavorano sempre sul codice a New York, Germania, Irlanda e Giappone. Se c'è un problema, dobbiamo ottenere una risposta al più presto. Nella mia esperienza, le persone di Perforce sanno davvero cosa stanno facendo e sono ricettivi ai suggerimenti.

Mentre penso che questa domanda sia ampia e debba essere indirizzata su base per azienda, in base al tuo framework IT e alle strutture di rete / sviluppo, penso che l'aspetto più importante nella scelta del controllo sorgente / versione non sia quale applicazione usi, ma se il suo utilizzo è praticamente strutturato e applicato.

La struttura e l'applicazione dell'utilizzo sono gli aspetti più importanti del controllo delle versioni.

Pianifica in anticipo e coinvolgi tutti. Applicare l'utilizzo. Non solo con i programmatori, ma con tutto ciò che riguarda i progetti (documenti, immagini, ecc.).

SVN è una buona applicazione e può essere integrata con molti componenti aggiuntivi (incluso il tracciamento di bug / attività), non ha bisogno di un server separato ed è gratuita!

Esistono anche altre buone applicazioni di controllo del codice sorgente, come ha affermato @EricBoersma:

Usa tutto ciò che la tua squadra è a tuo agio.

Basta disporre di processi e migliori pratiche e acquistare da quelli che possono applicarlo.

Hai delle idee sbagliate su come funziona git. L'invio di una richiesta pull a un gatekeeper è solo un modo per farlo. Ci sono molti altri modi per configurarlo, incluso praticamente esattamente come svn, che è esattamente quante persone iniziano prima che si sentano abbastanza a loro agio da personalizzare. Con un DVCS come git, hai abbastanza opzioni per strutturare il controllo del codice sorgente sul flusso di lavoro, anziché viceversa.

Pensavo che il controllo del codice sorgente fosse solo uno strumento e che ciascuno dei prodotti facesse più o meno la stessa cosa. E poi il punto di questi sistemi di controllo della versione distribuita è scattato con me.

Il controllo della versione distribuita consente di avere più di un repository centrale. Immagina che le modifiche al codice vengano migrate dal repository degli sviluppatori locale, al repository delle funzionalità, al repository del prodotto, al repository QA e infine al repository rilasciato.

Personalmente utilizzo un prodotto commerciale chiamato Kiln, basato su Hg, ma la funzionalità chiave è il controllo della versione distribuita . Rivoluziona il flusso di nuovo codice dallo sviluppatore a un prodotto rilasciato.

Sai come usare SVN, quindi usa SVN - migra su un DVCS solo se c'è qualcosa che ti serve.

Ciò che è veramente importante è che usi qualcosa che ti piacerà usare, che è facile da usare. Martin Fowler ha fatto un rapido e semplice sondaggio sui VCS, i risultati sono molto interessanti.

Ho impostato git nel mio ultimo lavoro in cui stavamo lavorando a un progetto di dimensioni simili (15 sviluppatori, progetto di 18 mesi) e ha funzionato bene.

Il modo in cui lo abbiamo impostato è stato:

Avevamo un server git che era il nostro server git autorevole centralizzato. I membri del team sono stati scoraggiati dal separarsi direttamente gli uni dagli altri in modo che tutte le modifiche siano andate nel server centrale.

Abbiamo utilizzato il ramo principale come ramo di produzione principale, con tag per ogni versione. Ogni modulo nel progetto era un sottomodulo git. Ogni sottomodulo aveva filiali per ciascun membro del team. A ciascun sottomodulo è stato assegnato un manutentore (di solito l'autore originale), che era responsabile della gestione delle richieste di pull dagli altri membri del team e dell'emissione di richieste di pull al responsabile del team che avrebbe aggiornato il sottomodulo nel ramo principale quando era pronto per essere integrato nel ramo di produzione. Abbiamo usato i tag per identificare i commit che completavano una funzione specifica o che corrispondevano a una versione.

Darei almeno una buona occhiata a Team Foundation System (TFS) di Microsoft. Dai tuoi commenti prendo atto che non sei un negozio Microsoft. Tuttavia, la mia comprensione è che esiste un plug-in Eclipse abbastanza robusto se si utilizza tale IDE per lo sviluppo.

I meccanismi di fusione e ramificazione funzionano bene come tutti gli altri sistemi di controllo del codice sorgente (meglio di svn, secondo la mia esperienza, e altrettanto validi), ma ciò che brilla davvero è il monitoraggio del progetto e gli aspetti di gestione del progetto del prodotto, e l'automazione integrata per build e implementazioni.

Se stai scrivendo un'applicazione basata sul Web, dai un'occhiata al framework di test automatizzato dell'interfaccia utente e al framework di test del carico che puoi creare e configurare in un ordine abbastanza breve. Una caratteristica elegante: simulare i browser mobili integrati nel test di carico.