Perché le grandi compagnie finanziarie / assicurative devono usare git e / o gitub

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

• Qualsiasi controllo di versione è migliore di niente. Abbiamo molto da scegliere, cosa c'è di sbagliato in questi?
• Controllo della versione distribuita? Cos'è quello? Come controlliamo quello?
• Quanto costa? Non solo il software, ma i server, le licenze, la manutenzione, ecc.
• Non mi fido di GitHub, o qualsiasi hosting in outsourcing. Dobbiamo fare tutto internamente. Perché non possiamo configurare il nostro server?
• Possiamo eseguirlo su Windows? Dobbiamo tenerlo sulla base attuale, lo sai.
• Come possiamo proteggere la cosa? SVN otteniamo, ma questo mi spaventa.

Queste sono le prime domande che verranno poste. Per quanto riguarda VSS e PVCS, è probabile che sia disponibile una serie di argomenti ragionevolmente validi (come VSS che danneggia la cronologia delle versioni). SVN sarà un po 'più difficile. Consiglio vivamente di concentrarsi sulle funzionalità di fusione di GIT e di raccomandare di mantenere una mentalità 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 del rischio, considera cosa potrebbe accadere se qualcuno ha violato GitHub e rubato il codice sorgente, o ha scoperto la vulnerabilità della sicurezza documentata nel tracker dei problemi. Sarebbe devastante per l'azienda. Da una prospettiva di gestione pura, se la società è legalmente tenuta a pagarti per ogni ora di lavoro, come può monitorare se stai lavorando da casa quando le risorse sono al di fuori della loro rete VPN? In un'altra nota, come possono impedirti di svolgere attività di 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 ha per guardare le cose in questo modo. Per una piccola azienda, si guarda alla linea di fondo e quanto costerebbe mettere tutti quei servizi in atto.

In realtà è più economico per la grande azienda farlo in casa. Hanno già le risorse IT, hanno solo bisogno di mescolare le responsabilità un po '. E se la soluzione si prende cura di se stessa con solo la manutenzione periodica necessaria (backup e gestione degli utenti), un motivo in più per tenerlo all'interno delle porte dell'azienda.

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

Infine, in tale una grande organizzazione ci sono garantiti che i feudi vogliono fare le cose a modo loro. Tutti hanno argomenti convincenti sul motivo per cui hanno scelto VSS, PVCS, SVN o cosa hai. Per IT sono tutti uguali. L'unico modo per consolidare all'interno di un'organizzazione così grande è di avere l'ordine giungere per fiat 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 di Total Cost of Ownership (TCO) per avere un sistema di controllo di 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'azienda abbia scelto specificamente prodotti Microsoft per lo sviluppo, non esiste ancora l'architettura master, la lingua o il controllo del codice sorgente. Stiamo tutti utilizzando .Net, ma abbiamo diversi progetti in diverse versioni del framework e in diverse lingue. Alcuni progetti utilizzano VFS altri TFS. Ora abbiamo un nuovo architetto di livello superiore come responsabile della gestione della qualità e ha lanciato una transizione più aziendale dal nostro bug tracking di hodge-podge, dal controllo del codice sorgente, dall'utilizzo del framework a un'implementazione più universale di TFS per tutto questo. Ciò è reso possibile solo dal fatto che egli è un) estremamente esperto nella natura del software, b) altamente posizionato all'interno della società e in grado di influenzare sia tramite l'astuzia che la posizione, e c) non direttamente affiliato con un particolare software team .

Nell'affrontare questo problema all'interno della tua organizzazione, devi prima considerare alcune cose:

