Essas ferramentas parecem compartilhar características muito semelhantes.
Quão complicado seria começar a usar o TeamCity depois de se acostumar a trabalhar no Jenkins? Existem conceitos específicos dos quais é preciso estar ciente?
jenkins
continuous-integration
teamcity
Ricardo Herrera
fonte
fonte
Respostas:
TeamCity:
Parece melhor, se isso é importante para a sua equipe, então ele deve pesar definitivamente. Dito isso, se é MUITO importante do que você provavelmente acabará criando ferramentas ou algum tipo de sobreposição de painel para dar suporte à sua equipe; realmente quer é aquele com a melhor API. Não tentei a API do Jenkins, por isso não posso comparar; a API do TC deve fornecer o que você precisa.
O apoio deles é muito bom, os caras respondem relativamente rápido e são corteses. No entanto, isso não significa que você conseguirá o que deseja. Se você usar o sistema de maneira não convencional, poderá muito bem colocar seu bug nas prateleiras ... aconteceu conosco. Nesse ponto, torna-se bastante frustrante de usar, você se depara com uma caixa preta deixando pouca alternativa do que contorná-la. Nesse ponto, as coisas podem ficar feias e feias.
Geralmente, é bastante rápido fazer o que você deseja e a quase API de interação do log é um recurso muito bom se você executar muitos scripts personalizados em seu pipeline.
Jenkins:
Testado em batalha e extenso.
Mas é um pouco menos bonito, não chegaria a dizer que é feio, pode-se dizer que a funcionalidade vem antes da aparência.
Tenho certeza de que você pode encontrar um plano de suporte pago privado por empresas de terceiros, se olhar em volta. Se isso é importante para sua loja, não basta bloquear a parte "OpenSource" do negócio, a comunidade é bastante ampla.
Muitos, quero dizer muitos plugins. Mais uma vez, não se limite apenas aos canais oficiais, há muito mais plugins no github e em outros lugares.
Eu achei que ambos eram igualmente rápidos para começar, embora com Jenkins você precise ser mais dinâmico com plugins do que com TeamCity. Portanto, se você possui um departamento de TI restrito e não obtém acesso de administrador ao servidor, isso pode ser um problema. Composto por seu ciclo de lançamento muito mais rápido que o TeamCity (semanalmente).
Descobri que Jenkins suporta mais paradigmas do ciclo de lançamento que o TeamCity. Pode ser mais fácil encontrar um modelo de processo pronto para uso que seja mais próximo do que você tem em mente. Digo isso com reservas, pois não lido com o TeamCity há dois anos.
Pessoalmente, prefiro o Jenkins principalmente porque sou inclinado para o Open Source para essas ferramentas e, em menor grau, porque achei que a estrutura e o mecanismo de configuração concordam mais comigo.
YMMV
fonte
No geral, a experiência do usuário é bastante semelhante. O TeamCity possui uma interface de usuário mais bonita, mas não é particularmente mais fácil de usar. Em termos de funcionalidade, os dois são efetivamente equivalentes. A maior parte da terminologia também é a mesma.
Os ecossistemas de plug-ins são bastante diferentes, no entanto; você definitivamente vai querer ver quais plug-ins estão disponíveis para o TeamCity alcançar o que você está tentando fazer, pois esse provavelmente será o maior problema em termos de transição. Se você está acostumado a executar determinados plug-ins Jenkins, precisará aprender a) que funcionalidade é fornecida pelo TeamCity sem os plugins necessários eb) quais plug-ins estão disponíveis para adicionar qualquer funcionalidade restante e como eles diferem dos plug-ins que você está acostumado em Jenkins.
fonte
Eu concordo com Adrian na maioria dos pontos. A interface do usuário do TeamCity é definitivamente mais bonita e você obtém muito mais funcionalidade integrada com o TeamCity do que com Jenkins. Mas Jenkins é de código aberto e, embora a qualidade (e doc) varie muito de plug-in para plug-in, o ecossistema é extenso.
Uso Jenkins há anos e comecei a usar o TeamCity recentemente. Por exemplo, configurar trabalhos dependentes é muito mais simples e intuitivo no Jenkins do que no TeamCity.
fonte