Perché le grandi compagnie finanziarie / assicurative dovrebbero usare git e / o github

Lavoro per una grande impresa (30.000 dipendenti) nel settore finanziario / assicurativo. Mentre "IT" non è il nostro obiettivo principale, siamo onesti, si tratta di industrie guidate dall'informazione e le aziende con il miglior vantaggio tecnologico sembrano avanzare più velocemente.

Ci sono molti team di sviluppo software nella mia azienda. Sono su tutta la mappa con controllo della versione, per non parlare delle lingue / dei framework utilizzati. Alcuni non usano alcun (lo so), alcuni usano PVCS, altri usano VSS e i più illuminati usano SVN.

Voglio portare git alla mia impresa. Più specificamente, voglio portare GitHub (repository privati). Conosco le persone giuste con cui parlare di questo, ma siamo onesti di nuovo, mosse drastiche come questa di solito vengono abbattute nel contesto della grande impresa a causa di vaghi problemi di sicurezza o del fatto che nessuno dei nostri concorrenti lo sta usando (e posso cita solo jQuery, Ruby on Rails, Facebook, ecc. come riferimenti).

Quindi la mia domanda è questa. Quali sono i motivi più convincenti del perché una grande impresa dovrebbe passare lentamente e deliberatamente da PVCS / VSS / SVN a una soluzione git ospitata come GitHub (repository privato). Naturalmente, parte del mio piano prevede un POC per un progetto di sviluppo non essenziale.

Ci sono alcune cose di cui potrei preoccuparmi, come terza parte disinteressata. Quindi lascia che ti faccia alcune domande a cui faresti meglio a essere pronto a rispondere (al tuo dipartimento IT):

• Qualsiasi controllo di versione è migliore di nessuno. Abbiamo molto da scegliere, cosa c'è di sbagliato in quelli?
• Controllo della versione distribuita? Cos'è quello? Come lo controlliamo ?
• Quanto costa? Non solo software, ma server, licenze, manutenzione, ecc.
• Non mi fido di GitHub o di alcun hosting in outsourcing. Dobbiamo fare tutto internamente. Perché non possiamo configurare il nostro server?
• Possiamo eseguirlo su Windows? Dobbiamo mantenerlo sulla nostra attuale linea di base, lo sai.
• Come garantiamo la cosa? SVN abbiamo capito, ma questo mi spaventa.

Queste sono le prime domande che verranno poste. Per quanto riguarda VSS e PVCS, probabilmente puoi trovare una serie di argomenti ragionevolmente buoni (come la cronologia delle versioni corrotte di VSS). SVN sarà un po 'più difficile. Consiglio vivamente di concentrarsi sulle funzionalità di unione di GIT e di tenere una mente aperta su Mercurial. Ogni argomento per GIT è anche un argomento per Mercurial - e Mercurial ha un supporto Windows più maturo.

La sicurezza è di fondamentale importanza per le istituzioni finanziarie e governative. Saranno estremamente resistenti alle risorse ospitate esternamente. Dal punto di vista della gestione dei rischi, considera cosa potrebbe accadere se qualcuno avesse violato GitHub e rubato il codice sorgente o scoperto la vulnerabilità della sicurezza documentata nel tracker dei problemi. Sarebbe devastante per l'azienda. Da una prospettiva puramente gestionale, se la società è legalmenteobbligato a pagarti ogni ora di lavoro, come possono monitorare se lavori da casa quando le risorse sono al di fuori della loro rete VPN? In un'altra nota, come possono impedirti di eseguire uno spionaggio aziendale quando tutte le risorse sono disponibili al di fuori dell'azienda? Questi sono gli argomenti IT e di gestione contro l'outsourcing dell'hosting. Una grande azienda deve guardare le cose in questo modo. Per una piccola azienda, dai un'occhiata alla linea di fondo e quanto costerebbe mettere in piedi tutti quei servizi.

