Distributed Version Control Systems e Enterprise: un buon mix?

Posso capire perché i sistemi di controllo dei sorgenti distribuiti (DVCS – come Mercurial) hanno senso per i progetti open source.

Ma hanno senso per un’impresa? (su un sistema di controllo del codice sorgente centralizzato come TFS)

Quali caratteristiche di un DVCS lo rendono migliore o peggiore adatto per un’azienda con molti sviluppatori? (su un sistema centralizzato)

Ho appena introdotto un DVCS (Git in questo caso) in una grande società bancaria, dove Perforce, SVN o ClearCase erano il VCS centralizzato delle scelte:
Conoscevo già le sfide (vedi la mia precedente risposta ” Possiamo finalmente passare a DVCS in Corporate Software? SVN è ancora un” must “per lo sviluppo? “)

Sono stato sfidato su tre fronti:

  • centralizzazione : mentre il modello decentralizzato ha i suoi meriti (e consente committenze private o lavoro senza la rete pur avendo accesso alla cronologia completa ), ci deve essere ancora un insieme chiaro di repository centralizzati , che fungono da riferimento principale per tutti gli sviluppatori.

  • autenticazione : un DVCS ti permette di “firmare” (commit) il tuo codice come … praticamente chiunque (autore ” foo “, email ” foo@bar.com “).
    Puoi fare un git config user.name foo , o git config user.name whateverNameIFeelToHave , e avere tutti i tuoi commit con il nome falso in esso.
    Ciò non si sposa bene con l’esclusivo referente utente centralizzato “Active Directory” utilizzato dalle grandi aziende.

  • authorization : per impostazione predefinita, è ansible clonare, inviare o estrarre qualsiasi repository e modificare qualsiasi ramo o qualsiasi directory.
    Per i progetti sensibili, questo può essere un problema di blocco (il mondo bancario di solito è molto protettivo su alcuni algoritmi di pricing o quants, che richiedono un severo accesso in lettura / scrittura per un numero molto limitato di persone)

La risposta (per una configurazione Git) era:

  • centralizzazione : è stato creato un server unico per tutti gli archivi che devono essere accessibili da tutti gli utenti.
    Il backup si è occupato di (incrementale ogni giorno, completo ogni settimana).
    DRP (Disaster Recovery Plan) è stato implementato, con un secondo server su un altro sito e con la replica dei dati in tempo reale tramite SRDF .
    Questa configurazione in sé è indipendente dal tipo di referenziale o strumento necessario (DVCS, Nexus repo o programma di pianificazione Hudson principale o …): qualsiasi strumento che può essere critico per un rilascio in produzione deve essere installato sui server con backup e DR.

.

  • autenticazione : solo due protocolli consentono agli utenti di accedere ai repository principali:
    • basato su ssh, con chiave pubblica / privata:
      • utile per gli utenti esterni all’organizzazione (come lo sviluppo off-shore),
      • e utile per gli account generici che il gestore di Active Directory non vuole creare (perché sarebbe un account “anonimo”): una persona reale deve essere responsabile di quell’account generico, e quello sarebbe quello che possiede la chiave privata
    • basato su https, con un Apache che autentica gli utenti attraverso un’impostazione LDAP: in questo modo, deve essere fornito un login effettivo per ogni operazione git su quei repository.
      Git lo offre con il suo protocollo HTTP intelligente , che consente non solo di pull (leggere) tramite http, ma anche di push (scrivere) tramite http.

La parte di autenticazione è anche rinforzata a livello Git da un hook di post-receive che garantisce che almeno uno dei commit che si sta spingendo su un repository ha un “nome di committer” uguale al nome utente rilevato tramite shh o protocollo http.
In altre parole, è necessario git config user.name correttamente git config user.name , o qualsiasi push che si vuole fare su un repository centrale verrà rifiutato.

.

  • authorization : entrambe le impostazioni precedenti (ssh o https) sono cablate per chiamare lo stesso set di script perl, denominato gitolite , con i seguenti parametri:
    • il nome utente effettivo rilevato da questi due protocolli
    • il comando git (clone, push o pull) che l’utente vuole fare

