Compliance na administração de DVCS em contexto empresarial, o que esperar de uma transição de CVCS (Perforce)?

Question

Trabalho em uma grande empresa multinacional como engenheiro de software e atualmente estou mantendo uma conversa muito agradável com TI e outros desenvolvedores sobre a adoção de um DVCS (Mercurial e/ou Git).

Uma das questões levantadas pela TI foi conformidade e propriedade intelectual (BTW,Forforce fala alto sobre issoe em relação ao Git). Parece-me que a TI tem a impressão de que, como o Mercurial/Git é distribuído, ter repositórios em todas as máquinas de desenvolvimento é um cenário fora de controle e eles teriam que auditar cada repositório.

Outra coisa que considero preocupante para a TI é o fato de agora ter "100" repositórios em vez de "10" enormes, tenho a impressão de que eles acham que seu esforço administrativo para mantê-los/monitorá-los cresceria "dez- dobrar". Acho que um software de gerenciamento de repositório (Rhodecode, Atlassian Stash) seria o primeiro passo para fornecer controle de acesso e rastreabilidade.

Minhas perguntas são:

1. O software de gerenciamento de repositório é suficiente para uma empresa desse tamanho (digamos, aproximadamente 2.000 desenvolvedores e aproximadamente 50 depósitos Perforce em aproximadamente 10 servidores)?, para ser compatível (e atender a outros requisitos corporativos?)

2. O que exatamente está abrangido por esse requisito de "conformidade"? Há alguma referência que você possa fornecer (por exemplo, um padrão IEEE ou algo parecido)?

Minha empresa usa o Perforce há cerca de 10 anos

Answer 1

Na verdade, não muda muita coisa quando você muda para um DVCS. A grande diferença é que a cópia do código-fonte na estação de trabalho de cada desenvolvedor agora também é seu próprio repositório.

Duvido que haja muitos motivos para a TI se preocupar com isso. Só porque git e mercurial são distribuídos, não significa que você irá implantar/entregar diretamente do desktop de algum desenvolvedor. Ainda é possível - e quase certamente necessário - continuar usando alguns repositórios centrais que todos verificam, para testes, controle de qualidade e eventual lançamento.

Esteja a TI monitorando o código-fonte nas estações de trabalho dos desenvolvedores ou não, nada realmente muda. Você ainda colocará o histórico de alterações nos repositórios centrais assim que eles forem enviados, e é com isso que suspeito que eles estão realmente preocupados.

O que vocêganhoa partir disso, do ponto de vista de TI, você não acessa os repositórios centrais a cada poucos minutos (ou segundos!) sempre que os desenvolvedores fazem um commit. Os desenvolvedores podem terminar de trabalhar em algo e, em seguida, acioná-lo somente quando estiver pronto, mas ainda assim ter controle de versão completo em sua estação de trabalho sem precisar acessar tanto a rede.

Por fim, você precisa conversar mais detalhadamente com a TI sobre a natureza exata dos problemas de conformidade sobre os quais eles estão falando. Isso pode ser qualquer coisa, desde gerenciamento de propriedade intelectual, ISO 9000 ou algumas leis/regulamentos governamentais.

(Para todos: sintam-se à vontade para melhorar esta resposta; esta énãominha área de especialização...)