Como e por que eu configuro uma máquina de construção em C #? [fechadas]

Estou trabalhando com uma equipe de desenvolvimento pequena (4 pessoas) em um projeto C #. Propus a criação de uma máquina de compilação que fará compilações e testes noturnos do projeto, porque entendo que isso é uma coisa boa. O problema é que não temos muito orçamento aqui, então tenho que justificar a despesa para os poderes que existem. Então eu quero saber:

Atualização: Jenkins é a versão mais atualizada do Hudson. Todo mundo deveria estar usando Jenkins agora. Eu atualizarei os links adequadamente.

O Hudson é gratuito e extremamente fácil de configurar e será executado facilmente em uma VM.

Em parte de um antigo posto meu:

Nós o usamos para

• Implantar serviços do Windows
• Implantar serviços da web
• Execute MSTests e exiba tanta informação quanto qualquer teste de junção
• Acompanhe tarefas baixas, médias e altas
• avisos e erros do trendgraph

Aqui estão algumas das coisas .net incorporadas que o Hudson suporta

• MSBuild
• NAnt
• MSTest
• Nunit
• Team Foundation Server
• fxcop
• stylecop
• avisos do compilador
• tarefas de código

Além disso, Deus não permita que você esteja usando fontes visuais seguras, mas também suporta isso . Eu recomendo que você dê uma olhada no artigo de Redsolo sobre a criação de projetos .net usando Hudson

Suas perguntas

• P : De que tipo de ferramentas / licenças vou precisar? No momento, usamos o Visual Studio e o Smart Assembly para criar e o Perforce para controle de origem. Preciso de outra coisa ou existe um equivalente a um trabalho cron para executar scripts automatizados?

• UMA: Acabei de instalar o visual studio em uma nova cópia de uma VM executando uma instalação nova e corrigida de um sistema operacional Windows server. Então você precisaria das licenças para lidar com isso. O Hudson se instalará como um serviço do Windows e será executado na porta 8080 e você configurará quantas vezes deseja que ele faça uma varredura no seu repositório de códigos em busca de códigos atualizados, ou peça-lhe para construir em um determinado momento. Tudo configurável através do navegador.

• Q: O que exatamente isso me fará, além de uma indicação de uma compilação quebrada? Devo configurar projetos de teste nesta solução (arquivo sln) que serão executados por esses scripts, para que eu possa testar determinadas funções? No momento, temos dois desses testes, porque não tivemos tempo (ou francamente, a experiência) para fazer bons testes de unidade.

  R: Você receberá um email na primeira vez que uma compilação falhar ou se tornar instável. Uma compilação é instável se um teste de unidade falhar ou pode ser marcada como instável por qualquer número de critérios que você definir. Quando um teste ou compilação da unidade falhar, você receberá um e-mail, informando onde, por que e como falhou. Com minha configuração, obtemos:

  • lista de todas as confirmações desde a última compilação de trabalho
  • cometer notas desses commits
  • lista de arquivos alterados nos commits
  • saída do console da própria compilação, mostrando o erro ou falha de teste

• P: Que tipo de hardware precisarei para isso?

  A: Uma VM será suficiente

• P: Depois que uma compilação é concluída e testada, é uma prática comum colocá-la em um site ftp ou ter alguma outra maneira de acesso interno? A idéia é que esta máquina faça a compilação, e todos nós vamos a ela, mas pode fazer compilações de depuração se for necessário.

  R: O Hudson pode fazer o que quiser com ele, incluindo identificação através do hash md5, upload, cópia, arquivamento etc. Ele faz isso automaticamente e fornece um longo histórico de artefatos de construção.

• P: Com que frequência devemos criar esse tipo de build?

  R: Temos nossa pesquisa SVN a cada hora, procurando alterações de código e executando uma compilação. A noite é boa, mas a IMO um tanto inútil, já que o que você trabalhou ontem não estará fresco em sua mente pela manhã quando você entrar.

• P: Como o espaço é gerenciado? Se fizermos construções noturnas, devemos manter todas as construções antigas ou começar a abandoná-las depois de aproximadamente uma semana?

  R: Depende de você, depois de tanto tempo movo nossos artefatos de construção para armazenamento a longo prazo ou os apago, mas todos os dados armazenados em arquivos de texto / arquivos xml que eu mantenho por aí, isso permite armazenar o changelog, gráficos de tendência, etc no servidor com muito pouco espaço consumido. Também é possível configurar o Hudson para manter apenas os artefatos de um número de compilações à direita

• P: Há mais alguma coisa que não estou vendo aqui?

  A: Não, vá buscar Hudson agora, você não ficará desapontado!

Tivemos muita sorte com a seguinte combinação:

