Como e por que eu criar um C # máquina de compilação? [fechadas]

https://stackoverflow.com/questions/616149

03-07-2019
|

Pergunta

Eu estou trabalhando com um pequeno (4 pessoas) equipe de desenvolvimento em um projeto C #. Eu já propôs a criação de uma máquina de construção que vai fazer nightly builds e testes do projeto, porque eu entendo que isso é uma coisa boa. O problema é que não temos um monte de orçamento aqui, então eu tenho que justificar a despesa para os poderes constituídos. Então, eu quero saber:

Que tipo de ferramentas / licenças vou precisar? Agora, usamos Visual Studio e Montagem inteligente para construir, e Perforce para controle de origem. Vou precisar de algo mais, ou há um equivalente de um trabalho cron para a execução de scripts automatizados?

O que, exatamente, isso vai me pegar, que não seja uma indicação de uma compilação quebrado? Devo configurar projetos de teste nesta solução (arquivo sln) que será executado por esses scripts, para que eu possa ter funções específicas testado? Temos, no momento, dois desses testes, porque não tivemos o tempo (ou, francamente, a experiência) para fazer bons testes de unidade.

Que tipo de hardware que eu preciso para isso?

Uma vez que a construção foi concluída e testada, é uma prática comum de colocar esse acúmulo em um site FTP ou ter alguma outra forma para acesso interno? A ideia é que esta máquina marcas o construção, e nós todos vão para ele, mas pode fazer compilações de depuração, se for preciso.

Quantas vezes devemos fazer esse tipo de construção?

Como o espaço gerenciado? Se fizermos nightly builds, devemos manter em torno de todo o velho constrói, ou começar a vala-los após cerca de uma semana ou assim?

É outra coisa lá qualquer coisa que eu não estou vendo aqui?

Eu percebo que este é um tema muito grande, e eu estou apenas começando. Eu não poderia encontrar uma duplicata desta questão aqui, e se há um livro lá fora, eu deveria apenas obter, por favor me avise.

EDIT: Eu finalmente tenho que trabalhar! Hudson é completamente fantástico, e FxCop está mostrando que algumas características que pensávamos foram implementadas foram realmente incompleta. Nós também tivemos que alterar o tipo de instalação a partir do Old-E-Busted vdproj para New Hotness WiX.

Basicamente, para aqueles que estão prestando atenção, se você pode executar a sua construção a partir da linha de comando, então você pode colocá-lo em Hudson. Fazendo a construção correr a partir da linha de comando via MSBuild é um exercício útil em si mesmo, porque força as suas ferramentas para ser atual.

Solução

Update: Jenkins é o até a versão mais data de Hudson. Todos devem estar usando Jenkins agora. Eu vou estar atualizando as ligações em conformidade.

Hudson é gratuito e extremamente fácil de configurar e facilmente executado em uma máquina virtual.

Em parte de um velho post meu:

Nós usá-lo para

Serviços de implantar o Windows
serviços Web Deploy
Executar MSTests e exibição tanta informação quanto quaisquer testes JUnit
faixa de manter baixo, med, tarefas de alta
avisos trendgraph e erros

Aqui estão algumas das construído em material .net que Hudson suportes

Além disso, Deus me livre que você está usando segura fonte visual, ele suporta que tão bem . Eu recomendo que você dê uma olhada Redsolo de artigo sobre a construção de projetos .net usando Hudson

Suas perguntas

Q : Que tipo de ferramentas / licenças vou precisar? Agora, usamos Visual Studio e Montagem inteligente para construir, e Perforce para controle de origem. Vou precisar de algo mais, ou há um equivalente de um trabalho cron para a execução de scripts automatizados?
A: Eu só visual studio instalado em uma nova cópia de uma máquina virtual em execução um novo, remendado, instale de um sistema operacional de servidor windows. Então você precisa de licenças para lidar com isso. Hudson irá instalar-se como um serviço do Windows e executar na porta 8080 e você vai configurar quantas vezes você quiser que a varredura de seu repositório de código para o código atualizado, ou você pode dizer que para construir em um determinado momento. Todos configurável através do browser.
Q: O que, exatamente, isso vai me pegar, que não seja uma indicação de uma compilação quebrado? Devo configurar projetos de teste nesta solução (arquivo sln) que será executado por esses scripts, para que eu possa ter funções específicas testado? Temos, no momento, dois desses testes, porque não tivemos o tempo (ou, francamente, a experiência) para fazer bons testes de unidade.

