Que parte do seu projeto deve estar no controle do código-fonte?

Um colega desenvolvedor começou a trabalhar em um novo projeto Drupal, e o sysadmin sugeriu que eles apenas colocassem os sites / subdiretório padrão no controle de origem, porque "tornará as atualizações facilmente programáveis". Deixando de lado essa afirmação um tanto duvidosa, ele levanta outra questão - quais arquivos devem estar sob controle de origem? E existe uma situação em que uma grande parte dos arquivos deve ser excluída?

Minha opinião é que toda a árvore do projeto deve estar sob controle, e isso seria verdade para um projeto Drupal, trilhos ou qualquer outra coisa. Parece um acéfalo - você claramente precisa de versões para sua estrutura, tanto quanto para qualquer código personalizado que escreve.

Dito isto, eu gostaria de obter outras opiniões sobre isso. Existem argumentos para não ter tudo sob controle?

Eu diria que o mínimo que o controle de origem deve conter é todos os arquivos necessários para recriar uma versão em execução do projeto. Isso inclui até arquivos DDL para configurar e modificar qualquer esquema de banco de dados e também na sequência correta. Menos, é claro, as ferramentas necessárias para construir e executar o projeto, bem como qualquer coisa que possa ser derivada / gerada automaticamente de outros arquivos no controle de origem (como arquivos JavaDoc gerados a partir dos arquivos Java no controle de origem).

É melhor colocar quase tudo sob o sol no controle da fonte.

• Código

• Bibliotecas

• Recursos

• Criar / implantar scripts

• Scripts de criação e atualização de banco de dados

• Certa documentação

• Arquivos de configuração específicos do ambiente

A única coisa que não deve ser colocada no controle de origem são os artefatos de construção para o seu projeto.

Eu diria isso;

• qualquer arquivo necessário para executar a compilação entra no controle de versão
• qualquer arquivo (que possa ser) gerado pela compilação não

Eu tenderia a colocar binários grandes, como pacotes de instalação de ferramentas em algum lugar fora do tronco, mas eles ainda devem estar sob controle de versão.

E não se esqueça de colocar todo o código do banco de dados no Source Control também! Isso incluiria os scripts de criação original, os scripts para alterar as tabelas (marcadas por qual versão do software as utiliza, para que você possa recriar qualquer versão do banco de dados para qualquer versão dos aplicativos) e os scripts para preencher as tabelas de pesquisa.

A experiência conquistada com dificuldade me ensinou que quase tudo pertence ao controle de origem. (Meus comentários aqui são coloridos por uma década e meia em desenvolvimento para sistemas embarcados / telecomunicações em hardware proprietário com ferramentas proprietárias e, às vezes, difíceis de encontrar.)

Algumas das respostas aqui dizem "não coloque binários no controle de origem". Isto é errado. Ao trabalhar em um produto com muitos códigos de terceiros e muitas bibliotecas binárias de fornecedores, você faz check-in nas bibliotecas binárias . Porque, se não o fizer, em algum momento você atualizará e terá problemas: a compilação é interrompida porque a máquina de compilação não possui a versão mais recente; alguém fornece ao novo cara os CDs antigos para instalar; o wiki do projeto possui instruções antigas sobre qual versão instalar; Pior ainda, se você precisar trabalhar em estreita colaboração com o fornecedor para resolver um problema específico e ele enviar cinco conjuntos de bibliotecas em uma semana, você deverápoder rastrear qual conjunto de binários exibiu qual comportamento. O sistema de controle de origem é uma ferramenta que resolve exatamente esse problema.

Algumas das respostas aqui dizem "não coloque a cadeia de ferramentas no controle de origem". Não vou dizer que está errado, mas é melhor colocar a cadeia de ferramentas no controle de origem, a menos que você tenha um sistema de gerenciamento de configuração sólida (CM) . Mais uma vez, considere o problema de atualização conforme mencionado acima. Pior ainda, trabalhei em um projeto em que havia quatro tipos diferentes de ferramentas flutuando quando fui contratado - todos eles em uso ativo ! Uma das primeiras coisas que fiz (depois que consegui fazer uma compilação funcionar) foi colocar a cadeia de ferramentas sob controle de origem. (A idéia de um sistema sólido de CM estava além da esperança.)

E o que acontece quando projetos diferentes exigem cadeias de ferramentas diferentes? Caso em questão: Após alguns anos, um dos projetos recebeu uma atualização de um fornecedor e todos os Makefiles foram interrompidos. Acontece que eles estavam contando com uma versão mais recente do GNU make. Então, todos nós atualizamos. Opa, os Makefiles de outro projeto quebraram. Lição: confirme as duas versões do GNU make e execute a versão que acompanha o checkout do seu projeto.

