Por que grandes empresas financeiras / de seguros devem usar git e / ou github

Trabalho para uma grande empresa (30 mil funcionários) no setor financeiro / de seguros. Embora "TI" não seja nosso foco principal, sejamos honestos, são setores orientados a informações e as empresas com a melhor vantagem tecnológica parecem progredir mais rapidamente.

Existem muitas equipes de desenvolvimento de software na minha empresa. Eles estão espalhados por todo o mapa com controle de versão, sem falar nas linguagens / estruturas usadas. Alguns não usam (eu sei), alguns usam PVCS, outros usam VSS e os mais esclarecidos usam SVN.

Eu quero trazer o git para a minha empresa. Mais especificamente, quero trazer o GitHub (repositórios privados). Conheço as pessoas certas para conversar sobre isso, mas vamos ser honestos novamente, movimentos drásticos como esse geralmente são abatidos no cenário de grandes empresas por causa de vagas preocupações de segurança ou pelo fato de nenhum de nossos concorrentes estar usando (e eu posso cite apenas jQuery, Ruby on Rails, Facebook, etc como referência).

Então, minha pergunta é essa. Quais são as razões mais convincentes pelas quais uma grande empresa deve lenta e deliberadamente mudar do PVCS / VSS / SVN para uma solução git hospedada como o GitHub (repositório privado). Obviamente, parte do meu plano envolve um POC para um projeto de desenvolvimento não essencial.

Há algumas coisas que me preocupam, como um terceiro desinteressado. Então, deixe-me fazer algumas perguntas para você que é melhor você estar preparado para responder (ao seu departamento de TI):

• Qualquer controle de versão é melhor que nenhum. Temos muito por onde escolher, o que há de errado nisso?
• Controle de versão distribuído? O que é isso? Como controlamos isso?
• Qual é o custo? Não apenas o software, mas também os servidores, licenças, manutenção etc.
• Não confio no GitHub ou em qualquer hospedagem terceirizada. Precisamos fazer tudo internamente. Por que não podemos configurar nosso próprio servidor?
• Podemos executá-lo no Windows? Temos que mantê-lo em nossa linha de base atual, você sabe.
• Como protegemos a coisa? Temos SVN, mas isso me assusta.

Essas são as primeiras perguntas que surgirão. Quanto ao VSS e PVCS, você provavelmente pode apresentar vários argumentos razoavelmente bons (como o VSS corrompendo o histórico de versões). O SVN será um pouco mais difícil. Eu recomendo enfatizar os recursos de mesclagem do GIT e também recomendo manter a mente aberta sobre o Mercurial. Todo argumento para o GIT também é um argumento para o Mercurial - e o Mercurial tem suporte mais maduro ao Windows.

A segurança é de suma importância para instituições financeiras e governamentais. Eles serão extremamente resistentes a recursos hospedados externamente. Da perspectiva do gerenciamento de riscos, considere o que poderia acontecer se alguém invadisse o GitHub e roubasse o código-fonte ou descobrisse a vulnerabilidade de segurança documentada no rastreador de problemas. Isso seria devastador para a empresa. De uma perspectiva pura de gerenciamento, se a empresa é legalmenteComo é necessário pagar por cada hora em que você trabalha, como eles podem monitorar se você está trabalhando em casa quando os recursos estão fora da rede VPN? Em outra nota, como eles podem impedir você de executar alguma espionagem corporativa quando todos os recursos estão disponíveis fora da empresa? Esses são os argumentos de TI e de gerenciamento contra a terceirização da hospedagem. Uma grande empresa precisa encarar as coisas dessa maneira. Para uma empresa pequena, você analisa os resultados e quanto custaria para implementar todos esses serviços.

Na verdade, é mais barato para a grande empresa fazer isso internamente. Eles já têm os recursos de TI, precisam apenas embaralhar um pouco as responsabilidades. E se a solução se cuidar em grande parte, apenas com manutenção periódica necessária (backups e gerenciamento de usuários), mais um motivo para mantê-la dentro das portas da empresa.

Quanto à hospedagem do Windows, trata-se de um problema de organização por organização. Várias empresas engoliram o koolaid do Windows. Outros engoliram o koolaid do Linux. Outros o consideram caso a caso. Você terá que seguir as regras que o departamento de TI definiu para sua organização. Contanto que sua solução possa ser hospedada em qualquer um deles, você estará em ouro.

Finalmente, em uma organização tão grande, é garantido que todos os feudos querem fazer as coisas do seu jeito. Todos eles têm argumentos convincentes por que escolheram VSS, PVCS, SVN ou o que você tem. Para TI, eles são todos iguais. A única maneira de consolidar dentro de uma organização tão grande é fazer com que a ordem seja aprovada por cima. Esses pedidos sempre são atendidos com resistência, e provavelmente não é algo que sua empresa deseja fazer, a menos que haja benefícios óbvios de Custo Total de Propriedade (TCO) em ter um sistema de controle de versão padronizado.

Também trabalho em uma empresa financeira / de seguros (embora não seja tão grande quanto a que você está trabalhando atualmente). Também temos várias equipes de desenvolvimento e, embora a empresa tenha escolhido especificamente produtos da Microsoft para desenvolver, ainda não há arquitetura mestre, idioma ou controle de origem. Todos nós estamos usando .Net, mas temos vários projetos em diferentes versões da estrutura e em diferentes idiomas. Alguns projetos usam VSS, outros TFS. Agora, temos um novo arquiteto de nível superior como gerente de controle de qualidade e ele liderou uma transição mais corporativa do rastreamento de erros do hodge-podge, controle de origem, uso da estrutura para uma implementação mais universal do TFS para tudo isso. Isso só é possível pelo fato de ele ser a) extremamente experiente na natureza do software,

Ao abordar isso em sua própria organização, você deve considerar algumas coisas primeiro:

1. Por que você está tão apaixonado pelo GitHub como resposta? Você está procurando por um controle de fonte comum ou por um motivo para implementar algo com o qual se sinta confortável? Não sei a resposta (e francamente não me importo), mas essa é uma pergunta que surgirá quando você começar a zombar dos negócios de outras pessoas.
2. Você está atualmente afiliado a uma dessas equipes de software? Se sim, pode ser necessário encontrar um indivíduo não afiliado e bem posicionado para defender o conceito. Caso contrário, outras equipes de desenvolvimento podem sentir que você está tentando imprimir seu pensamento nelas. Isso os tornará ainda mais resistentes ao conceito, já que eles já têm algo que funciona (na opinião deles).
3. Você já fez alguma divulgação a indivíduos de outras equipes para ganhar adesão ao conceito? Outros desenvolvedores têm opiniões ou preocupações semelhantes? Outro caminho para conseguir isso é construir uma massa crítica de seguidores entre as pessoas que realizam o trabalho. À medida que mais pessoas começam a exigir repositórios de fontes comuns, o gerenciamento precisa prestar atenção.
4. Você conhece o código / processos / requisitos das outras equipes o suficiente para dizer que o GitHub funcionará (ou não) para eles?

Quanto à sua pergunta final (ou real?), A única razão verdadeira e convincente a longo prazo, na perspectiva dos gerentes de negócios, é que ela economiza dinheiro. Essas economias podem estar na forma de tempo de inatividade reduzido, maior segurança do código, maior produtividade do desenvolvedor, maior redundância de base de código (para backup), etc, et al. Em última análise, o que você precisará fazer é convencer as pessoas que fazem cheques para tudo isso de que o tempo, o esforço e o dinheiro gastos na transição para esse modelo valerão a pena no final como retorno do investimento. Você também precisará mostrar que o suporte futuro para o mesmo modelo estará lá quando "lenta e deliberadamente" finalmente acontecer.

Há muita coisa que entra nessa mudança de doutrina da empresa; portanto, é preciso muito entusiasmo do estilo de base e você definitivamente precisará de alguém no nível de vice-presidente para defender o conceito. Um gerente pode funcionar, mas um executivo terá muito mais autoridade para imprimir conceitos em outros grupos.

Essas empresas vão querer ter seus repositórios centralizados. SVN, VSS e PVCS têm uma coisa em comum - todos eles são arquitetura cliente-servidor. O Git é projetado como VCS distribuído e, por natureza, é descentralizado.

GitHub - ainda mais problemático. É um serviço externo. O código-fonte no serviço externo é algo que o gerenciamento provavelmente nunca aceitará.

No entanto, existe uma solução que pode manter os dois lados satisfeitos. Git tem git-svncomando. Basicamente, você teria um repositório SVN, mas alguns desenvolvedores podem optar por ter seu próprio repositório GIT local e sincronizá-lo com o repositório SVN centralizado. Boa alternativa para filiais particulares ou envio de patches não solicitados. Boas instruções para a integração do git-svn .

Várias dessas respostas estão significativamente desatualizadas em relação a comentários sobre o GitHub e segurança devido a alterações no GitHub desde que foram postadas.

• O GitHub não força você a ser hospedado externamente
• A versão GRATUITA do GitHub é o que coloca essa restrição em vigor.
• Existe uma versão corporativa do GitHub disponível para hospedagem interna . https://enterprise.github.com/home . Não é gratuito e custa $ é claro

A empresa em que trabalho começou a usá-lo e tínhamos exatamente as mesmas preocupações porque nosso código é um segredo comercial, estamos no setor financeiro. Além disso, existem outras maneiras de usar o GIT que não envolvem o GitHub que são semelhantes, redmine, gitosis, etc.

Com relação à pergunta "quem está usando": PayPal, Etsy, rackspace, vimeo, SAP, JPL da NASA , Linux Kernel

Razões técnicas convincentes são muitas para listar. A única coisa que vale a pena focar aqui são os problemas corporativos de alto nível, que as outras respostas apontam. O maior em que consigo pensar é consistência, uniformidade, auditoria clara, simplicidade da auditoria. Embora resolver um grande tesouro de problemas com muitos desses outros sistemas VCS seja grande.

Há reduções no esforço duplicado para todos os departamentos que precisam escrever scripts malucos diferentes para integrar entre os diferentes sistemas, auditá-los, relatá-los e controlá-los.

• Toda vez que eu tive que usar o SVN em um ambiente paranóico como uma empresa comercial, os ganchos absurdos de 'conformidade' e 'segurança' eram extremamente prejudiciais ao desempenho.

Desde que encarei os problemas de uso técnico de um prospect em desenvolvimento, vou dizer isso. Com mais de 15 anos de uso total, usei CVS, SVN, CMVC, clearcase, perforce e outros sistemas em um ambiente profissional, juntamente com o GIT. Se alguém quisesse que eu usasse algo diferente de GIT (com exceção talvez de bzr, mercurial, forforce e clearcase (dependendo da configuração dos dois últimos)) , saberia imediatamente que meu tempo é melhor gasto em outro lugar. Eu estava quase nessa conclusão (embora estendendo uma pequena permissão ao CVS e ao SVN) em 2009. Eu estava tão farto das pequenas quedas de como o SVN era usado no meu local de trabalho que comecei a usar o GIT como meu cliente SVN no início de 2010 antes ajudando a nos convencer a mudar para o GIT.