Lo script perl gitolite analizzerà un semplice file di testo in cui sono state impostate le autorizzazioni (accesso in lettura / scrittura per un intero repository o per rami all’interno di un determinato repository o anche per le directory all’interno di un repository).
Se il livello di accesso richiesto dal comando git non corrisponde all’ACL definito in quel file, il comando viene respinto.


Quanto sopra descrive ciò che dovevo implementare per un’impostazione Git, ma, cosa più importante, elenca i principali problemi che devono essere affrontati per un’impostazione DVCS che abbia senso in una grande azienda con una base di utenti unica.

Quindi, e solo allora, un DVCS (Git, Mercurial, …) può aggiungere valori a causa di:

  • scambio di dati tra più siti : mentre quegli utenti sono tutti autenticati tramite la stessa Active Directory, possono essere localizzati in tutto il mondo (le società per le quali ho lavorato hanno solitamente sviluppi tra team di due o tre paesi). Un DVCS è fatto naturalmente per lo scambio efficiente di dati tra i team distribuiti.

  • replica negli ambienti : un’impostazione che si occupa di autenticazione / authorization consente di clonare tali repository su altri server dedicati (per test di integrazione, test UAT, pre-produzione e pre-distribuzione)

  • automazione dei processi : la facilità con cui è ansible clonare un repository può anche essere utilizzata localmente sulla workstation di un utente, per scopi di testing unitario con le tecniche di “guarded commits” e altri usi intelligenti: vedere ” Qual è l’uso più intelligente del repository di origine che hai mai visto? “.
    In breve, puoi inviare a un secondo repository locale incaricato di:

    • vari compiti (unit test o analisi statica del codice)
    • respingendo al repository principale se tali attività hanno esito positivo
    • mentre si sta ancora lavorando nel primo repository senza dover attendere il risultato di tali attività.

.

  • caratteristiche killer : qualsiasi DVCS viene fornito con quelli, il principale è la fusione (mai provato a fare un complesso stream di lavoro con SVN? O fondere sloooow 6000 file con ClearCase?).
    Solo questo (unione) significa che puoi davvero trarre vantaggio dalla ramificazione , pur essendo in grado in ogni momento di unire il tuo codice ad un’altra linea di sviluppo “principale”, perché lo faresti:
    • prima a livello locale all’interno del proprio repository, senza disturbare nessuno
    • quindi sul server remoto, premendo il risultato di tale unione sul repository centrale.

Per aggiungere agli altri commenti, osserverei che non c’è motivo per cui non si possa avere un archivio centrale aziendale . Tecnicamente è solo un altro repository, ma è quello da cui spedisci la produzione. Ho usato un modulo o un altro di VCS da oltre 30 anni e posso dire che passare a Mercurial è stato come un ragazzo di città che respirava aria di campagna pulita per la prima volta.

DSCS ha una storia migliore (in generale) di sistemi centralizzati per reti offline o lente. Tendono ad essere più veloci, il che è davvero notevole per gli sviluppatori (usando TDD) che fanno molti check-in.

I sistemi centralizzati sono in qualche modo più facili da afferrare inizialmente e potrebbero essere una scelta migliore per gli sviluppatori meno esperti. DVCSes ti consente di creare molti mini-rami e isolare nuove funzionalità mentre eseguo ancora il refripping rosso-gree sullo stile di codifica verde. Ancora una volta questo è molto potente ma attraente solo per team di sviluppo abbastanza esperti.

Avere un singolo repository centrale per il supporto per i blocchi esclusivi ha senso se si gestiscono file che non sono unibili come risorse digitali e documenti non di testo (PDF e Word ecc.) In quanto impedisce di entrare in un disastro e di fondersi manualmente.

Non penso che il numero di sviluppatori o di dimensioni della base di codice ci giochi così tanto, entrambi i sistemi sono stati mostrati per supportare grandi alberi di sorgenti e numeri di committer. Tuttavia, per basi di codice e progetti di grandi dimensioni, DVCS offre molta flessibilità nella creazione rapida di filiali remote decentralizzate. Puoi farlo con i sistemi centralizzati, ma devi essere più deliberato su ciò che è sia buono sia cattivo.