A: Você receberá um e-mail sobre a primeira vez que uma construção falhar, ou se torna instável. A construção é instável se um teste de unidade falhar ou pode ser marcada instável por qualquer número de critérios que você definir. Quando um teste de unidade ou construção falhar você será enviado por email e ele vai lhe dizer onde, como e por que ele falhou. Com a minha configuração, obtemos:
- lista de todos os commits desde a última compilação de trabalho
- comprometer notas desses commits
- lista de arquivos alterados nos commits
- saída do console da própria construção, mostrando o fracasso de erro ou de teste
Q:? Que tipo de hardware que eu preciso para este

A: A VM será suficiente
Q: Uma vez que a construção foi concluída e testada, é uma prática comum de colocar esse acúmulo em um site FTP ou ter alguma outra forma para acesso interno? A idéia é que esta máquina faz a compilação, e vão todos para ele, mas pode fazer compilações de depuração, se for preciso.

A: Hudson pode fazer o que quiser com ele, que inclui ID'ing-lo através do hash MD5, carregá-lo, copiá-lo, arquivá-lo, etc. Ele faz isso automaticamente e fornece-lhe com uma longa história de execução de artefatos de construção.
Q:? Quantas vezes devemos fazer esse tipo de construção

A: Nós temos a nossa pesquisa SVN cada hora, procurando alterações de código, em seguida, executando uma compilação. Por noite é ok, mas um pouco inútil IMO desde que você trabalhou ontem não vai ser fresco em sua mente na parte da manhã quando você entrar.
Q: Como é espaço gerenciado? Se fizermos constrói todas as noites, devemos manter em torno de todo o velho constrói, ou começar a vala-los após cerca de uma semana ou assim?

A: Isso é até você, depois de tanto tempo eu mover nossos artefatos de construção para armazenamento a longo prazo ou apagá-los, mas todos os dados que são armazenados em arquivos de texto / arquivos xml I manter ao redor, isso me deixa armazenar o changelog, gráficos de tendência, etc no servidor com verrrry pouco espaço consumido. Além disso, você pode definir Hudson até só manter artefatos de uma fuga # de compilações
Q:? é outra coisa lá qualquer coisa que eu não estou vendo aqui

A: Não, Go obter Hudson agora, você não ficará desapontado

Outras dicas

Nós tivemos muita sorte com a seguinte combinação:

Visual Studio (especificamente, utilizando a ferramenta de linha de comando MSBuild.exe e passando-os nossos arquivos de solução. Remove a necessidade de scripts msbuild)
NAnt (como a biblioteca sintaxe XML / tarefa melhor do que MSBuild. Também tem opções para operações de controle P4 src )
CruiseControl.net - construído no painel web para o monitoramento / começando constrói.

CCNet foi construído em notificadores para enviar e-mails quando constrói sucesso / falha

Na justificação: Isso leva a carga fora desenvolvedores fazendo o manual constrói e faz um monte para tirar o erro humano da equação. É muito difícil quantificar esse efeito, mas uma vez que você fizer isso você nunca vai voltar. Ter um processo repetitivo de software de construção e liberação é primordial. Tenho certeza que você esteve em lugares onde eles constroem o software à mão e fica em estado selvagem, só para ter a sua construção cara dizer "Opa, eu devo ter esquecido de incluir essa nova DLL!"

Em hardware: tão poderoso quanto você pode obter. Mais construir vezes mais rápidos de alimentação / memória =. Se você pode pagar você nunca vai se arrepender recebendo uma máquina de compilação de alto nível, não importa quão pequeno o grupo.

No domínio do espaço: Ajuda a ter uma abundância de espaço no disco rígido. Você pode criar seus scripts NAnt para apagar arquivos intermediários cada vez que uma construção começa, então a verdadeira questão é manter histórias de log e instaladores de aplicativos antigos. Temos software que espaço em disco monitores e envia alertas. Em seguida, limpar a unidade manualmente. Normalmente precisa ser feito a cada 3-4 meses.

