TeamCity vs Jenkins para integração contínua [atualização de 2023]

Jenkins é uma ferramenta de integração contínua de código aberto, enquanto o TeamCity é uma oferta proprietária da JetBrains. O TeamCity é mais fácil de configurar e mais direto de usar, enquanto o Jenkins possui um rico ecossistema de plug-ins e integrações.

Isso é TeamCity vs Jenkins em resumo, mas continue lendo para um mergulho profundo na integração contínua e por que mais e mais equipes de desenvolvimento de software estão usando essas ferramentas para acelerar seu ciclo de lançamento.

Integração contínua, controle do código-fonte e gerenciamento de compilação são conceitos formativos por trás do DevOps, impulsionados pela necessidade de integrar regularmente códigos novos e alterados no repositório principal de sistemas de controle de versão como Github ou Bitbucket da Atlassian. A integração contínua é frequentemente combinada com a entrega contínua para obter processos de construção mais rápidos e estáveis com automação.

Com a integração contínua, as equipes compilam o software e o executam por meio de uma série de testes que imitam o ambiente de produção para garantir uma compilação bem-sucedida quando enviada para a produção. A lógica por trás disso é simples, mas só veio em resposta a problemas no ciclo de implantação tradicional. Quanto mais você puder criar e testar durante o desenvolvimento, menos engenheiros de software terão que se preocupar em enviar para a produção. Em vez de empurrar uma vez por trimestre, a integração contínua, a entrega contínua e os testes tornam o go-live outra implantação de rotina simples.

TeamCity e Jenkins são ferramentas de CI que permitem aos desenvolvedores integrar ramificações de código durante o processo de desenvolvimento e executar uma série de testes automatizados nelas. Cada membro da equipe recebe feedback imediato sobre a prontidão de produção de seu código, mesmo que tenha alterado apenas uma única linha. Dessa forma, todos podem enviar para a produção enquanto o processo de criação, execução de testes e implantação é feito automaticamente para que possam se concentrar no próximo recurso ou correção de bug.

Embora ambas as ferramentas cubram grande parte do mesmo terreno, elas o fazem de maneiras diferentes. Isso ocorre porque o Jenkins é um projeto de código aberto, enquanto o TeamCity é uma oferta proprietária da JetBrains. Em nossa comparação, mostraremos como eles se comparam e discutiremos algumas de suas semelhanças, diferenças e o que torna cada um adequado para diferentes ambientes. Ambos oferecem ótimo suporte e documentação, mas, novamente, existem diferenças de profundidade e qualidade.

O que é TeamCity?

O slogan da TeamCity "Integração Contínua Poderosa pronta para uso" fala sobre o que eles oferecem em sua solução além de uma opção gratuita como o Jenkins: usabilidade pronta para uso com excelente histórico de compilação, controle de origem e ferramentas de cadeia de compilação. Sua interface gráfica elegante e recursos de facilidade de uso o tornam mais palatável para uma integração nova e contínua. O TeamCity é executado em um ambiente Java, geralmente em um servidor Apache Tomcat, embora possa ser instalado em servidores Windows e Linux. O TeamCity oferece suporte igual para projetos .NET e openstack, integrando-se ao Visual Studio e IDEs como o Eclipse.

O TeamCity converteu muitos fiéis do Jenkins com sua interface e configuração padrão segura. A JetBrains também oferece uma edição gratuita, com até 20 configurações de compilação e 3 agentes de compilação. O escopo além disso requer sua edição comercial "empresarial".

O que é Jenkins?

Jenkins é um servidor de integração contínua de código aberto e ferramenta de entrega contínua amplamente usado e considerado por muitos como o padrão de fato para servidores de CI. O Jenkins também é executado em Java, para que você possa instalá-lo nos sistemas operacionais Windows, unix ou Linux. Altamente extensível e com uma galeria de plug-ins prontamente à mão, o Jenkins oferece personalização granular para operações de CI de qualquer tamanho. Mas, como você pode ver comparando as duas capturas de tela, a interface do Jenkins lembra mais a última geração de aplicativos da web.

Jenkins era anteriormente o servidor Hudson CI. Após a aquisição da Sun pela Oracle, o código-fonte foi bifurcado e a Oracle continua o desenvolvimento sob o nome Hudson.

Se você está considerando CI, está considerando Jenkins. Mas, como muitos projetos de software de código aberto ricos em recursos, o Jenkins ganha a reputação de ter um processo de instalação e configuração difícil, que é a lacuna que o TeamCity tenta preencher com sua oferta comercial.

