Separe 'depuração' e 'release' constrói?

Question

Eu acho que é melhor para lançar a versão do software que seus desenvolvedores realmente testado; Eu, portanto, tendem a eliminar o alvo 'depuração' do projecto / makefile, de modo que só há uma versão que pode ser construído (e testado e depurado, e liberado).

Por uma razão semelhante, eu não uso 'afirmações' (ver também são afirmações sempre ruim? ...).

Uma pessoa não argumentou que a razão para uma versão 'debug' é que é mais fácil de depurar: mas, eu contra-argumentou que você pode eventualmente querer apoiar e depurar tudo o que você lançou, e assim que você precisa para construir uma versão que você pode se depuração necessária ... isso pode significar permitindo símbolos de depuração, e desativando algumas otimizações, mesmo no build 'release'.

Alguém disse que "esta é tal uma má idéia"; é uma política que evoluiu há alguns anos, depois de ter sido queimado por:

• Alguns desenvolvedores testar a sua depuração, mas não lançar versões
• Alguns dos desenvolvedores erros de escrita que aparecem apenas na versão de lançamento
• A empresa está lançando a versão depois de testes inadequados (é sempre totalmente adequado?)
• Ser chamado para depurar a versão

Desde então, tenho visto mais do que uma outra loja de desenvolvimento seguir esta prática (não ou seja, tem de depuração separada e compilações).

Qual é a sua política?

Answer 1

Isso pode ser menor, mas acrescenta-se ao que já foi dito aqui. Uma das vantagens de ter versão de testes QA constrói é que ao longo do tempo o construído em depuração e registrando capacidades do seu software vai avançar, devido às necessidades de desenvolvedores que precisam descobrir por que as coisas vão mal no controle de qualidade.

Quanto mais os desenvolvedores precisam para liberação compilações de depuração, as ferramentas melhores que você terá mais tarde, quando os clientes começam a ter problemas. Claro, não há razão para os desenvolvedores para trabalhar em compilações como parte do ciclo de desenvolvimento.

Além disso, eu não conheço nenhuma empresa de software que tem longa ciclos suficiente para pagar a sobrecarga de comutação QA de depuração para compilações meio período de testes de uma versão. Ter que fazer um ciclo de QA completo é algo que muitas vezes acontece muito raramente.

Answer 2

Tendo depuração e compilações separado é uma boa idéia, porque ele faz o desenvolvimento make mais fácil.

Mas compilações de depuração deve ser para o desenvolvimento, e não para testar. Você testar compilações somente. E você não usar desenvolvedores para testar os constrói, você usa testadores.

É uma política simples que dá o melhor de dois mundos, IMO.

Editar: Em resposta a um comentário, eu acho que é óbvio que a depuração e compilações (pode) gerar código diferente. Pense "-DDEBUG" versus "-DNDEBUG", e "#if defined (DEBUG)", etc.

Por isso, é vital que você testar o código que você acaba de enviar. Se você não gerar código diferente na depuração e compilações, que significa testar duas vezes - independentemente de haver ou não ele é testado pela mesma pessoa

.

símbolos de depuração não são um grande problema, no entanto. Sempre construir com símbolos de depuração, mantenha uma cópia do binário unstripped, mas lançar um binário despojado. Contanto que você marcar cada binário com um número de compilação de alguma forma, você deve sempre ser capaz de identificar o que corresponde binários unstripped para o binário despojado que você tem de depurar ...

Como tirar binários e símbolos de carga em seu depurador de uma fonte externa é dependente de plataforma.

Answer 3

A nossa política é ter desenvolvedores trabalhar em compilações de depuração, mas todos os outros (QA, BAs, vendas, etc.) corre a versão de lançamento. Ontem eu tive que corrigir um bug que só apareceu na compilação de lançamento, era óbvio que estava acontecendo, simplesmente porque ele só apareceu na liberação

É primeiro aqui nesta loja, e eu estive aqui 18 meses ou assim.

Onde as coisas cabeludas é quando a compilação de lançamento faz coisas diferentes para a compilação de depuração -. Sim, eu fui para o inferno e vi isso em alguns muito antigo código de produção, muito ropy

Eu não vejo nenhuma razão pela qual não ter ambos, se a única diferença entre as configurações são símbolos de depuração e otimizações.

Answer 4

então você precisa para construir uma versão que você pode se depuração necessária ... este pode significar permitindo símbolos de depuração, e desativando algumas otimizações, mesmo em a 'libertação' de construção.

Ummm ... parece que você está fazendo uma compilação de depuração para mim ... certo?

A parte onde você errou é a seguinte declaração:

Eu acho que é melhor para liberar o versão do software que o seu desenvolvedores realmente testado

desenvolvedores não o código de teste. código de testes de teste.

Seus testes de unidade deve testar todas configurações de compilação. Não faça seu trabalho desenvolvedores com uma mão amarrada atrás das costas - deixá-los usar todas as ferramentas de depuração que têm à disposição lá. A compilação de depuração é uma delas.