Em notificações de compilação: Este é construído para CCNet, mas se você estiver indo para adicionar testes automatizados como um passo adicional, em seguida, construir este para o projeto a partir do get-go. É extremamente difícil para fazer testes de ajuste quando um projeto se torna grande. Há toneladas de informações sobre os quadros de teste lá fora (provavelmente uma tonelada de informações sobre SO bem), então eu vou adiar a nomeação de quaisquer ferramentas específicas.

No meu local de trabalho anterior usamos TeamCity . É muito fácil e poderoso para uso. Ele pode ser usado gratuitamente com algumas restrições. Há também um tutorial sobre Dime moldes . A razão por que não usar CruiseControl.NET é que tivemos um monte de pequenos projetos e é muito doloroso para definir cada um em CC.NET. Eu recomendo TeamCity. Para resumir, se você estiver em direção de código aberto, em seguida, CC.NET é o grande pai com um pouco maior curva de aprendizado. Se o seu orçamento permitir que você definitivamente ir com TeamCity ou confira a versão gratuita.

Como? Ter um olhar para blog de Carel Lotz .

Por quê? Há várias razões que eu posso pensar de:

Uma compilação de trabalho, quando devidamente implementado, significa que todos os seus desenvolvedores pode construção em sua máquina quando a compilação é verde
Uma compilação de trabalho, quando devidamente implementado, significa que você está pronto para implantar a qualquer momento
Uma compilação de trabalho, quando devidamente implementado, significa que tudo o que você liberar fez uma viagem ao seu sistema de controle de origem.
Uma compilação de trabalho, quando devidamente implementado, significa que você integrar cedo e muitas vezes, reduzindo o risco de integração.

O artigo de Martin Fowler sobre Integração Contínua continua a ser o texto definitivo. Ter um olhar para ele!

O principal argumento a favor é que ele vai cortar o custo do seu processo de desenvolvimento, ao alertá-lo o mais rápido possível que você tem uma compilação quebrado ou testes fracassados.

O problema de integrar o trabalho de vários desenvolvedores é o principal perigo do crescimento de uma equipe. Quanto maior a equipe fica, mais difícil é para coordenar seu trabalho e impedi-los brincar com alterações uns dos outros. A única boa solução é dizer-lhes para "integrar cedo e muitas vezes", verificando em pequenas unidades de trabalho (às vezes chamado de "histórias"), como eles são concluídos.

Você deve fazer a máquina de compilação reconstruir cada vez que algum cheques em, ao longo do dia. Com Cruise Control, você pode obter um ícone na barra de tarefas que fica vermelho (e mesmo conversações para você!) Quando a compilação é quebrado.

Você deve então fazer uma compilação noturno cheio limpo, onde a versão de origem é rotulado (dado um número de compilação única) que você pode optar por publicar a seus stakeholders (gerentes de produto, pessoas QA). Isso é para que quando um erro é informado, é contra um número de compilação conhecida (que é extremamente importante).

Idealmente, você deve ter um site interno, onde constrói pode ser baixado, e ter um botão que você pode clicar para publicar o nightly build anterior.

Apenas tentando construir um pouco sobre o que mjmarsh disse, desde que ele colocou uma grande base ...

Visual Studio. MSBuild funciona bem.
NAnt .
NAntContrib . Isto irá fornecer tarefas adicionais, tais como operações Perforce.
CruiseControl.net . Esta é mais uma vez, basicamente, a sua "construção dashboard".

Todos os itens acima (exceto por VS) é de código aberto, para que você não está olhando para qualquer licenciamento adicional.

Como Earwicker mencionado, construção início, construir muitas vezes. Saber algo quebrou, e você pode produzir um resultado final é útil para a captura de coisas desde o início.

NAnt inclui tarefas para nunit / nunit2 , bem, então você pode realmente automatizar seu teste de unidade. Você pode então aplicar folhas de estilo para os resultados, e com a ajuda do quadro fornecido pela CruiseControl.net, têm, resultados de teste de unidade agradáveis ??legíveis impressão para cada compilação.