In realtà è più economico per la grande azienda farlo in casa. Hanno già le risorse IT, devono solo mescolare un po 'le responsabilità. E se la soluzione si occupa in gran parte di sé con solo la manutenzione periodica necessaria (backup e gestione degli utenti), motivo in più per tenerlo nelle porte aziendali.

Per quanto riguarda l'hosting Windows, si tratta di un'organizzazione per problema organizzativo. Diverse aziende hanno ingoiato il koolaid di Windows. Altri hanno ingoiato il koolaid di Linux. Altri lo considerano caso per caso. Dovrai rispettare le regole stabilite dal dipartimento IT per la tua organizzazione. Finché la tua soluzione può essere ospitata su entrambi, sei d'oro.

Infine, in un'organizzazione così grande ci sono sicuramente feudi che vogliono fare le cose a modo loro. Tutti hanno argomenti convincenti sul perché hanno scelto VSS, PVCS, SVN o cosa hai. Per l'IT sono tutti uguali. L'unico modo per consolidare all'interno di un'organizzazione così grande è far arrivare l'ordine dall'alto. Tali ordini sono sempre incontrati con resistenza, e probabilmente non è qualcosa che la tua azienda vuole fare a meno che non ci siano evidenti benefici del TCO (Total Cost of Ownership) nell'avere un sistema di controllo della versione standardizzato.

Lavoro anche in un'impresa finanziaria / assicurativa (anche se non grande come quella per cui lavori attualmente). Disponiamo inoltre di più team di sviluppo e, sebbene l'impresa abbia scelto specificamente i prodotti Microsoft per lo sviluppo, non esiste ancora architettura master, controllo del linguaggio o del codice sorgente. Stiamo tutti usando .Net, ma abbiamo più progetti in diverse versioni del framework e in diverse lingue. Alcuni progetti utilizzano VSS altri TFS. Ora abbiamo un nuovo architetto di livello superiore come responsabile del controllo qualità e ha guidato una transizione più aziendale dal nostro tracciamento dei bug hodge-podge, controllo del codice sorgente, utilizzo del framework a un'implementazione più universale di TFS per tutto questo. Ciò è reso possibile solo dal fatto che è a) estremamente esperto nella natura del software,

Nell'affrontare questo problema all'interno della propria organizzazione, è necessario considerare prima alcune cose:

1. Perché sei così innamorato di GitHub come risposta? Stai cercando un controllo del codice sorgente comune o stai cercando un motivo per implementare qualcosa con cui ti senti a tuo agio? Non conosco la risposta (e sinceramente non mi interessa), ma questa è una domanda che sorgerà quando inizierai a fare il giro degli affari degli altri.
2. Attualmente sei affiliato con uno di questi team di software? In caso affermativo, potrebbe essere necessario trovare un individuo non affiliato e ben posizionato per sostenere il concetto. Altrimenti, altri team di sviluppo potrebbero pensare che stai tentando di imprimere il tuo pensiero su di essi. Ciò li renderà ancora più resistenti al concetto poiché hanno già qualcosa che funziona (secondo loro).
3. Hai fatto ricorso a individui di altre squadre per ottenere il consenso al concetto? Altri sviluppatori hanno opinioni o preoccupazioni simili? Un'altra strada per ottenerlo è costruire una massa critica che segue tra le persone che svolgono il lavoro. Man mano che sempre più persone iniziano a richiedere repository di fonti comuni, la direzione dovrà prenderne atto.
4. Conosci abbastanza bene il codice / i processi / i requisiti degli altri team abbastanza da dire che GitHub funzionerà (o non funzionerà) per loro?

Per quanto riguarda la tua domanda finale (o effettiva?), L'unica vera ragione convincente a lungo termine dal punto di vista dei manager aziendali è che consente di risparmiare denaro. Questi risparmi potrebbero essere sotto forma di tempi di inattività ridotti, maggiore sicurezza del codice, aumento della produttività degli sviluppatori, maggiore ridondanza della base di codice (per il backup), ecc., Ecc. Ciò che alla fine dovrai fare è convincere le persone che scrivono assegni per tutto ciò che il tempo, lo sforzo e il denaro spesi per passare a un tale modello varranno la pena alla fine come un ritorno sul loro investimento. Dovrai anche dimostrare che il supporto futuro per quello stesso modello sarà lì quando "lentamente e deliberatamente" finalmente avverrà.