No que diz respeito afirma: o uso de afirmações depende muito se ou não você programar por contrato. Se o fizer, então afirmações simplesmente verificar o contrato em uma compilação de depuração.

Answer 5

De acordo com a minha resposta no fio ligada, também usamos a mesma compilação para depuração e liberação por razões muito semelhantes. Os ganhos de desempenho de 10% -20% do optimiser tendem a ser muito menor quando comparado com as optimizações manual no nível de algoritmo. A única construção remove muitos erros potenciais. Especificamente;

• variáveis ??uninitialised e pequenas sobrecargas de buffer pode acabar com resultados muito diferentes em depuração e libertação optimizada constrói.

• Mesmo com a informação simbólica disponíveis, depurando uma versão otimizada pode ser difícil, pois o objeto não coincide com a fonte, por exemplo, variáveis ??podem ter sido optimizado para fora e de código pode ter sido re-arranjadas. Assim bugs reportados na versão testada constrói pode ser mais difícil e, portanto, demorado, de rastrear.

Tendo comparado unoptimised e otimizado constrói sob testes de regressão automatizados, os ganhos de desempenho fornecidos pela otimização não fornecem valor adicional suficiente para ter duas versões no meu caso. É interessante notar que o software que desenvolvo é muito CPU com fome (por exemplo, criação e manipulação de modelos de superfície grandes).

Answer 6

Ao desenvolver com Java, eu odeio versões não-depuração. Quando uma exceção é lançada, você não obter informações de linha que torna difícil ou mesmo impossível de rastrear bugs para baixo. Além disso, a diferença de tempo de execução entre depuração e não-depuração é de cerca de 5% com Java 5 ou mais tarde, de modo que este é realmente nenhum problema e com discos rígidos de hoje, o tamanho não importa mais.

No lado positivo usando versões de depuração:

• rastreamentos de pilha contém todas as informações que você precisa
• As variáveis ??podem ser examinados
• Se você tem um problema na produção, você pode simplesmente anexar ao processo correr sem ter que parar o servidor primeira a instalar uma versão de depuração.
• Você não vai ser pego por erros de otimização inteligentes
• A construção é mais simples (apenas um artefato)

Answer 7

Os desenvolvedores trabalhar com compilações de depuração, QA e todo mundo usa a versão de lançamento, que chamamos de "produção". A principal vantagem disso é que, na compilação de depuração, podemos adicionar um monte de código extra e afirmações. Alguns objetos contêm peças extra de informações que não têm uso, exceto quando visualizar o código no depurador. Alguns objetos validar-se periodicamente para se certificar de que todas as informações do estado é consistente. Essas coisas fazem a versão de depuração muito mais lento, mas eles nos ajudaram a encontrar sem fim de erros que teriam sido um inferno para encontrar na compilação de produção.

Como eu disse, toda a nossa produção QA e usos de desempenho testando constrói, e nós ocasionalmente deparar com problemas que aparecem na produção, mas não em depuração. Mas eles são relativamente raros, e como um desenvolvedor, as vantagens de depurar uma compilação de depuração em vez de uma compilação de produção superam esse problema.

Answer 8

Eu acho que depende do tamanho do projeto e que tipo de sistema de compilação e teste que você está usando.

Se você tem um sistema de compilação automatizada no lugar, e é simples de unidade de corrida e testes funcionais em uma determinada construção, então você deve nunca ter quaisquer problemas com vários tipos de compilação.

Answer 9

Eu sempre subscreveu o "Navio que você depurar, para que você pode depurar o que você enviar" abordagem, por todas as razões que você lista em sua pergunta.

Answer 10

Na minha opinião esta discussão faltando um ponto muito importante:

É realmente depende de que tipo de projeto que é!

Se você criar um nativo (C / C ++) projetar você vai de fato ser forçado a criar compilações de depuração, simplesmente porque otimizações do compilador pode fazer a depuração quase impossível em alguns casos.

Se você criar aplicações web que você pode e não deseja simplesmente tem um construir (embora "construção" é bastante enganadora para algumas aplicações web) que pode activar o registo de recursos durante a execução.

Embora um projeto nativo C ++ e um aplicativo de web PHP não são, obviamente, todos os tipos de projeto que existem, espero que meu ponto atravessaram.

P.S .: Ao desenvolver para C #, você corre em um caso fronteira desde embora usando uma depuração desativa construção otimizações do compilador, na minha experiência você não vai correr em quase tanto diferenças como com C ++

Answer 11

aqui nós desenvolvemos no modo de depuração e fazer tudo a unidade de teste no modo de versão. nós somos uma pequena loja com apenas alguns (menos de 12) aplicação de suporte que vão do clássico ASP, ASP.Net, VB.Net e C #. Nós também temos uma pessoa dedicada para lidar com todos os testes, problemas depurado são jogados de volta para os desenvolvedores.