O mesmo se aplica à ndoc tarefa. Ter a documentação produzida e disponível, para cada compilação.

Você ainda pode usar o exec tarefa de executar outros comandos, por exemplo, produzindo um Windows Installer com o InstallShield.

A idéia é automatizar a construção, tanto quanto possível, porque os seres humanos cometem erros. O tempo gasto na frente é tempo economizado na estrada. As pessoas não estão tendo que tomar conta da compilação passando pelo processo de criação. Identificar todas as etapas de sua construção, criar scripts NAnt para cada tarefa, e construir seus scripts NAnt um por um até que você totalmente automatizado todo o seu processo de criação. Também seguida, coloca todo o seu constrói em um só lugar, o que é bom para fins de comparação. quebrar alguma coisa em Build 426 que funcionou bem em Build 380? Bem, existem as entregas pronto para testar -. Agarrá-los e teste afastado

Nenhuma licença necessário. CruiseControl.net está disponível gratuitamente e só precisa do SDK do .NET para construir.
Um servidor de compilação, mesmo sem testes de unidade automatizados ainda fornece um ambiente controlado para a construção de lançamentos. Não mais "John normalmente baseia-se na sua máquina, mas ele está fora doente. Por alguma razão eu não posso construir na minha máquina"
Agora eu tenho um criado em uma sessão de PC virtual.
Sim. As necessidades de construção para ser despejado em algum lugar acessível. Desenvolvimento construções deveria ter depuração ligado. Lançamento de construção deve tê-lo desligado.
Como muitas vezes é até você. Se configurado corretamente, você pode construir após cada check-in vontade muito pouca sobrecarga. Esta é uma ótima idéia, se você tem (ou estão pensando em ter) testes de unidade no lugar.
Mantenha marcos e versões, desde que necessário. Qualquer outra coisa que depende de quantas vezes você constrói: continuamente? jogar fora. Diariamente? Mantenha uma semana. Semanal? Mantenha a pena de dois meses.

Quanto maior for o seu projeto fica mais você vai ver os benefícios de uma máquina de compilação automatizada.

É tudo sobre a saúde da compilação. O que isto faz com que você é que você pode configurar qualquer tipo de coisas que você quer que aconteça com o constrói. Entre estes é possível executar testes, análise estática, e profiler. Problemas são tratados com muito mais rápida, quando você trabalhou recentemente em que parte da aplicação. Se você cometer pequenas mudanças, então é quase lhe diz onde você quebrou-o:)

Isto, obviamente, pressupõe, você configurá-lo para construir com cada check-in (integração contínua).

Ele também pode ajudar a obter QA e Dev mais perto. Como você pode configurar testes funcionais para correr com ele, junto com profiler e qualquer outra coisa que melhora o feedback para a equipe de desenvolvimento. Isso não significa que os testes funcionais são executados com cada check-in (pode demorar um pouco), mas você configurar constrói / testes com ferramentas que são comuns a toda a equipe. I foram automatizar testes de fumo, então no meu caso, colaborar ainda mais de perto.

Por: 10 anos atrás, como desenvolvedores de software usados ??para analisar algo à enésima potência obter os documentos (escrito em uma linguagem humana) 'assinado', em seguida, começar a escrever código. Gostaríamos de teste de unidade, teste de corda e então teríamos atingido teste do sistema: a primeira vez que o sistema como um todo seria executado juntos, às vezes semanas ou meses depois que nós obtivemos os documentos assinados off. Foi só então que iríamos descobrir todos os pressupostos e mal-entendidos que tivemos quando analisamos tudo.

Integração Contínua como e idéia faz com que você construir uma (embora, inicialmente, muito simples) end sistema completo ao fim. Ao longo do tempo a funcionalidade do sistema é construído perpendicularmente. Toda vez que você faz uma compilação completa você está fazendo o teste do sistema cedo e muitas vezes. Isto significa que você encontrar e fixar bugs e premissas tão cedo quanto possível, quando é o mais barato hora de corrigi-los.

Como: Quanto ao como, eu escrevi sobre isso um pouco atrás: [ Clique Aqui ]

Mais de 8 mensagens que vai passo a passo sobre como configurar um servidor Jenkins em um ambiente de janelas para soluções .NET.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow