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


13

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

Respostas:


13

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


7

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


3

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.


Minha empresa é muito parecida com quatro processos de compilação diferentes. Nós precisamos mudar isso.
Brandon

2

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.