Ou, se você trabalha em um lugar onde todo o resto está descontroladamente descontrolado, você tem conversas como: "Ei, o cara novo está começando hoje, onde está o CD do compilador?" "Não sei, não os vejo desde que Jack saiu, ele era o guardião dos CDs." "Uhh, não foi isso antes de sairmos do 2º andar?" "Talvez eles estejam em uma caixa ou algo assim." E como as ferramentas têm três anos, não há esperança de obter esse CD antigo do fornecedor.

Todos os seus scripts de construção pertencem ao controle de origem. Tudo! Todo o caminho até as variáveis ​​de ambiente. Sua máquina de compilação deve poder executar uma compilação de qualquer um dos seus projetos executando um único script na raiz do projeto. ( ./buildé um padrão razoável; ./configure; makeé quase tão bom.) O script deve configurar o ambiente conforme necessário e, em seguida, iniciar qualquer ferramenta que construa o produto (marca, formiga etc.).

Se você acha que é muito trabalho, não é. Na verdade, economiza uma tonelada de trabalho. Você confirma os arquivos uma vez no início dos tempos e sempre que atualizar. Nenhum lobo solitário pode atualizar sua própria máquina e confirmar um monte de código-fonte que depende da versão mais recente de alguma ferramenta, quebrando a compilação para todos os outros. Quando você contrata novos desenvolvedores, pode pedir para eles verificarem o projeto e executarem ./build. Quando a versão 1.8 possui muitos ajustes de desempenho e você ajusta o código, os sinalizadores do compilador e as variáveis ​​de ambiente, você deseja garantir que os novos sinalizadores do compilador não sejam acidentalmente aplicados às compilações de patches da versão 1.7, porque eles realmente precisam do código mudanças que os acompanham ou você vê algumas condições de corrida peludas.

O melhor de tudo é que isso vai te salvar um dia: imagine que você envia a versão 3.0.2 do seu produto na segunda-feira. Viva, comemore. Na terça-feira de manhã, um cliente VIP liga para a linha direta de suporte, reclamando sobre esse bug supercrítico e urgente na versão 2.2.6 que você enviou há 18 meses . E você ainda precisa contratá-lo, e eles se recusam a atualizar até que você possa confirmar com certeza que o bug foi corrigido no novo código e que eles são grandes o suficiente para fazer você dançar. Existem dois universos paralelos:

• No universo em que você não tem bibliotecas, cadeia de ferramentas e scripts de construção no controle de origem, e você não possui um sistema CM sólido ... Você pode verificar a versão correta do código, mas ela fornece você todos os tipos de erros ao tentar criar. Vamos ver, atualizamos as ferramentas em maio? Não, essas eram as bibliotecas. Ok, volte para as bibliotecas antigas - espere, houve duas atualizações? Ah sim, isso parece um pouco melhor. Mas agora esse estranho acidente de vinculador parece familiar. Ah, é porque as bibliotecas antigas não funcionaram com a nova cadeia de ferramentas, é por isso que tivemos que atualizar, certo? (Vou poupar a agonia do resto do esforço. Leva duas semanas e ninguém fica feliz no final, nem você, nem a gerência, nem o cliente.)

• No universo em que tudo está no controle de origem, você confere a tag 2.2.6, tem uma compilação de depuração pronta em mais ou menos uma hora, passa um dia ou dois recriando o "bug VIP", localiza a causa, corrige-a a versão atual e convencer o cliente a atualizar. Estressante, mas não tão ruim quanto o outro universo em que sua linha do cabelo é 3 cm mais alta.

Com isso dito, você pode ir longe demais:

• Você deve ter uma instalação padrão do SO da qual tenha uma "cópia dourada" de. Documente-o, provavelmente em um README que esteja no controle de origem, para que as gerações futuras saibam que a versão 2.2.6 e anterior foram criadas apenas no RHEL 5.3 e 2.3.0 e posterior, apenas no Ubuntu 11.04. Se for mais fácil gerenciar o conjunto de ferramentas dessa maneira, siga em frente, apenas certifique-se de que é um sistema confiável.
• É difícil manter a documentação do projeto em um sistema de controle de origem. Os documentos do projeto estão sempre à frente do próprio código, e não é incomum trabalhar na documentação da próxima versão enquanto trabalha no código da versão atual. Especialmente se todos os documentos do seu projeto forem documentos binários que você não pode diferenciar ou mesclar.
• Se você possui um sistema que controla as versões de tudo usado na compilação, use-o ! Apenas verifique se é fácil sincronizar com toda a equipe, para que todos (incluindo a máquina de compilação) estejam utilizando o mesmo conjunto de ferramentas. (Estou pensando em sistemas como o pbuilder do Debian e o uso responsável do virtualenv do python.)