Atualização, sexta-feira, 13 de maio: Jenkins 2.0 melhorou significativamente a interface do usuário.

Pontuação lado a lado: TeamCity vs. Jenkins

1. Conjunto de recursos

Realmente, ambos são produtos bastante capazes. Jenkins lidera o caminho para CI, como já faz há algum tempo, então seu conjunto de recursos é bastante rico, oferecendo muitas maneiras diferentes de alcançar CI e entrega contínua.

O TeamCity pode não ser exatamente compatível com o Jenkins quando se trata do conjunto de recursos, mas as diferenças são pequenas e o TeamCity também atenderá à maioria das operações de CI.

Boas notícias para o TeamCity, que não seria capaz de competir se não oferecesse a maioria dos mesmos recursos que sua contraparte de código aberto, mas oferece suporte a diferentes plataformas, como Ruby, .NET e Java, bem como suporte a Docker de primeira classe.

2. Facilidade de uso

A interface do TeamCity, a configuração simples e a segurança pronta para uso dão a ele uma vantagem sobre o Jenkins quando se trata de facilidade de uso. O ponto de venda de qualquer alternativa comercial a um produto de código aberto é que ele reduz a sobrecarga administrativa visualizando ou simplificando o acesso ao conjunto de funcionalidades.

Isso não quer dizer que o Jenkins não seja utilizável, porque é e tem sido bem usado por muitas pessoas, mas para aqueles que podem pagar e não têm tempo ou inclinação para aprender Jenkins dentro e fora, o TeamCity oferece uma interface mais utilizável para a mesma tecnologia básica.

3. Apoio da Comunidade

Tanto o TeamCity quanto o Jenkins têm suporte da comunidade disponível em seu site, permitindo que os usuários de seu software compartilhem informações e solucionem problemas coletivamente, além de fornecer uma base de conhecimento para vasculhar ao procurar respostas específicas.

O Jenkins tem uma pequena vantagem aqui, mesmo porque eles existem há mais tempo e, como um projeto de código aberto, os usuários do Jenkins confiam mais em sua comunidade para solução de problemas.

4. Taxa de liberação

O TeamCity está atualmente na versão 2019.1.4, lançada em 11 de outubro de 2019. Seus lançamentos têm sido regulares e bem documentados.

O histórico de lançamentos do Jenkins é bastante impressionante, resumido em seu log de alterações, com informações detalhadas sobre cada lançamento. A versão 2.200 foi lançada em 14 de outubro de 2019.

Como fabricam produtos de CI, essas empresas sabem que a prova está no pudim, então não deve ser surpresa que seus processos de lançamento sejam de alta qualidade.

5. Preços e suporte

A TeamCity oferece duas versões de seu produto de CI. O TeamCity Professional é gratuito para 100 configurações de compilação e três agentes de compilação. Licenças adicionais de agente de compilação podem ser adquiridas por US$299 e incluem um agente de compilação adicional e dez configurações de compilação adicionais.

O TeamCity Enterprise permite um número ilimitado de configurações de compilação e licenças a partir de US$1999 para 3 agentes de compilação, escalando até 100 agentes por US$21.999. O preço é de 50% de desconto para startups e gratuito para projetos de código aberto.

Como mencionamos, o Jenkins é de código aberto, sob a licença do MIT e, como tal, pode ser baixado e usado gratuitamente. Por esse motivo, empresas menores podem querer abordar a CI de uma perspectiva de "por que não usaríamos o Jenkins".

Uma possível resposta a essa pergunta pode ser porque sua organização não tem mão de obra, conhecimento ou capacidade para organizar e gerenciar uma solução Jenkins. O TeamCity oferece serviços de suporte profissional, enquanto o suporte para o Jenkins vem principalmente da comunidade e de recursos online, embora empresas terceirizadas ofereçam serviços profissionais específicos do Jenkins.

6. API e extensibilidade

Tanto o TeamCity quanto o Jenkins oferecem uma API RESTful. A API do Jenkins vem em três sabores: XML, JSON e Python. O Jenkins tem maior extensibilidade, pois quase todas as partes podem ser personalizadas conforme necessário. Sua página de extensibilidade possui excelentes recursos para quase todos os tipos de personalização possíveis. O TeamCity tem muito menos informações disponíveis em seu site, outra diferença entre as ofertas comerciais e de código aberto; no entanto, os usuários do TeamCity parecem satisfeitos com a API em geral.