Answer 12

Nós sempre construir ambos, nunca sequer considerada não fazê-lo. Permitindo opções de depuração aumenta o tamanho do código e desempenho desacelera, possivelmente, não um problema com o seu tipo de software ao testar, mas o que se o cliente está a executar seu código mais 5 outros aplicativos ...

Os problemas com o teste pode ser resolvido através da utilização de testes automatizados para que você está compilação de lançamento pode ser facilmente testado quando você acha que está pronto para liberar. O fracasso de seus desenvolvedores ou empresa para adequadamente versão de teste baseia-se não é uma falha na idéia de libertação e compilações de depuração, mas em seus desenvolvedores e ou empresa.

Em seu último ponto, eu nunca foram chamados para depurar uma compilação de lançamento, apenas para corrigi-lo ...

Answer 13

É uma troca. Dado que os ciclos de CPU são baratos e ficando mais baratos, enquanto os ciclos humanos permanecem caros, faz muito sentido de manter apenas uma única versão de um programa grande e complexo -. A depuração versão (empena)

Sempre usando afirmações sempre é uma política mais seguro do que não usá-los. Se a produção de versões de depuração e comunicado separado, reative o que quer símbolos #defined que você precisa para garantir que as afirmações são habilitados na versão de lançamento também.

Answer 14

Eu acho que a troca é simples: sim, com apenas uma compilação de lançamento, você realmente testar o que realmente está sendo enviado. Por outro lado, você paga um preço em termos de facilidade de depuração para seus desenvolvedores e / ou desempenho para o usuário, por isso é até você para verificar ambos os casos.

Na maioria médio para projetos de grande porte, facilidade de depuração irá garantir um melhor produto para seus usuários no final.

Answer 15

Veja este Qual é a sua opinião programação mais controverso?

Citação:

Opinião: Nunca, jamais, ter diferentes código entre "debug" e "release" constrói

A principal razão é que a liberação código quase nunca é testado. Melhor ter o mesmo código em execução em teste como é na natureza.

Answer 16

Ao remover o "alvo debug", você está forçando os desenvolvedores a depuração no versão de lançamento do software. O que isso significa probaly em prática é duas coisas:

1) "compilações" terá otimizações deficientes (desenvolvedores otherwised não pode usar um depurador)

2) Não constrói terá macros especiais pré-processador alterando a sua execução.

Então, o que você vai realmente fazer é mesclar as configurações de libertação e de depuração em vez de eliminar apenas o modo "debug".

Eu pessoalmente tenho feito isso com o desenvolvimento iOS sem maus efeitos. A quantidade de tempo gasto em nosso código escrito é menos de 1% do que realmente está acontecendo, então as otimizações não eram importantes contribuintes. Neste caso, eles realmente se parecem causar um aumento nos erros, mas mesmo se não o fizessem, a idéia de testar um caminho, em seguida, dando a QA com diferentes introduz código apenas mais um fator a considerar com as questões.

Por outro lado, há casos em que as otimizações são necessários, onde eles são úteis, e mesmo onde há tempo suficiente para testar ambos. Normalmente, as mudanças entre depuração e liberação são tão pequenas que não causa qualquer pessoa quaisquer problemas.

Answer 17

Se você tem um grupo QA real, que pode ser contado para testar completamente a coisa, eu diria que faz compilações de depuração até chegar perto do lançamento, e, em seguida, certifique-se um ciclo de QA completo é feito na mesma compilação que está acontecendo fora da porta.

Embora em pelo menos um caso lançamos algo que ainda tinha algum código de depuração nele. A única consequência foi que correu um pouco mais lento e os arquivos de log foram grande nada.

Answer 18

Na minha empresa, temos tanto Debug e Release. - Os desenvolvedores usam a versão de depuração para encontrar corretamente e erros de correção. -. Estamos usando TDD e por isso temos um conjunto de testes grande que corremos no nosso servidor que testa duas configurações de compilação de depuração e de lançamento, bem como 64/32 constrói temos assim

Então, se usando a configuração "debug" ajuda a um desenvolvedor para encontrar um bug mais rápido não há nenhuma razão para não usá-lo - quando o código vai para o servidor (a ser mais testado) ou revisto usamos a um "Release" .

Answer 19

Eu aprendi a construir a versão com ficheiros.PDB há muito tempo para que eu pudesse depurar a versão de lançamento. O que um monte de programadores tendem a esquecer é que, quando você executar a versão de depuração, com todas as otimizações desligado, você está depurando um programa completamente diferente. Ele pode se comportar como a compilação de lançamento (em sua maior parte), mas ainda é um programa diferente do que a compilação de lançamento.

Além disso, a depuração do compilação de lançamento não é tão difícil. E se você receber um despejo de memória, você tem que ser capaz de fazê-lo de qualquer maneira.