As únicas coisas que não coloco sob controle de origem são os arquivos que você pode regenerar facilmente ou são específicos do desenvolvedor. Isso significa executáveis ​​e binários compostos pelo seu código-fonte, documentação gerada a partir da leitura / análise de arquivos sob controle de origem e arquivos específicos do IDE. Tudo o resto entra no controle de versão e é gerenciado adequadamente.

O caso de uso do controle de origem é: E se todas as máquinas de nossos desenvolvedores e todas as nossas máquinas de implantação fossem atingidas por um meteoro? Você deseja que a recuperação esteja o mais próximo possível do check-out e da construção. (Se isso é muito bobo, você pode optar por "contratar um novo desenvolvedor".)

Em outras palavras, tudo que não seja SO, aplicativos e ferramentas deve estar no VCS e em sistemas embarcados, onde pode haver uma dependência de uma versão binária de uma ferramenta específica. Também vi as ferramentas mantidas no VCS!

O controle incompleto da fonte é um dos riscos mais comuns que vejo ao consultar - há todo tipo de atrito associado à criação de um novo desenvolvedor ou à instalação de uma nova máquina. Juntamente com os conceitos de Integração Contínua e Entrega Contínua, você deve ter um senso de "Desenvolvimento Contínuo" - uma pessoa de TI pode configurar uma nova máquina de desenvolvimento ou implantação essencialmente automaticamente, para que o desenvolvedor possa ver o código antes de terminar a primeira xícara de café?

Tudo o que contribui para o projeto e para o qual você deseja acompanhar as alterações.

As exceções podem incluir blobs binários grandes, como imagens, se você estiver usando um scm que não lida com dados binários muito bem.

Drupal usa git, então usarei a terminologia do git. Eu usaria sub-repositórios para cada módulo para poder obter as atualizações dos módulos dos repositórios oficiais do drupal, preservando a estrutura de implantações individuais. Dessa forma, você obtém os benefícios da capacidade de script sem perder os benefícios de ter tudo sob controle de origem.

Tudo deve estar sob controle de origem, exceto:

• Arquivos de configuração, se eles incluem opções de configuração diferentes para cada desenvolvedor e / ou cada ambiente (desenvolvimento, teste, produção)
• Arquivos de cache, se você estiver usando o cache do sistema de arquivos
• Arquivos de log, se você estiver efetuando logon em arquivos de texto
• Qualquer coisa que goste de arquivos de cache e de log é gerado por conteúdo
• (Muito) Arquivos binários grandes que dificilmente serão alterados (alguns sistemas de controle de versão não gostam deles, mas se você estiver usando hg ou git, eles não se importam muito)

Pense assim: Todo novo membro da equipe deve fazer check-out de uma cópia de trabalho do projeto (menos os itens de configuração).

E não se esqueça de colocar também alterações no esquema do banco de dados (simples despejos sql de todas as alterações no esquema) sob controle de versão. Você pode incluir documentação do usuário e da API, se isso fizer sentido para o projeto.

O @maple_shaft levanta uma questão importante na minha primeira declaração sobre os arquivos de configuração do ambiente nos comentários. Gostaria de esclarecer que minha resposta é aos detalhes da pergunta, que é sobre Drupal ou projetos genéricos de CMS. Nesses cenários, você normalmente possui um banco de dados local e um de produção, e uma opção de configuração do ambiente são as credenciais para esses bancos de dados (e credenciais similares). É aconselhável que eles NÃO estejam sob controle de origem, pois isso criaria várias preocupações de segurança.

No entanto, em um fluxo de trabalho de desenvolvimento mais típico, concordo com o maple_shaft que as opções de configuração do ambiente devem estar sob controle de origem para permitir uma construção e implantação em uma etapa de qualquer ambiente.

Tudo o que sua compilação automatizada gera não entra no controle de origem. Qualquer coisa que exige nenhuma modificação durante a construção não ir no controle de origem. É simples assim.

Por exemplo, o seguinte não entra no controle de origem:

• código gerado
• binários gerados
• qualquer coisa criada por sua compilação
• qualquer coisa criada em tempo de execução pelo seu serviço, processo, aplicativo da web

O que existe no controle de origem:

• qualquer coisa que um humano cria
• qualquer coisa criada por outra pessoa ou grupo (por exemplo, uma biblioteca interna de terceiros onde o controle de origem é distribuído ou os binários de um projeto de código aberto).
• scripts e outras fontes que criam coisas como um banco de dados (ou seja, como você recriaria o banco de dados se todos os DBAs fossem AWOL).

Essas regras práticas baseiam-se na noção de que tudo o que está no controle de origem pode ser modificado por um ser humano e pode levar um tempo valioso de alguém para entender por que ele está lá.

