Em que ponto você deve mudar para liberar a compilação?

Uma das práticas estabelecidas na Entrega Contínua de Jez Humble é que você deve criar um pacote e liberá-lo para cada ambiente no qual implantar, para que a implantação e os artefatos tenham sido testados várias vezes antes de iniciar a produção.

Eu apoio totalmente essa ideia.

Por outro lado, as compilações no modo de depuração que fornecem rastreamentos de pilha com números de linha são incrivelmente úteis em ambientes de teste, assim como a capacidade de depuração remota. Mas você deseja enviar uma compilação de versão para produção.

Então, para as pessoas que seguem o primeiro princípio, em que momento você alterna da depuração para a liberação das compilações?

É antes da primeira implantação em um ambiente de teste, calculando que vale a pena pagar o custo de perder o modo de depuração para garantir que você esteja testando o candidato real à versão antecipada? Ou você constrói novamente em algum momento do processo de promoção, imaginando que confiará no processo de construção sobre o software? Ou você simplesmente estraga tudo e implanta versões de depuração na produção?

Nota: Eu sei que isso realmente não se aplica a linguagens interpretadas, porque geralmente você pode pressionar o switch na configuração, em vez de fazê-lo no momento da construção.

Então, para as pessoas que seguem o primeiro princípio, em que momento você alterna da depuração para a liberação das compilações?

Mudamos cedo, quando o código fonte obteve um número de versão e foi empurrado para a fila de compilação do Debian. Estamos na situação de sorte de criar software científico com entradas e saídas bem especificadas e pouca interação do sistema; portanto, o custo de reproduzir uma situação de erro é bastante baixo.

Essa também é minha resposta geral: o ponto de alterar as compilações depende principalmente dos custos de reprodução de erros. Se estes forem muito altos, eu enviaria versões de depuração para testar os clientes. Embora isso acarrete o risco de falhas na construção da produção, isso ainda pode ser mais barato do que passar semanas na reprodução de casos de teste.

Então, para as pessoas que seguem o primeiro princípio, em que momento você alterna da depuração para a liberação das compilações?

Assim que entramos no controle de qualidade, passamos a liberar builds. Mas sempre que criamos uma versão, nosso processo de compilação também cria uma versão de depuração das DLLs. Isso nos permite soltar rapidamente as DLLs de depuração no ambiente de controle de qualidade e obter informações adicionais, se necessário.

As versões de lançamento e depuração das DLLs são copiadas e mantidas por vários anos.

Em nosso ambiente, o código é implantado em muitos sites. E, portanto, deve haver um contexto diferente aplicado a cada instância da implantação. Geralmente, nós o implantamos em lugares importantes "de menor risco" e vemos a experiência.

Essa implantação ainda está em produção , portanto, este não é o modo 'debug'. Mas também pressupõe que o teste seja feito bem.

Obviamente, com o modo de depuração desativado, a depuração rápida do código (no local) pode ser difícil. Mas, se a versão falhar, a produção volta para a versão anterior.

No entanto, tentamos manter ou criar um ambiente idêntico, que pode reproduzir esse ambiente para testar novamente. (Eu sei que isso não é sempre trivial de se fazer), mas tudo o que precisamos às vezes é reproduzir as transações / entradas.

A questão é: quanto mais a tentação, o modo de depuração, não deve estar em produção. No entanto, não vou dizer que isso é uma regra.

Outra coisa é que a versão ainda é chamada de teste até que tenha estabelecido (executando por um tempo significativo) outras premissas ainda não a aceitam.

Existem outras práticas para garantir que o processo de compilação não seja totalmente defeituoso. Veja isto: Maneiras simples de melhorar a qualidade da versão no ambiente RAD

Temos nossas máquinas de desenvolvedor configuradas para criar compilações de depuração. Porém, quando os desenvolvedores confirmam o código, um pacote de implantação é criado em nosso ambiente de integração contínua (TeamCity) e criado para a liberação. Portanto, sempre que decidimos implantar no controle de qualidade, pegamos o pacote de implantação mais recente do servidor de CI e o empurramos para fora, para que seja sempre liberado, a menos que esteja em uma máquina de desenvolvimento.

BTW, para alguns idiomas, mesmo ao criar para lançamento, você ainda pode criar símbolos de depuração. No .NET, por exemplo, há uma configuração "pdb-only" que permite otimizações, mas ainda cria arquivos de depuração. Obviamente, a depuração de uma versão de lançamento é mais complicada, pois não é equivalente a linha por linha, mas ainda pode ser útil em uma pitada.