Versão de compilação versus compilação noturna

Uma solução típica é ter um build de IC (integração contínua) em execução em um servidor de build: ele analisará o código-fonte, fará build (em depuração) e executará testes, medirá a cobertura do teste etc.

Agora, outro tipo de compilação geralmente conhecido é "Compilação noturna": faça coisas lentas, como criar documentos de código, criar um pacote de instalação, implantar no ambiente de teste e executar testes automáticos (fumaça ou aceitação) no ambiente de teste etc.

Agora, a pergunta:

• É melhor ter um terceiro "Release build" separado como release build?
• Ou "Build nightly" no modo release e usa-o como release?

O que você está usando na sua empresa?

(A compilação do release também deve adicionar algum tipo de tag ao controle de origem da versão potencial do produto.)

Um caso para ter a versão compilada igual à versão noturna é: você deseja testar exatamente as mesmas coisas que você libera . Você não deseja descobrir erros na produção que já poderiam ter sido detectados no teste do desenvolvedor.

A diferença entre o lançamento e as versões noturnas:

• a criação noturna é executada automaticamente, bem, todas as noites, enquanto a versão deve ser executada manualmente em certos momentos
• idealmente, a build de liberação deve marcar / ramificar o código-fonte e possivelmente implantar o (s) artefato (s) de build em um repositório central (por exemplo, ao usar o Maven)

Essas diferenças são, na prática, algumas opções extras na maioria dos sistemas de gerenciamento de build que eu conheço. Para minimizar a chance de erros humanos, eles podem ser salvos, por exemplo, em um arquivo de lote / script que utiliza apenas os parâmetros necessários (e os valida).

Bem, eu gostaria que a versão fosse o mais próxima possível da noite! Idealmente exatamente o mesmo, mas com uma etiqueta.

O problema é que, se a sua versão compilar e todas as noites não for a mesma, há uma chance de que o que for diferente possa mascarar um problema (ou dificultar o rastreamento de um deles).

Eu teria um único processo de compilação, que criaria tudo a cada check-in executado pelo serviço de IC. Isso seria depurar e compilar versões.

Ter dois ou três processos separados é apenas pedir para que eles comecem a mudar aleatoriamente sem serem documentados, e não demorará muito para que alguém se veja tendo que fazer 15 etapas para cada versão em potencial para prepará-la para sair pela porta.

Uma coisa que estou interessado em fazer é colocar a compilação noturna no modo de lançamento, em vez do modo de depuração. Com estruturas de log como log4net substituindo System.Diagnostics.Debug, as principais diferenças entre os modos Release e Debug são a vida útil do objeto e as otimizações de código.

A menos que você esteja anexando um depurador à sua criação noturna, sugiro que faça isso também.

O processo que seguimos é que a compilação noturna é executada todas as noites e, se funcionar, podemos implantar a mesma compilação em nossos outros servidores (sem reconstrução, basta pegar os instaladores empacotados e executá-los). Se tivermos um problema com a compilação noturna, verificamos as alterações nela em uma ramificação e executamos uma compilação 'noturna' nessa ramificação durante o dia. Os testes podem ser executados novamente.