7. Integrações de terceiros

Plugins são o nome do jogo para Jenkins, que oferece centenas de plugins gratuitos, desde gerenciamento de código-fonte até ferramentas de construção e ferramentas de desenvolvimento específicas de linguagem. Esse banco de dados pré-existente de plug-ins úteis torna a adaptação do Jenkins ao seu ambiente muito mais fácil, poupando a necessidade de personalização interna ou contratada cara. O TeamCity também tem mais de 380 plug-ins gratuitos e desenvolvidos por multidão disponíveis, que eles oferecem no estado em que se encontram, fora de seu produto comercial suportado. O TeamCity também possui ótimas integrações em nuvem (Google Cloud, AWS, VMWare, etc), bem como integrações 'chave' (VSCode, Jira e até NuGet).

8. Empresas que o utilizam

A TeamCity possui uma ampla gama de empresas importantes como clientes, incluindo as potências da Internet Twitter, eBay e Wikipedia. Jenkins também não tem falta de grandes nomes em sua lista de usuários, Dell, Tumblr e Netflix entre eles. Claramente, ambos os produtos são capazes de operar em alto nível, mesmo na maior escala.

9. Curva de aprendizado

Assim como na facilidade de uso, a curva de aprendizado no TeamCity é menor do que no Jenkins como parte do valor que eles oferecem para seu produto comercial. As pessoas novas no próprio CI podem ter mais facilidade em entender os conceitos e procedimentos na interface superior do TeamCity, em vez de se adaptar à interface do usuário antiga do Jenkins. Dito isso, a documentação é abundante para o Jenkins, e os administradores de sistemas salgados podem preferir sua essência semelhante ao Linux à caixa preta proprietária do TeamCity.

10. Classificação de segurança

Tanto a JetBrains quanto a Jenkins têm classificações externas de segurança cibernética na faixa "boa". O site pai do TeamCity, JetBrains, tem uma classificação de segurança de um respeitável 827/950, enquanto Jenkins pontua mais alto em 865/950.

Placar e Resumo

É um resultado próximo, mas as grandes diferenças entre os dois produtos devem guiá-lo: você precisa de uma solução de código aberto infinitamente extensível que esteja disposto a aprender ou prefere pagar adiantado por uma solução comercial voltada para aumentar a usabilidade? Ambas as soluções podem executar bem seu ambiente de CI/CD e parecem apenas melhorar suas ofertas no futuro. Lembre-se de que CI e CD são ótimos, mas podem ser complementados por uma solução de visibilidade, como o UpGuard. Garantir que suas configurações correspondam às suas expectativas é o primeiro passo importante para CI, CD e automação.

Outras ferramentas de integrações contínuas a serem consideradas

Existem outros servidores de CI/CD por aí. O bambu da Atlassian é uma escolha popular. Como Jenkins e TeamCity, ele permite que os desenvolvedores criem, integrem e testem automaticamente o código-fonte e, em seguida, preparem aplicativos para desenvolvimento. O Bamboo funciona perfeitamente com outras ferramentas da Atlassian, como Jira (gerenciamento de projetos) e Hipchat.

Outra escolha popular é o GitLab CI, juntamente com projetos de teste e construção, o GitLab CI também pode implantar as compilações em sua infraestrutura, oferecendo a opção de rastrear suas diferentes implantações sabendo para onde cada pedaço de código foi. O bom do GitLab CI é que ele é oferecido gratuitamente como parte do GitLab. É tão simples quanto adicionar um arquivo .gitlab-ci.yml ao diretório raiz do seu repositório e configurar seu projeto GitLab para usar um Runner. Posteriormente, cada commit ou push acionará o pipeline de CI que tem três estágios: compilação, teste e implantação.

O Travis CI é outra alternativa que fornece vários tempos de execução (por exemplo, versões Node.js ou PHP), armazenamentos de dados e muito mais. Por isso, hospedar seu projeto no travis-ci.com significa que você pode testar sua biblioteca ou aplicativos em vários tempos de execução e armazenamentos de dados sem instalá-los localmente.

CircleCI é outra escolha. É uma plataforma de integração e entrega contínua que ajuda as equipes de software a liberar código automatizando o processo de compilação, teste e implantação. Não é igual às outras alternativas listadas acima.