In breve, ci sono alcuni aspetti tecnici da considerare, ma dovresti anche pensare alla maturità della tua squadra e al loro attuale processo intorno a SCCS.

Almeno con tfs 2013 hai la possibilità di lavorare disconnesso con aree di lavoro locali. Distributed vs centralized è definito dal business e dipende dai bisogni e dai requisiti dei progetti in fase di sviluppo.

Per i progetti aziendali, la capacità di colbind il stream di lavoro e i documenti alle modifiche del codice può essere fondamentale per colbind requisiti aziendali e elementi di ordine superiore a specifiche modifiche del codice che indirizzano una modifica specifica, un bug o un’aggiunta di funzionalità.

Questa connessione tra workflow e repository di codice separa TFS dalle sole soluzioni di repository di codice. Per alcuni luoghi in cui è richiesto un ordine superiore di controllo del progetto, solo un prodotto come TFS soddisfa più requisiti di verifica del progetto.

Una panoramica del processo di gestione del ciclo di vita delle applicazioni può essere trovata qui.

http://msdn.microsoft.com/en-us/library/vstudio/fda2bad5(v=vs.110).aspx

Il problema più grande che dobbiamo affrontare con Git nelle impostazioni aziendali è la mancanza di controllo di accesso in lettura basato sul percorso. È inerente all’architettura di Git (e assumerei la maggior parte dei DVCS) che se si ottiene l’accesso in lettura al repository si ottiene il tutto. Ma a volte un progetto richiederebbe una verifica sparsa (ovvero si desidera che i dati sensibili di controllo della versione siano vicini all’origine o si desideri fornire a una terza parte una vista selettiva di parte del progetto).

Git non fornisce alcun permesso: hai dei ganci per scrivere i tuoi.

La maggior parte dei gestori di repository popolari GithubEnterprise, Gitlab, Bitbucket offre restrizioni di scrittura basate su branch. La gitolite consente di ottenere una grana più fine, fornendo restrizioni di scrittura basate sul percorso (e più).

L’unico gestore di repository che ho sentito di supportare l’accesso in lettura è la Perforce Helix, che reimplementa il protocollo git in cima al backend perforato, ma non ho esperienza pratica con esso. È promettente, ma sarei preoccupato di quanto sia compatibile con il “semplice” git.

Per me la cosa più grande che offrono è la velocità. Sono ordini di grandezza più veloci per le operazioni più comuni rispetto al controllo della sorgente centralizzato.

Lavorare disconnesso è anche un enorme vantaggio.

Assolutamente un modello di fonte distribuita può avere senso in un’azienda, ma dipende dalla struttura dei tuoi team.

Il controllo del codice sorgente distribuito ti offre la flessibilità per creare i tuoi flussi di lavoro.

Immagina, se vuoi, un team più grande, all’interno del quale ci sono team più piccoli che lavorano su branch di feature separati.

  • Questi team possono avere tutti i propri repository centrali, con i propri meccanismi di controllo automatico dell’automazione / controllo delle build.
  • Possono lavorare ovunque e fare il backup del loro lavoro locale ogni volta che lo desiderano.
  • Possono quindi scegliere i checkin che vorrebbero condividere tra i gruppi.
  • Possono avere un singolo integratore individuale, lavorando sulla propria macchina, eseguendo la fusione, senza influenzare gli altri.

Queste sono cose che potreste ottenere con un server centralizzato tradizionale, ma come sottolinea @Brook, il modello centralizzato deve essere scalato, mentre il modello distribuito è già tagliato, quindi non è necessario (o almeno meno) scalare verticalmente alcun server.

Il nostro team ha utilizzato TFS per circa 3 anni prima di passare a Mercurial. Il supporto per ramo / unione di HG è molto meglio di TFS. Questo perché un DVCS si basa sulla fusione indolore.

Migliore sincronizzazione tra posizioni remote / disconnesse.