1. Visual Studio (especificamente, usando a ferramenta de linha de comando MSBuild.exe e passando nossos arquivos de solução. Elimina a necessidade de scripts msbuild)
2. NAnt (como a sintaxe XML / biblioteca de tarefas melhor que o MSBuild. Também possui opções para operações de controle P4 src)
3. CruiseControl.net - painel da web incorporado para monitorar / iniciar compilações.

A CCNet incorporou notificadores para enviar e-mails quando as compilações foram bem-sucedidas / reprovadas

Na justificativa: isso afasta os desenvolvedores de compilações manuais e faz muito para eliminar erros humanos da equação. É muito difícil quantificar esse efeito, mas, uma vez feito, você nunca mais voltará. Ter um processo repetitivo para criar e liberar software é fundamental. Tenho certeza de que você já esteve em lugares onde eles construíram o software manualmente e ele se espalhou pela natureza, apenas para que o responsável pela criação dissesse "Opa, devo ter esquecido de incluir essa nova DLL!"

No hardware: o mais poderoso possível. Mais energia / memória = tempos de construção mais rápidos. Se você puder pagar, nunca se arrependerá de ter uma máquina de construção de primeira, não importa o tamanho do grupo.

No espaço: ajuda a ter bastante espaço no disco rígido. Você pode criar seus scripts NAnt para excluir arquivos intermediários toda vez que uma compilação é iniciada, portanto o problema real é manter históricos de log e instaladores de aplicativos antigos. Temos software que monitora o espaço em disco e envia alertas. Em seguida, limpamos a unidade manualmente. Geralmente precisa ser feito a cada 3-4 meses.

Nas notificações de compilação: isso é incorporado ao CCNet, mas se você deseja adicionar testes automatizados como uma etapa adicional, construa-o no projeto desde o início. É extremamente difícil voltar aos testes de ajuste depois que um projeto cresce. Há toneladas de informações sobre estruturas de teste por aí (provavelmente também muitas informações sobre SO), então vou adiar o nome de quaisquer ferramentas específicas.

No meu local de trabalho anterior, usamos o TeamCity . É muito fácil e poderoso de usar. Pode ser usado gratuitamente com algumas restrições. Há também um tutorial sobre Dime Casts . A razão pela qual não usamos o CruiseControl.NET é que tínhamos muitos projetos pequenos e é bastante doloroso configurá-los no CC.NET. Eu recomendo o TeamCity. Para resumir se você gosta de código aberto, o CC.NET é o avô com uma curva de aprendizado um pouco mais alta. Se o seu orçamento permitir, você definitivamente vai com o TeamCity ou confira a versão gratuita.

Quão? Dê uma olhada no blog de Carel Lotz .

Por quê? Existem várias razões em que posso pensar:

• Uma compilação funcional, quando implementada adequadamente, significa que todos os seus desenvolvedores podem compilar na máquina quando a compilação é verde
• Uma compilação funcional, quando implementada adequadamente, significa que você está pronto para implantar a qualquer momento
• Uma compilação funcional, quando implementada adequadamente, significa que tudo o que você libera fez uma viagem ao seu sistema de controle de origem.
• Uma compilação de trabalho, quando implementada adequadamente, significa que você se integra cedo e frequentemente, reduzindo o risco de integração.

O artigo de Martin Fowler sobre integração contínua continua sendo o texto definitivo. Dê uma olhada!

O principal argumento a favor é que isso reduzirá o custo do seu processo de desenvolvimento, alertando assim que possível que você tem uma compilação quebrada ou falha nos testes.

O problema de integrar o trabalho de vários desenvolvedores é o principal perigo de formar uma equipe. Quanto maior a equipe, mais difícil é coordenar seu trabalho e impedi-los de mexer nas mudanças uns dos outros. A única boa solução é dizer a eles para "integrarem-se cedo e com frequência", verificando pequenas unidades de trabalho (às vezes chamadas de "histórias") à medida que são concluídas.

Você deve fazer com que a máquina de compilação reconstrua A CADA VEZ alguns check-in, ao longo do dia. Com o Cruise Control, você pode obter um ícone na barra de tarefas que fica vermelho (e até fala com você!) Quando a compilação é interrompida.

Em seguida, você deve fazer uma compilação limpa todas as noites, onde a versão de origem está identificada (com um número de compilação exclusivo) que pode optar por publicar para as partes interessadas (gerentes de produto, pessoal de controle de qualidade). Isso é feito para que, quando um bug for relatado, seja contra um número de compilação conhecido (isso é extremamente importante).

Idealmente, você deve ter um site interno no qual as compilações possam ser baixadas e um botão no qual você pode clicar para publicar a compilação noturna anterior.

Apenas tentando entender um pouco o que mjmarsh disse, já que ele lançou uma grande base ...

• Estúdio visual. MSBuild funciona bem.
• NAnt .
• NantContrib . Isso fornecerá tarefas adicionais, como operações do Perforce.
• CruiseControl.net . Este é novamente o seu "painel de construção".

