O que artefatos para guardar para uma compilação noturno?

StackOverflow https://stackoverflow.com/questions/230595

Pergunta

Suponha que eu configurar um automática nightly build . O que artefatos da compilação devo salvar?

Por exemplo:

  • código fonte de entrada
  • binários de saída

Além disso, quanto tempo devo salvá-los, e onde?

Faça a sua mudança respostas se eu fizer integração contínua?

Foi útil?

Solução

Aqui estão alguns artefatos / informação que eu estou acostumado a mantê-la em cada compilação:

  • O nome da marca do instantâneo você está construindo (tag e fazer um check-out limpo antes você constrói)
  • Os scripts de construção themselfs ou seu número de versão (se você tratá-los como um projeto separado com seu próprio controle de versão)
  • A saída do script de construção: logs e produto final
  • Um instantâneo do ambiente:
    • versão do compilador
    • Versão ferramenta de construção
    • bibliotecas e DLL / libs versões
    • versão de banco de dados (cliente e servidor)
    • versão ide
    • versão interpretador de script
    • versão do SO
    • versão de controle de origem (cliente e servidor)
    • versões de outros instrumentos utilizados no processo e tudo o mais que pode influenciar o conteúdo de seus produtos de construção. Eu costumo fazer isso com um script que consulta todas essas informações e registros para um arquivo de texto que deve ser armazenado com os outros artefatos de construção.

Pergunte a si mesmo esta pergunta: "se algo destrói totalmente o meu ambiente de construção / desenvolvimento que informação que eu preciso para criar um novo para que eu possa refazer a minha build # 6547 e acabar com o mesmo resultado cheguei pela primeira vez? "

A sua resposta é o que você deve manter em cada construção e vai ser um subconjunto ou superconjunto das coisas que eu já mencionados.

Você pode armazenar tudo em sua SCM (eu recomendo um repositório separado), mas neste caso sua pergunta sobre quanto tempo você deve manter os itens perde sentido. Ou você deve armazená-lo para pastas zipadas ou gravar um CD / DVD com o resultado de construção e artefatos. Seja qual você escolher, ter uma cópia de segurança.

Você deve armazená-los, desde que você pode precisar deles. Quanto tempo, vai depender do seu ritmo equipe de desenvolvimento e o seu ciclo de lançamento.

E não, eu não acho que isso muda se você fizer a integração contínua.

Outras dicas

Você não deve salvar nada por causa de salvá-lo. você deve salvá-lo porque você precisa dele (ou seja, usos QA constrói noite para teste). Em que ponto, "quanto tempo para salvá-lo" torna-se no entanto longo QA quer que eles.

i não iria "salvar" o código-fonte tanto como tag / rotulá-la. Eu não sei o controle da fonte que você está usando, mas a marcação é trivial (desempenho e espaço em disco) para qualquer sistema de controle de origem de qualidade. Uma vez que a sua construção é marcado, a menos que você precisa binários, não há realmente nenhum benefício para apenas tê-los por perto porque você pode simplesmente re-compilação quando necessário a partir da fonte.

ferramentas mais CI deixá-lo tag em cada compilação bem-sucedida. Isso pode tornar-se problemática para alguns sistemas, como você pode facilmente ter 100+ etiquetas por dia. Para esses casos eu ainda recomendo executar uma compilação de todas as noites e única marcação que.

Esta não é uma resposta directa à sua pergunta, mas não se esqueça de controle de versão a configuração nightly build si. Quando a estrutura do projeto muda, você pode ter que alterar o processo de construção, que vai quebrar mais velho constrói a partir desse ponto.

Além dos binários como todos os outros mencionados Eu recomendaria a criação de um símbolo servidor e uma href="http://msdn.microsoft.com/en-us/library/ms680641.aspx" rel="nofollow noreferrer"> servidor e ter certeza que você obtenha as informações corretas para fora e para aqueles. Vai ajudar na depuração tremendamente.

Nós salvar os binários, despojado e unstripped (por isso temos exatamente o mesmo binário, uma vez com e uma vez sem símbolos de depuração). Além disso nós construímos tudo duas vezes, uma vez com saída de depuração habilitado e uma vez sem (novamente, despojado e unstripped, assim que cada resultado de construção em 4 binários). A construção é armazenado em um diretório de acordo com o número de revisão do SVN. Dessa forma, podemos sempre manter a fonte do repositório SVN, basta verificar este muito revisão (dessa forma que a fonte seja arquivado também).

A uma surpreendente que eu aprendi sobre recentemente:. Se você está em um ambiente que pode ser auditado você quer salvar toda a saída de sua construção, a saída do script, a saída do compilador, etc

Essa é a única maneira que você pode verificar suas configurações de compilador, etapas de construção, etc.

Além disso, quanto tempo para salvá-los para, e onde salvá-los?

Save-los até que você sabe que compilação não estará indo para a produção, iow, enquanto você tem os bits compilados ao redor.