1. Perché sei così innamorato di GitHub come risposta? Stai cercando un controllo del codice sorgente o stai cercando un motivo per implementare qualcosa con cui ti senti a tuo agio? Non conosco la risposta (e francamente non mi interessa), ma questa è una domanda che si presenterà quando inizierai a cazzeggiare negli affari degli altri.
2. Sei attualmente affiliato con uno di questi team software? Se sì, potrebbe essere necessario trovare un individuo non affiliato e ben posizionato per difendere il concetto. Altrimenti, altri team di sviluppo potrebbero semplicemente sentire che stai tentando di imprimere il tuo pensiero su di loro. Ciò li renderà ancora più resistenti al concetto poiché hanno già qualcosa che funziona (secondo loro).
3. Hai mai contattato le persone di altre squadre per ottenere il consenso al concetto? Gli altri sviluppatori hanno opinioni o preoccupazioni simili? Un'altra strada per ottenerlo è costruire una massa critica che segua tra le persone che svolgono il lavoro. Man mano che sempre più persone iniziano a richiedere repository di sorgenti comuni, la gestione dovrà prendere nota.
4. Hai familiarità con il codice / i processi / i requisiti degli altri team abbastanza da dire che GitHub lavorerà 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, maggiore produttività degli sviluppatori, maggiore ridondanza del codice base (per il backup), ecc., Ecc. Ciò che alla fine dovrai fare è convincere le persone che scrivono assegni per tutto ciò che il tempo, gli sforzi e i soldi spesi per passare a un modello del genere varrà alla fine come un ritorno sul loro investimento. Dovrai anche dimostrare che il supporto futuro per lo stesso modello sarà lì quando alla fine "lentamente e deliberatamente" succederà. Cosa succede quando il supporto per il software non è più disponibile (per qualsiasi motivo) o in un modello ospitato cosa succede se l'azienda va a pancia in giù e chiude le sue porte?

Ci sono molte cose che vanno in un tale cambiamento d'impresa nella dottrina, quindi ci vorrà un sacco di entusiasmo di stile di base e avrai sicuramente bisogno di qualcuno a livello di VP per difendere il concetto. Un manager potrebbe funzionare, ma un dirigente avrà molta più autorità per imprimere concetti su altri gruppi.

Tali società vorranno avere i loro repository centralizzati. SVN, VSS ad PVC hanno una cosa in comune: sono tutte architetture 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 la gestione molto probabilmente non accetterà mai.

C'è comunque una soluzione che potrebbe soddisfare entrambe le parti. Git ha git-svn comando. Fondamentalmente avresti un repository SVN, ma alcuni sviluppatori potrebbero scegliere di avere il loro repository GIT locale e sincronizzarlo con il repository SVN centralizzato. Buona alternativa ai rami privati o invio di patch non modificate. Buona how-to per l'integrazione git-svn .

Molte di queste risposte sono significativamente 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 restrizione.
• Esiste una versione Enterprise di GitHub disponibile per l'hosting interno . link . Non è gratuito e costa $ ovviamente

La società in cui lavoro ha iniziato a usarlo e abbiamo avuto le stesse preoccupazioni ESATTE 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 che sono 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 per elencarli. L'unica cosa su cui vale la pena concentrarsi qui è l'alto livello di problemi aziendali più grandi che le altre risposte sottolineano. Il più grande che posso pensare è consistenza, uniformità, auditing chiaro, semplicità di auditing. Anche se risolvere un tesoro di problemi con molti di questi altri sistemi VCS è uno dei più grandi.

Ci sono riduzioni nello sforzo duplicato a tutti quei dipartimenti che devono scrivere diversi script stravaganti per integrarsi tra i diversi sistemi, controllarli e riferire su di essi e controllarli.

• Ogni volta che dovevo usare SVN in un ambiente paranoico come un'azienda commerciale, gli assurdi 'compliance' e 'security' erano estremamente dannosi per le prestazioni.

Da quando ho ignorato i problemi di utilizzo tecnico da una prospettiva di sviluppo, dirò questo. Con oltre 15 anni di utilizzo ho utilizzato 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 (con l'eccezione forse di bzr, mercurial, perforce e clearcase (a seconda della configurazione degli ultimi due)) vorrei sapere immediatamente che il mio tempo è meglio speso altrove. Ero quasi arrivato a questa conclusione (anche se con un lieve aumento di CVS e SVN) nel 2009. Ero così stufo delle brevi cadute di come SVN era usato nel mio posto di lavoro Ho iniziato a usare GIT come mio cliente SVN all'inizio 2010 prima di contribuire a convincerci a passare al GIT.