Como e por que eu configuro uma máquina de construção em C #? [fechadas]
144
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:
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. Vou precisar de outra coisa ou há um equivalente a um trabalho cron para executar scripts automatizados?
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.
Que tipo de hardware vou precisar para isso?
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 iremos a ela, mas poderá fazer compilações de depuração se for necessário.
Quantas vezes devemos fazer esse tipo de construção?
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 cerca de uma semana?
Há mais alguma coisa que não estou vendo aqui?
Percebo que esse é um tópico muito amplo e estou apenas começando. Não consegui encontrar uma duplicata dessa pergunta aqui e, se houver um livro por aí, eu deveria apenas obter, por favor me avise.
EDIT: Eu finalmente consegui funcionar! Hudson é completamente fantástico, e o FxCop está mostrando que alguns recursos que pensamos terem sido implementados estavam realmente incompletos. Também tivemos que mudar o tipo de instalador de vdproj do antigo e usado para o New Hotness WiX.
Basicamente, para quem está prestando atenção, se você pode executar sua compilação na linha de comando, pode colocá-la no hudson. Fazer a compilação executar a partir da linha de comando via MSBuild é um exercício útil por si só, porque força suas ferramentas a serem atualizadas.
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!
Ótima resposta! Eu usei apenas o CruiseControl, mas você tem uma boa venda para o Hudson.
Ben S
1
Obrigado pelas indicações - Hudson parece a ferramenta certa.
Mmr'
1
Você poderia colocar o link na primeira palavra, por favor?
Jhonny D. Cano -Leftware-
Onde você está pedindo um link para Hudson? Se assim for, eu adicionei-o, boa chamada :)
Allen Rice
5
Caso alguém tenha perdido, o Hudson foi bifurcado / renomeado como Jenkins por seus desenvolvedores originais. Agora é melhor escolher Jenkins, pois essa pergunta provavelmente o convencerá.
Jonik
26
Tivemos muita sorte com a seguinte combinação:
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)
NAnt (como a sintaxe XML / biblioteca de tarefas melhor que o MSBuild. Também possui opções para operações de controle P4 src)
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.
Ye, eu tive grandes experiências com CC.NET bem :)
cwap
Ótima resposta, exceto para requisitos de hardware. Ele está fazendo builds noturnos, então eu duvido que ele se importe se demorar algumas horas para compilar e testar. Eu até sugeriria configurar tudo em uma VM no hardware que eles já possuem.
5119 Ben S
Obrigado pelas dicas. Vou usar isso nas minhas justificativas.
2100 mmr mmr
1
Aqui usamos uma máquina de compilação com o NAnt / Subversion / CC.Net para compilações em C # e C ++ e é realmente uma ótima ferramenta para garantir que você não tenha quebrado nenhum outro projeto. É remover uma grande parte do medo de quebrar outro projeto quando se muda de uma biblioteca, porque de qualquer maneira que você vai vê-lo em breve, se ele quebrou tudo
Julien Roncaglia
11
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.
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.
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.
Eu tinha esquecido o ndoc. A documentação é toda uma outra bola de cera que teremos que enfrentar - obrigado pelo lembrete.
2100 mmr mmr
4
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.
Embora esse link possa responder à pergunta, é melhor incluir aqui as partes essenciais da resposta e fornecer o link para referência. As respostas somente para links podem se tornar inválidas se a página vinculada for alterada.
precisa saber é o seguinte
Isso não fornece uma resposta para a pergunta. Para criticar ou solicitar esclarecimentos a um autor, deixe um comentário abaixo da postagem - você sempre pode comentar em suas próprias postagens e, quando tiver reputação suficiente , poderá comentar em qualquer post .
Respostas:
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
Aqui estão algumas das coisas .net incorporadas que o Hudson suporta
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:
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!
fonte
Tivemos muita sorte com a seguinte combinação:
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.
fonte
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.
fonte
Quão? Dê uma olhada no blog de Carel Lotz .
Por quê? Existem várias razões em que posso pensar:
O artigo de Martin Fowler sobre integração contínua continua sendo o texto definitivo. Dê uma olhada!
fonte
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.
fonte
Apenas tentando entender um pouco o que mjmarsh disse, já que ele lançou uma grande base ...
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.
fonte
Quanto maior o seu projeto, mais você verá os benefícios de uma máquina de construção automatizada.
fonte
É 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.
fonte
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.
fonte