Um lugar lógico para salvá-los é o seu sistema de SCM. Outra opção é usar uma ferramenta que irá automaticamente guardá-las para você, como AnthillPro e sua laia.

Estamos fazendo algo perto de desenvolvimento "embedded" aqui, e posso dizer-lhe o que nós salvar:

  • o número de revisão do SVN e timestamp, bem como a máquina foi construída sobre e por quem (também queimaram nos binários de compilação)
  • um registro compilação completa, mostrando se era uma compilação completa / incremental, qualquer saída interessante (STDERR) os dados de fermento em instrumentos produzidos, uma lista de arquivos compilados e quaisquer avisos do compilador (Isso comprime muito bem, texto ser)
  • os binários reais (para qualquer lugar de 1-8 configurações de compilação)
  • arquivos produzidos como um efeito colateral de ligar: um arquivo de comando vinculador, mapa de endereços, e uma espécie de "manifesto" arquivo indicando o que foi queimado nos binários finais (CRC e tamanho para cada), bem como o banco de dados de depuração (PDB equivalente)

Nós também enviar para fora o resultado da execução de algumas ferramentas sobre os arquivos "efeito colateral" para usuários interessados. Nós realmente não arquivar estes desde que podemos reproduzi-los mais tarde, mas estes relatórios incluem:

  • total eo delta do tamanho do sistema de arquivos, discriminadas por tipo de arquivo e / ou diretório
  • total e o delta de tamanhos de secção de código (.text, .data, .rodata, .bss, .sinit, etc)

Quando temos testes de unidade ou testes funcionais (por exemplo, testes de fumo) em execução, os resultados aparecem no log de compilação.

Não joguei fora nada ainda -. Dado, nossa meta constrói geralmente acabam em ~ 16 ou 32 MiB por configuração, e eles são bastante compressível

Nós fazemos manter cópias não comprimidas dos binários em torno de uma semana para facilidade de acesso; depois que manter apenas a versão levemente compactado. Sobre uma vez por mês temos um script que extrai todos .zip que o processo de compilação produz e 7-fecha um mês inteiro de saídas construir juntos (que tira vantagem de ter apenas pequenas diferenças por acumulação).

Um dia médio pode ter uma ou duas dúzias constrói por projeto ... O buildserver acorda a cada 5 minutos para verificar se há diferenças relevantes e constrói. A .7z completo em um grande projeto muito ativo durante um mês pode ser 7-10GiB, mas é certamente acessível.

Para a maior parte, temos sido capazes de diagnosticar tudo dessa forma. Ocasionalmente há um soluço na buildsystem e um arquivo não é realmente uma revisão que é suposto ser quando uma compilação acontece, mas não há evidências normalmente bastante deste nos logs. Às vezes temos que desenterrar uma ferramenta que entendem esse formato de banco de dados de depuração e alimentá-lo alguns endereços para diagnosticar um acidente (temos stackdumps automáticas incorporadas ao produto). Mas, geralmente, toda a informação necessária está lá.

Não tivemos a rachar os arquivos .7z ainda, de mencionar. Mas nós temos a informação lá, e eu tenho algumas idéias interessantes sobre como pedaços de minas de dados úteis a partir dele.

Salvar o que não pode ser reproduzido facilmente. Eu trabalho em FPGAs, onde apenas a equipe FPGA tem as ferramentas e alguns núcleos (bibliotecas) do projeto estão licenciados para compilar em uma única máquina. Por isso, salvar os fluxos de bits de saída. Mas tentar vê-los uns sobre os outros, em vez de com um / hora / versão carimbo de data.

Salvar como no check-in para controle de código fonte ou apenas no disco? Salvar nada para controle de código fonte. Todos os arquivos derivados devem ser visíveis no sistema de arquivo e disponíveis para os desenvolvedores. Não check-in binários, código gerado a partir de arquivos XML, resumos de mensagem etc. Um passo embalagem separada fará com que esses produtos finais disponíveis. Como você tem o número mudança que você pode sempre reproduzir a construção, se necessário assumindo, claro, tudo o que você precisa fazer uma compilação é completamente na árvore e está disponível para todas as compilações de sincronização.

Gostaria de salvar seus binários construídos exatamente para contanto que eles têm a chance de entrar em produção ou ser usado por alguma outra equipe (como um grupo QA). Uma vez que algo tem produção de esquerda, o que você faz com ele pode variar muito. Para um monte de equipes, eles vão manter apenas sua recente volta compilação anterior mais (para rollback) e outra forma de descarte sua cria.

Outros têm requisitos regulamentares para manter qualquer coisa que entrou em produção em torno de tanto tempo quanto sete anos (bancos). Se você é uma empresa de produtos, eu ficaria em torno de qualquer binário um cliente pode ter instalado no caso de um cara de suporte técnico quer instalar a mesma versão.

Não afiliado a StackOverflow
scroll top