Todas as opções acima (exceto o VS) são de código aberto, portanto você não precisa de nenhum licenciamento adicional.

Como Earwicker mencionou, construa cedo, construa com frequência. Saber que algo quebrou e você pode produzir uma entrega é útil para capturar coisas desde o início.

O NAnt também inclui tarefas para o nunit / nunit2 , para que você possa automatizar seu teste de unidade. Você pode aplicar folhas de estilo aos resultados e, com a ajuda da estrutura fornecida pelo CruiseControl.net, obter bons resultados de teste de unidade legíveis e imprimíveis para cada compilação.

O mesmo se aplica à tarefa ndoc . Tenha sua documentação produzida e disponível para cada build.

Você pode até usar a tarefa exec para executar outros comandos, por exemplo, produzindo um Windows Installer usando o InstallShield.

A idéia é automatizar a construção o máximo possível, porque os seres humanos cometem erros. O tempo gasto na frente é o tempo economizado na estrada. As pessoas não precisam cuidar da construção passando pelo processo de construção. Identifique todas as etapas de sua compilação, crie scripts NAnt para cada tarefa e crie seus scripts NAnt um por um até que você tenha automatizado completamente todo o seu processo de compilação. Ele também coloca todas as suas compilações em um único local, o que é bom para fins de comparação. Alguma quebra no Build 426 que funcionou bem no Build 380? Bem, existem os produtos prontos para teste - pegue-os e teste-os.

• Não são necessárias licenças. O CruiseControl.net está disponível gratuitamente e precisa apenas do .NET sdk para compilar.
• Um servidor de construção, mesmo sem testes de unidade automatizados, ainda fornece um ambiente controlado para as liberações de construção. Chega de "John normalmente constrói sua máquina, mas está doente. Por algum motivo, não consigo construir minha máquina"
• No momento, tenho um configurado em uma sessão do Virtual PC.
• Sim. A construção precisa ser descartada em algum lugar acessível. As compilações de desenvolvimento devem ter a depuração ativada. A versão de lançamento deve desativá-la.
• Quantas vezes depende de você. Se configurado corretamente, você poderá criar após cada check-in muito pouco custo adicional. Essa é uma ótima idéia se você tiver (ou planeja ter) testes de unidade em vigor.
• Mantenha marcos e liberações pelo tempo que for necessário. Qualquer outra coisa depende da frequência com que você constrói: continuamente? jogar fora. Diariamente? Mantenha o valor de uma semana. Semanal? Mantenha o valor de dois meses.

Quanto maior o seu projeto, mais você verá os benefícios de uma máquina de construção automatizada.

É tudo sobre a saúde da construção. O que isso leva a você é que você pode configurar qualquer tipo de coisa que deseja que ocorra com as compilações. Entre eles, você pode executar testes, análise estática e criação de perfil. Os problemas são tratados com muito mais rapidez, quando você trabalhou recentemente nessa parte do aplicativo. Se você cometer pequenas alterações, quase indica onde você as quebrou :)

Obviamente, isso pressupõe que você o configure para compilar a cada check-in (integração contínua).

Também pode ajudar a aproximar o controle de qualidade e o desenvolvimento. Como você pode configurar testes funcionais para executar com ele, juntamente com o criador de perfil e qualquer outra coisa que melhore o feedback para a equipe de desenvolvimento. Isso não significa que os testes funcionais sejam executados a cada check-in (pode demorar um pouco), mas você cria builds / testes com ferramentas comuns a toda a equipe. Eu tenho automatizado testes de fumaça, então, no meu caso, colaboramos ainda mais de perto.

Por que: há 10 anos, nós, como desenvolvedores de software, analisávamos algo até o enésimo grau, obtivemos a assinatura dos documentos (escritos em uma linguagem humana) e começamos a escrever o código. Fazíamos teste de unidade, teste de cordas e, em seguida, batíamos no teste do sistema: na primeira vez em que o sistema como um todo seria executado em conjunto, às vezes semana ou meses após a assinatura dos documentos. Só então descobriríamos todas as suposições e mal-entendidos que tínhamos quando analisamos tudo.

A integração contínua e a idéia fazem com que você construa um sistema completo (embora, inicialmente, muito simples) de ponta a ponta. Com o tempo, a funcionalidade do sistema é construída ortogonalmente. Toda vez que você faz uma compilação completa, realiza o teste do sistema com antecedência e frequência. Isso significa que você encontra e corrige bugs e suposições o mais cedo possível, quando é o momento mais barato para corrigi-los.

Como: Quanto ao como, escrevi sobre isso há pouco tempo: [ Clique aqui ]

Mais de 8 posts, passo a passo sobre como configurar um servidor Jenkins em um ambiente Windows para soluções .NET.