Deveríamos estar hospedando código online?


22

Estamos procurando uma boa solução de controle de fonte e gerenciamento de projetos no meu local de trabalho e sugeri a criação de uma organização GitHub e repositórios privados. Eu amo o GitHub por muitas razões, mas não se trata do GitHub (de fato, meus colegas apresentarão pontos em favor de plataformas concorrentes) - é sobre o armazenamento de nosso código privado online .

Estou tentando entender se é uma boa ideia ou não. Definitivamente, parece vantajoso porque elimina a necessidade de custos do servidor (pelo menos diretamente) e também facilita a pesquisa de código (tudo está online).

No entanto, nossa equipe está indecisa e me leva à minha pergunta, o que devemos considerar para tomar essa decisão?


13
Observe que você não precisa armazenar seu código na nuvem para usar o github. Eles vendem um produto corporativo
Gort the Robot

1
@StevenBurnap, sim ... por 10 vezes o preço do pacote da organização . =)
Mathieu Guindon

12
Também nota, você não precisa Github para uso git
Harrison Paine

6
Lembre-se de que não se trata apenas de código. É comum que os desenvolvedores comprometam acidentalmente coisas como senhas e chaves SSL.
Nate CK

5
Estou francamente surpreso que ninguém tenha mencionado o GitLab Community Edition que, ao contrário do GitHub , é na verdade um código aberto . Você não precisa armazenar código na nuvem ou obter software proprietário para usar o GitLab. (@StevenBurnap)
Wildcard

Respostas:


24

Como profissional,

Se o escritório da sua empresa queimar, o código ainda está no servidor.

Se o escritório da sua empresa não queima, mas o servidor no qual seu repositório git está localizado, você ainda tem uma cópia local.

Se você hospedar seu repositório no servidor no prédio de escritórios da empresa (como faria com uma unidade compartilhada de rede ...?), Se o escritório da empresa queimar, você perde os dois.

Claro, você ainda precisa de backups como de costume ...

Sinta-se livre para substituir "queimaduras" por "é infectado com ransomware".

Basicamente, a disponibilidade está alta.

Como um golpe,

Você precisaria compartilhar seus arquivos com terceiros que hospedarão seu código. Se você tem realmente grandes segredos da empresa, isso pode não ser permitido. Por exemplo, se você tiver um banco de dados contendo informações pessoais de cidadãos europeus, poderá não ter permissão para hospedar seu código em terceiros dos EUA - porque eles estariam sujeitos à lei dos EUA e, portanto, não poderiam confiar nela. defender as leis de privacidade da UE. Mesmo que não seja um problema legal, você deve estar ciente de que o terceiro pode ser subornado para fornecer seus arquivos particulares. Isso provavelmente seria muito ruim para terceiros (grande penalidade de reputação), mas poderia acontecer.

Basicamente, a confidencialidade diminuiu.


Se você concorda com a confidencialidade da negociação quanto à disponibilidade, é uma boa idéia hospedar seu código privado on-line com terceiros. Caso contrário, não. Você pode explicar as vantagens e desvantagens para permitir que seu chefe tome uma decisão inteligente - mas pode ouvir "não". É o que pode acontecer se você der uma decisão a alguém. Se o seu chefe diz que não, então é isso. Eu não acho que convencer à força o seu chefe é uma idéia muito boa.


Como esta é uma pergunta da lista, outro argumento a acrescentar à sua lista: e se a organização anfitriã seguir o caminho do Google Code?
David Hammen

@DavidHammen Se o servidor queimar, você tem uma cópia local ... mas ... acho que há um problema com a manutenção não planejada ...? Eu acho que esse ponto está disponível nos dois lados; se você hospedar seu próprio servidor, o servidor ficará inativo; se outra pessoa hospedar o servidor, ele poderá ficar inativo quando for inconveniente. Nesse caso, o github pode ficar louco, mas o seu servidor também. Eu acho que é menos provável que a terceira parte desapareça, neste caso.
Pimgd

9
Observe que se você estiver usando o git, todo desenvolvedor terá uma cópia do repositório. (Menos filiais particulares.)
Gort the Robot

3
@DavidHammen Então, assim como se os servidores do serviço tivessem queimado, você ainda tem uma cópia local. E então você pode optar por mudar para um serviço alternativo ou trazer tudo isso internamente.
precisa saber é o seguinte

3
@ njzk2 por causa de redes de baixa latência? Ou porque você é uma pequena empresa? Talvez a sua internet é uma porcaria total eo que você gostaria de ter acesso rápido aos seus arquivos ...
Pimgd

11

Obviamente, é uma questão de confiança no provedor e quanto você valoriza o seu código-fonte.

No entanto, acho claro que, pelo menos no passado, as pessoas valorizavam demais seu código-fonte.

  • Para produtos de 'automação de processos de negócios'; onde uma equipe interna cria sites e outros softwares especificamente para as necessidades da empresa. O valor desse software para outras pessoas geralmente é muito baixo.

  • Para software vendável; é o binário que você está vendendo e pode ser copiado e invadido sem acesso ao código-fonte.

Em segundo lugar: você também deve considerar se o armazenamento de seu código com terceiros realmente aumenta sua exposição acima do nível atual. Em muitos casos, não

  • Por exemplo; se o seu produto for um site sem código de back-end, ele já é público.
  • Se o seu código compilado for distribuído, ele poderá ser descompilado.
  • Se o seu código for um site ou serviço e você o estiver hospedando com terceiros. Em seguida, o terceiro pode descompilar seu código.
  • Se você armazenar seus backups com terceiros, eles terão acesso ao seu código.

Em resumo, as empresas mais modernas confiarão em uma variedade de terceiros nos seus negócios do dia a dia; até coisas vitais e únicas para eles.


3

Uma parte desse processo de decisão pode ser um pouco de teste, tentativa e erro. Faça um pequeno projeto e peça a alguns membros experimentarem alguns dos sites. Isso deve cobrir a usabilidade da equipe, mas há outras considerações.

  1. Infra-estrutura atual - Algumas empresas já possuem servidores, conexões à Internet, VPN e pessoas na equipe com habilidades para hospedar servidores, para que alguns dos custos e preocupações possam ser absorvidos com muito mais facilidade. Uma startup pode estar mais inclinada a usar algo como o Github porque não precisa fazer esse tipo de investimento e pode começar a funcionar mais cedo.
  2. Orçamento - Muitos aspectos do nº 1 se enquadram aqui, mas pode haver outras soluções com um preço elevado. Algumas empresas podem justificar os custos. Obviamente, com um orçamento baixo, muitas opções são eliminadas.
  3. Distribuição da equipe - Quando todos trabalham fora do mesmo escritório durante as mesmas horas, talvez você não precise do github. Se o seu servidor de arquivos não estiver muito sobrecarregado, basta colocar o Git nele.
  4. Segurança - Você provavelmente pode encontrar muitos sites seguros, mas as percepções de segurança para alguns clientes são mais importantes. Ter sua própria rede de ferro pode ser a coisa certa a ganhar sua confiança. Distintivos de segurança, scanners de retina e guardas armados apenas gritam segurança para alguns clientes.
  5. Treinamento - Há mais do que apenas como usar o aplicativo, existem as regras e procedimentos que sua empresa / equipe deseja implementar. Ter uma idéia de como você deseja fazer as coisas pode orientar quais ferramentas usar. Atrair membros adicionais da equipe fica um pouco mais fácil se eles gostam do jeito que você faz as coisas.

Comece a trabalhar em todo o processo de codificação e entrega. Quanto mais pessoas envolvidas nesse processo, melhor. Você não deseja adotar uma plataforma de controle de origem com base em certos critérios, apenas para que alguém no gerenciamento mude tudo. "Essa coisa ágil distribuída não está funcionando, então vamos precisar que todos comecem a trabalhar no escritório das 8 às 7 da manhã de segunda-feira, ok."


2

Não estou necessariamente dizendo que você não deve hospedar o repositório da sua empresa na nuvem, mas eu pessoalmente experimentei algumas desvantagens e problemas com a hospedagem na nuvem.

Quão rápida e confiável é a sua conexão à Internet?

Para mim, essa é a maior consideração. Por exemplo, minha empresa está localizada em uma bonita área rural. Enquanto nossas velocidades intra- rede são extremamente rápidas, nossas velocidades inter- rede são lentas na melhor das hipóteses, na verdade, na pior das hipóteses.

Dependendo do VCS que você estiver usando, parte da dor pode ser atenuada. Os sistemas distribuídos de controle de versão, como o Git, não são tão ruins porque você ainda pode trabalhar localmente. Você pode até iniciar um novo repositório em uma unidade de rede se realmente precisar compartilhar algum código com um colega de trabalho. Em comparação, você realmente não pode fazer nenhuma dessas coisas com o Team Foundation (apesar de toda a área de trabalho local).

Mas esse é apenas o código. Há muito mais no seu repositório hospedado na nuvem do que apenas o código. E os seus itens de trabalho (recursos / lista de erros)? E a sua documentação (wiki)? E sua construção de integração contínua? Provavelmente, todas essas coisas também serão hospedadas na nuvem ao lado do seu código. Se a sua conexão à Internet cair, como você trabalhará sem essas coisas?

O Gitlab fornece uma versão gratuita no local que provavelmente fornecerá mais do que sua equipe precisa. Eu recomendo uma instalação no local. Reduzirá consideravelmente os riscos.


1
É incrível como minha opinião sobre isso muda agora que estou trabalhando na cidade com uma conexão confiável à Internet. Se sua internet é confiável, não há razão para pagar os custos de manutenção nos servidores premium.
RubberDuck

1

O que devemos considerar para tomar essa decisão?

Você deve considerar as desvantagens. Eu (juntamente com outros) incentivei com sucesso meu atual empregador a parar de hospedar as jóias de propriedade intelectual da empresa em um repositório privado do github. Não me leve a mal; O github é fantástico para software de código aberto.

No caso de software de código fechado, o github.com (ou alguma alternativa) assinou um contrato de confidencialidade (NDA) para não divulgar seu código-fonte ao mundo? Boa sorte com isso!

Na minha opinião, é totalmente louco divulgar as joias de propriedade intelectual para outra entidade até que outra entidade tenha assinado um NDA com você. Você planeja usar um serviço como o github que não assina NDAs com seus clientes. Em vez disso, eles oferecem uma promessa vaga na forma de um EULA muito longo (contrato de licença de usuário final).

O próprio Github percebe que isso pode ser um problema significativo e, como resultado, oferece o Github Enterprise como um mecanismo para hospedar o código-fonte (e outras coisas particulares) no próprio servidor.


4
Então ... para o site de um fabricante simples, tudo bem, certo? A "propriedade intelectual da coroa" da empresa é mais sobre o que estamos fabricando do que sobre o código que usamos para promovê-lo.
Mathieu Guindon
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.