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

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

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.

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.

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.

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.

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

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".

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.

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

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.