Os erros de implantação devem constituir uma falha de compilação?

5

Nosso software usa software interno de implantação por causa da complexidade do produto. Como parte de nosso atual processo de desenvolvimento de QA (não desenvolvimento) (usando mais software interno), compilamos o código, corrigimos os bancos de dados, implantamos o software e executamos um teste de fumaça e, em alguns casos, testes de IU automatizados, antes da compilação é "passado". Estamos nos mudando para o TFS2010 e nos livrando do processo de criação interna e preferiria não adicionar esse processo às construções do TFS.

Quais processos você usa para garantir que a implantação seja bem-sucedida e relatar erros de volta à equipe de desenvolvimento? Uma construção deve ser classificada como uma falha no caso de erros de implantação / tela de fumaça ou falhas de teste de interface do usuário automatizadas?

O TFS encerra o processo de criação quando os arquivos são colocados na pasta-depósito e, em seguida, marca a configuração como OK. Se eu tiver que usar a mesma solução que temos agora, a compilação TFS deve ser estendida para executar todas essas tarefas antes de marcar a compilação como um sucesso ou temos que ter um mecanismo para marcar a compilação como falha após ter sido bem-sucedida anteriormente .

    
por DaveShaw 15.07.2011 / 11:23
fonte

3 respostas

3

Acho que também é possível resolver o problema, se qualquer pessoa que puder fazer check-in for capaz de corrigir "erros na implantação", a configuração normal deverá falhar.

Caso contrário, eu tentaria escolher duas “builds”, a primeira compila o código e executa os testes unitários. A segunda compilação pega a saída da primeira compilação e depois a implantação é verificada. Dessa forma, um programador normal que não funciona no sistema de implantação pode continuar trabalhando se outro programador tiver expandido o aplicativo de uma maneira que precise que os scripts de instalação sejam atualizados.

Falha em uma compilação que, para um problema que poucas pessoas podem resolver, leva a falhas na criação de construções ignoradas.

Você deseja que todos os desenvolvedores parem de trabalhar até que tenham consertado a compilação principal, isso só acontecerá se eles sempre puderem corrigi-la.

    
por 15.07.2011 / 16:39
fonte
1

Se a compilação não puder gerar a saída esperada, ela será quebrada e o mecanismo de compilação precisará notificar quem a quebrou e qualquer outra pessoa que precise saber.

Note que, se alguém pode quebrar um processo que não é relevante para eles, você pode ter dependências mais strongs do que gostaria em sua metodologia de construção e você pode querer investigar isso para se livrar deles.

    
por 15.07.2011 / 12:03
fonte
0

Qualquer erro em qualquer compilação ou teste merece marcar a compilação como uma falha.

Quaisquer erros na implantação podem ou não. Depende do que precisa ser feito, se ocorrer. Geralmente, qualquer erro significa que alguém em algum lugar precisa executar uma ação (corretiva). Então, sim, marcaria a falha na criação. Eu acho que um aviso pode ser ok para se você quiser distinguir entre erros de compilação e implantação, mas eu acho que é uma questão de semântica.

O importante é garantir que as notificações sejam enviadas e, mais importante, lidas. Por exemplo, eu despejo todos os e-mails do nosso servidor de criação diretamente na lixeira, a menos que "falha" ou "falha" esteja em algum lugar no assunto.

    
por 15.07.2011 / 11:43
fonte