Como o código no controle de versão deve ser armazenado?

19

Desenvolvedor amigável ? para que o programador possa pegar rapidamente as últimas e poder executar a partir de seu editor sem fazer muitas alterações? (como arquivos de configuração apontando para dev DB..etc)

ou

Deve ser amigável à produção ? A fonte deve estar de uma maneira fácil de implantar no ambiente de produção e, quando o desenvolvedor receber as últimas, ele deverá realizar alterações conforme suas necessidades de desenvolvimento.

version-control

— Pavan GR
fonte

56

Por que escolher ? Deveriam ser os dois.

Seu ambiente de desenvolvimento deve ser configurado para que seja tão fácil quanto fazer uma verificação geral, abrir, criar, executar, depurar (por exemplo: nenhum caminho absoluto!). Você pode fazer isso facilmente com diretivas de compilação, classe de configuração + injeção de dependência ou mesmo truques como o perso.config no ASP.NET

Seu script de construção automatizado deve ser personalizado o suficiente para cuidar de configurações específicas de produção, limpeza, empacotamento etc.

O que é o perso.config? Um google rápido não me ajudou.

— Tim Murphy

1

No arquivo de configuração do aplicativo .NET, você pode fazer referência a outro arquivo de configuração do aplicativo que, quando encontrado, substituirá as configurações especificadas. Portanto, você pode criar um arquivo dev.config que substitua coisas como cadeias de conexão e outras coisas e exclua-o dos repositórios.

5

+1 - os desenvolvedores não devem pensar em obter a fonte correta. Além disso, a implantação da produção não deve ocorrer diretamente do controle de origem, mas com peças adequadamente construídas, testadas e rastreáveis . Esse processo deve ser totalmente automatizado.

9

Quando é um projeto de código aberto em que as pessoas devem contribuir, eu certamente optaria por ser amigável ao desenvolvedor.

Minha maior aversão a projetos de código aberto é que, muito raramente, o repositório contém todas as dependências necessárias para criar o código (às vezes por razões práticas ou legais), mas quando não o fazem - alguns nem se dão ao trabalho de dizer quais dependências você precisa, ou mais importante, de qual versão deles você precisa. (e de preferência de onde obtê-los)

Às vezes, você pode passar mais de meio dia buscando e compilando vários outros projetos para criar o projeto que deseja.

Obviamente, isso é realmente relevante apenas para o desenvolvimento no Windows.

— Mark H
fonte

1

Isso me incomoda demais. Você ainda o encontra no OSS muito conhecido.

— Tim Murphy

1

Existem sistemas que aliviam esse problema buscando automaticamente dependências. Por exemplo, Apache Maven, Ivy ou scons.

— Novelas

4

Ambos, mas depende da frequência com que você faz sua produção. Para muitos aplicativos personalizados, as implantações são feitas manualmente e localmente. Por outro lado, o desenvolvedor compromete constantemente o código, não importa quão pequeno ou grande o projeto seja. Na minha opinião, acho que é mais importante garantir que o desenvolvedor possa usar o controle de versão corretamente, facilitando assim a vida deles, para que eles tenham tempo para se concentrar no código, em vez de encontrar o caminho através do controle de versão.

— tia
fonte

As implantações de produção não devem ser um problema se você usar um mecanismo de implantação contínua para criar.

1

Deve ser amigável à produção, caso contrário, é problemático manter construções automatizadas.

— dente afiado
fonte

8

Por quê? Um script de construção automatizado pode fazer todas as traduções necessárias para reestruturar a fonte em um formulário implementável. Nunca incomode as pessoas com algo que a automação possa resolver.

— Joeri Sebrechts 10/10/10

1

Eu sou a favor da redução do atrito, para que seja mais fácil fazer o trabalho, mas você também precisa levar em consideração os modos de falha.

Se a versão do repositório de origem estiver sempre configurada para uso em produção, qual é o resultado de um desenvolvedor não reconfigurar antes de executar o sistema? Um desenvolvedor executando o código na produção.

Independentemente de haver outros obstáculos no caminho do desenvolvedor fazer alterações aleatórias na produção, criar um modo de falha que incentive isso a acontecer parece perigoso.

Sugiro que os valores padrão incluídos no código confirmado sejam sempre seguros . Verifique também os arquivos de configuração de produção no controle de origem, se quiser - eu quase sempre faço -, mas mantenha-os em algum lugar "inoperante".

— Bevan
fonte

0

Tendo a me esforçar para favorecer a produção. Mantém suas construções limpas e impede que configurações estranhas entrem em produção.

— Mike Clark
fonte

0

Definitivamente amigável para desenvolvedores, com scripts para automatizar alterações de controle de qualidade e produção.

— William Payne
fonte

-1

Por que não ter uma ramificação (dependendo do controle de versão que você usa - eu uso o Git) para o código implementável e outro para a versão pronta para desenvolvedor? Isso soa muito melhor e não é tão difícil de configurar.

Você pode trabalhar e confirmar suas alterações e depois mesclá-las na versão implantável.

— Ricardo Souza
fonte

Como os ramos de vida longa são caros de gerenciar e tendem a ser difíceis de fundir. Você precisaria se lembrar de fazer todas as alterações nos dois ramos. Muito melhor tornar as duas versões iguais e / ou ter um script para gerar o artefato implementável a partir do código pronto para desenvolvedor.

— bdsl