Qualquer coisa que você precise trabalhar e possa mudar precisa ser versionada de uma forma ou de outra. Mas raramente é necessário ter dois sistemas independentes para acompanhar isso.

Qualquer coisa gerada de maneira confiável geralmente pode ser anexada a uma versão de origem - portanto, não precisa ser rastreada de forma independente: fonte gerada, binários que não são transmitidos de um sistema para outro, etc.

Crie logs e outras coisas com as quais provavelmente ninguém se importa (mas você nunca sabe ao certo) geralmente são mais bem rastreados por quem os gerar: jenkins, etc.

A criação de produtos que são transmitidos de um sistema para outro precisa ser rastreada, mas um repositório automatizado é uma boa maneira de fazer isso - você não precisa do nível de controle que um controle de origem fornece. As entregas geralmente estão na mesma categoria.

O que resta (e nesse ponto, deve haver pouco mais do que arquivos de origem e configuração do servidor de compilação) entra no controle de origem.

Minha resposta é bem simples: não binários. Por implicação, quase tudo o resto.

(Definitivamente, não backups de bancos de dados, migrações de esquema ou dados do usuário).

O controle de origem é um mecanismo de rastreamento de alterações. Use-o quando quiser saber quem mudou o que e quando.

O controle da fonte não é gratuito. Isso adiciona complexidade ao seu fluxo de trabalho e requer treinamento para novos colegas. Pese os benefícios em relação ao custo.

Por exemplo, pode ser difícil controlar bancos de dados. Costumávamos ter um sistema em que era necessário salvar manualmente as definições em um arquivo de texto e adicioná-las ao controle de origem. Isso levou muito tempo e não era confiável. Como não era confiável, não era possível usá-lo para configurar um novo banco de dados ou verificar a que horas uma alteração foi feita. Mas mantivemos isso por anos, perdendo inúmeras horas, porque nosso gerente pensou que "todas as coisas deveriam estar no controle da fonte".

O controle da fonte não é mágico. Experimente, mas abandone-o se não agregar valor suficiente para compensar o custo.

Coisas que eu não colocaria no controle de origem:

• Chaves secretas e senhas
• O SDK, mesmo que seja o mesmo diretório, e se eu fizer um patch no SDK, ele deverá ser outro projeto, pois seria por estrutura e não por aplicativo
• Bibliotecas de terceiros como. Sobras da migração, backups, código compilado, código sob outra licença (talvez)

Por isso, não faço isso, hg addremovepor exemplo, desde que um novo clone seja criado de vez em quando quando o SDK é atualizado. Isso também me faz fazer um backup completo toda vez que o SDk for atualizado e verificar se uma nova versão clonada no repositório está correta.

Eu recomendo a você o seguinte livro que aborda suas preocupações:

Entrega contínua: versões confiáveis ​​de software por meio de automação de compilação, teste e implantação . Especificamente, o Capítulo 2 aborda os itens a serem colocados no controle de origem, o que, como algumas pessoas disseram, é praticamente tudo, exceto o conteúdo gerado principalmente como resultado de uma compilação.

Não concordo com uma parte da resposta aceita fornecida por @FrustratedWithFormsDesigner menos porque ele defende não colocar no controle de versão as ferramentas necessárias para construir o projeto. Em algum lugar no controle de origem (adjacente ao código que está sendo criado) devem estar os scripts de compilação para compilar o projeto e os scripts que são executados somente a partir de uma linha de comando. Se por ferramentas ele quer dizer, IDEs e editores, eles não devem ser obrigados a construir o projeto, seja qual for. Isso é bom para o desenvolvimento ativo / rápido dos desenvolvedores e a configuração desse tipo de ambiente também pode ser script ou baixada de outra seção do SCM ou de algum tipo de servidor de gerenciamento binário, e a instalação desses IDEs deve ser o mais automatizada possível.

Também discordo do que @Yannis Rizos afirma sobre colocar configurações para ambientes no controle de origem. A razão é que você deve conseguir reconstruir qualquer ambiente à vontade usando nada além de scripts e não é gerenciável sem ter definições de configuração no controle de origem. Também não há histórico de como as configurações de vários ambientes evoluíram sem colocar essas informações no controle de origem. Agora, as configurações do ambiente de produção podem ser confidenciais ou as empresas podem não querer colocá-las no controle de versão; portanto, uma segunda opção ainda é colocá-las no controle de versão para que elas tenham um histórico e conceder acesso limitado a esse repositório.

Mantenha todo o código no controle de versão e todas as configurações e dados do usuário. Para ser específico ao drupal, você precisa colocar tudo no controle de versão, exceto arquivos e settings.php