Existem algumas estruturas diferentes de Integração Contínua (CI) por aí e estou me perguntando qual é a mais popular. Quais estruturas você usou nas empresas em que trabalha?
Existe alguma razão para que uma estrutura de IC seja mais popular que outra - talvez isso esteja relacionado aos recursos que ela oferece, às coisas que se integram a ela ou talvez seja apenas um marketing?
Parece que a integração contínua é usada mais nos mundos Java e .net do que em ruby ou python. Por que é isso?
java
c#
development-process
builds
Richard Warburton
fonte
fonte
Respostas:
Hudson ou Jenkins (o último é um garfo do primeiro). Razão: É simples (simples de instalar e usar) e possui grande flexibilidade. Os plugins adicionam quase todas as funcionalidades que consigo imaginar.
Alguns anos atrás eu usei o controle de danos . Também era simples de usar, mas não tinha os plugins. Mas o autor decidiu que desistiria da solução simples e iniciou o desenvolvimento de uma nova versão, que consistia em diferentes servidores se comunicando (o que diabos?). Isso não funcionou bem e o projeto foi abandonado. Eu estava na busca há algum tempo, mas nem o controle de cruzeiro (muito complicado) nem o contínuo realmente me pegou. Até Hudson, isso funcionou desde o primeiro momento para mim.
fonte
Eu uso o TeamCity no trabalho e em casa. Ele oferece excelente suporte a vários corredores de compilação e é extensível via plugins.
Não lidar com pilhas de XML para configuração é uma enorme vantagem em meus livros, e a versão gratuita é suficiente para as necessidades da minha casa.
Um problema que tive com o TeamCity tem a ver com a tentativa de fazer a versão automática de assemblies .NET. Eu tive que configurar uma solução alternativa relativamente complicada, mas, uma vez instalada, funcionou como um encanto.
fonte
Pessoalmente, eu só usei CruiseControl e CruiseControl.Net. A razão para isso tem a ver com economia. Eles são razoavelmente estáveis e, uma vez configurados, há muito pouco que você precisa fazer para mantê-lo. A comunidade de usuários geralmente é muito útil e pode ser estendida às suas necessidades.
Dito isso, existem algumas ofertas comerciais disponíveis (uma da JetBrains e outra da Atlassian) que oferecem uma melhor experiência de configuração e suporte comercial. Eu pretendo experimentar essas ofertas, mas ainda não tive uma chance.
As ferramentas de IC têm um papel mais importante a desempenhar com as linguagens compiladas do que as linguagens interpretadas, mas isso não significa que a ferramenta de CI seja desperdiçada em linguagens interpretadas. Quando você tem vários projetos que dependem um do outro e deseja garantir que uma alteração não interrompa acidentalmente suas dependências - as ferramentas de IC são inestimáveis.
Existem três classes gerais de problemas que as ferramentas de IC podem ajudar a detectar:
Os idiomas interpretados não são compilados, portanto, não há erros de compilação a serem capturados. No entanto, os outros dois problemas são comuns o suficiente para que as ferramentas de IC sejam úteis para projetos em Ruby / Python / Perl / etc.
A palavra-chave nos erros de lógica e nos pontos de teste de aceitação é "automatizado". Se você não possui um conjunto de testes que uma máquina pode executar, realmente está perdendo os maiores benefícios das ferramentas de CI. As suítes automatizadas podem ser construídas com o tempo, para que você possa começar pequeno.
Editar
Veja este bom gráfico para comparações de recursos de um grande número de ferramentas de CI (muitas das quais eu não conhecia):
http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix
fonte
Team Foundation Server
CI sólido, forte integração com o Visual Studio e Git como controle de versão . Eu já vi servidores de CI mais flexíveis, como o Hudson, mas a forte integração do TFS com outros produtos torna a experiência tão perfeita que faz sentido para minha equipe.
fonte
Eu uso o CruiseControl.NET e o Hudson . Algumas das minhas compilações estão em uma delas e outras no outro.
Por quê? Porque eu não sou o engenheiro de construção e aquele que é o engenheiro de construção os configura dessa maneira!
Não tenho problemas com a forma como minhas compilações são configuradas ou com reclamações sobre qualquer produto. Estou relatando a você como as coisas estão aqui, com naturalidade e espero que você aprecie essa perspectiva!
ATUALIZAÇÃO: Desde que postei a resposta, Hudson foi bifurcado e se tornou Jenkins . A recomendação acima se aplica à Jenkins.
fonte
Pulse . Basicamente, Just Works, o que para um engenheiro de construção ocupado é um grande negócio. Eles também têm um excelente suporte técnico. A principal razão pela qual eu amo tanto é que temos mais de 250 projetos e os lida sem problemas; Não posso dizer o mesmo para Hudson.
fonte
Nossa equipe trabalha principalmente em Python, C ++ e Java. Usamos o Buildbot para IC. Inicialmente, começamos com isso porque ele se integra ao Trac e porque parecia simples e direto. Eu acredito que é a estrutura de CI de escolha no mundo Python.
fonte
Hudson. Às vezes, é um pouco complicado, e alguns dos plugins mais interessantes não funcionam, mas com um pouco de pega é bastante útil.
Eu provavelmente usaria o Pulse, mas se você precisar criar em várias plataformas, é> US $ 5k, o que é um pouco demais.
fonte
CruiseControl.NET para integração contínua. Funciona muito bem, embora com o grande número de projetos de compilação que configuramos no CruiseControl, o aplicativo de bandeja da área de trabalho do CCTray seja terrivelmente sem resposta, mesmo com longos intervalos de atualização.
NAnt é para os scripts de construção que são executados nos projetos CruiseControl. Para scripts de construção mais complexos, estendemos o NAnt com tarefas personalizadas de C # NAnt, o que é muito bom - escrever código em C # é muito mais agradável do que criar scripts NAnt.
Somos uma loja da Microsoft e, teoricamente, mudaremos para o Team Build 2010 da Microsoft assim que migrarmos o ambiente do Team Foundation Server para 2010.
fonte
Observe que você poderá criar seu aplicativo a partir da linha de comando, independentemente de ter um mecanismo de CI em execução ou não.
Isso significa que tudo o que o mecanismo de CI faz é sistematizar suas chamadas de compilação e você pode escolher o mecanismo que melhor atenda às suas necessidades específicas.
Em geral, gosto de Hudson principalmente porque "parece" legal, mas sei que se tudo falhar, posso mudar para outro sem muito esforço. Nesse caso, eu provavelmente investigaria primeiro o feito pelo Atlassian, pois gosto da "sensação" dos outros programas que eles fazem.
Observe que a intercambiabilidade implica que não importa em que idioma eles estão escritos. Acredito que o Java foi escolhido para muitos mecanismos, porque as muitas plataformas suportadas, combinadas com os muitos blocos de construção facilmente disponíveis. Precisa de um servidor web - pegue um. Precisa de muitos threads simultâneos - basta usá-los. Precisa de extensibiilidade - deixe cair em uma jarra.
fonte
Antes de ouvir o termo "integração contínua" (isso foi em 2002 ou 2003), escrevi um script de construção noturno que se conectava ao cvs, peguei uma cópia limpa do projeto principal e dos cinco subprojetos menores, construí todos os jars via ant então construiu e reimplementou um arquivo WAR por meio de um segundo script ant que usava as tarefas ant tomcat.
Ele foi executado via cron às 19:00 e enviou um email com vários arquivos de saída anexados. Nós o usamos durante os 7 meses inteiros do projeto e ele permaneceu em uso pelos próximos 20 meses de manutenção e melhorias.
Funcionou bem, mas ainda prefere hudson a scripts bash, cron e ant.
fonte