C'è un sacco di cambiamenti nella dottrina di una tale impresa, quindi ci vorrà molto entusiasmo di base e avrai sicuramente bisogno di qualcuno a livello di vicepresidente per sostenere il concetto. Un manager potrebbe funzionare, ma un dirigente avrà molta più autorità per imprimere concetti su altri gruppi.

Tali società vorranno centralizzare i propri repository. SVN, VSS e PVCS hanno una cosa in comune: sono tutti architettura client-server. Git è progettato come VCS distribuito e per sua natura è decentralizzato.

GitHub - ancora più problematico. È un servizio esterno. Il codice sorgente nel servizio esterno è qualcosa che molto probabilmente la direzione non accetterà mai.

Esiste tuttavia una soluzione che potrebbe soddisfare entrambe le parti. Git ha il git-svncomando. Fondamentalmente avresti un repository SVN, ma alcuni sviluppatori potrebbero scegliere di avere il proprio repository GIT locale e sincronizzarlo con il repository SVN centralizzato. Buona alternativa alle filiali private o all'invio di patch non impegnate. Buona guida per l'integrazione git-svn .

Molte di queste risposte sono notevolmente obsolete per quanto riguarda i commenti su GitHub e la sicurezza a causa delle modifiche apportate a GitHub da quando sono state pubblicate.

• GitHub non ti obbliga ad essere ospitato esternamente
• La versione GRATUITA di GitHub è ciò che mette in atto questa limitazione.
• Esiste una versione Enterprise di GitHub disponibile per l'hosting interno . https://enterprise.github.com/home . Non è gratuito e costa $ ovviamente

La società in cui lavoro ha appena iniziato a utilizzarlo e abbiamo avuto le stesse ESATTE preoccupazioni perché il nostro codice è un segreto commerciale, siamo nel settore finanziario. A parte questo ci sono altri modi per usare GIT che non coinvolgono GitHub simili, redmine, gitosi, ecc ...

Per quanto riguarda la domanda "chi lo sta usando": PayPal, Etsy, rackspace, vimeo, SAP, JPL della NASA , kernel Linux

Motivi tecnici convincenti sono troppi da elencare. L'unica cosa su cui vale la pena concentrarsi qui sono i problemi di livello aziendale più elevati che le altre risposte sottolineano. Il più grande che mi viene in mente è coerenza, uniformità, auditing chiaro, semplicità di auditing. Sebbene risolvere un tesoro di problemi con molti di questi altri sistemi VCS sia grande.

Ci sono riduzioni negli sforzi duplicati per tutti quei dipartimenti che devono scrivere diversi script stravaganti per integrarsi tra i diversi sistemi, per controllarli e riferire su di essi e controllarli.

• Ogni volta che ho dovuto usare SVN in un ambiente paranoico come una società commerciale, l'assurdo aggancio di "conformità" e "sicurezza" era estremamente dannoso per le prestazioni.

Da quando ho analizzato i problemi di utilizzo tecnico da un potenziale sviluppatore, lo dirò. Con oltre 15 anni di utilizzo totale ho usato CVS, SVN, CMVC, clearcase, perforce e altri sistemi in un ambiente professionale insieme a GIT. Se qualcuno volesse che usassi qualcosa di diverso da GIT (ad eccezione forse di bzr, mercurial, perforce e clearcase (a seconda della configurazione degli ultimi due)) saprei immediatamente che il mio tempo è meglio speso altrove. Ero quasi a questa conclusione (anche se estendendo una leggera indennità a CVS e SVN) nel 2009. Ero così stufo delle brevi cadute di come SVN era usato sul mio posto di lavoro che ho iniziato a usare GIT come mio client SVN all'inizio del 2010 prima contribuendo a convincerci a passare a GIT.