Taverna /dev/All

CI - o que vocês tem usado?

image

Por muitos e muitos anos em nosso dia a dia temos usado o Jenkins como ferramenta de integração contínua pelas seguintes razões:

  • É fácil de operar (apesar de sempre ter achado sua interface simplesmente HORRÍVEL ao primeiro contato).
  • Bastante popular, especialmente no mundo Java.
  • Fácil de encontrar gente que saiba usá-lo.
  • Uma pletora de plugins que fazem literalmente tudo o que precisamos.

E, com o tempo, após usarmos por um período tão longo, também um certo comodismo. Mas conforme o tempo vai passando outras alternativas vão se mostrando mais atraentes: no nosso caso especialmente o Gitlab, que na prática já une a origem do que vamos integrar (nossos repositórios) com o ferramental necessário.

Então resolvi abrir esta discussão pra que possamos discutir alternativas. O que vocês tem usado como ferramenta de CI? Estão satisfeitos com o que usam? Se sim, por que? Se não, mete o ferro!

1 Curtida

Eu tenho preferido usar o default dos provedores de versionamento (gitlab, bitbucket, github).

Bitbucket eu tenho bitbucket-pipelines, Gitlab tem o CI e o github tem as actions. Então dependendo de onde ta os meus repos, uso a ferramenta de CI disponivel. Curto bastante tambem usar o travis CI pra projetos open e tentei usar circle CI, porém, não curti muito a interface.

1 Curtida

Já usei Bitbucket Pipelines + Bamboo mas se vc tiver muitos builds simultâneos fica caro escalar.

Jenkins tbm usei e resolvia apesar da parte de chata de vc manter a infra.

Estou agora na empresa no meio de uma migração de Travis CI para Circle CI. Estou gostando do Circle CI pois foi o que melhor encontrei para atender build de mobile incluindo iOS sem mto malabarismo.

Estamos usando o GitLab CI. Antes usávamos o Jenkins também. Mas o GitLab é uma ferramenta completa, opensource (temos nosso próprio servidor) e intuitiva, então pra mim não faz mais sentido ter o Jenkins.

Além disso, ele se integra com o Kubernetes para fazer os deploys automaticamente e com o Prometheus para monitorar os ambientes.

Estamos na mesma situação que vocês Bruno.

Neste exato momento estamos avaliando a possibilidade de migrar do Jenkins para o Gitlab

acho q é o movimento mais barato, se precisar de build de iOS vc pode colocar algum macbook/mac mini de worker remoto p/ ele fazer o build p/ vc

quando fui p/ o circle ci foi pelo fato de não usarmos o gitlab e não queriamos build sendo feito em lugares diferentes

Cara, da uma olhada no bitrise, to usando em um projeto e achei tudo muito fácil nele.

então, eu fiz em um dia a configuração no circle ci, o pessoal q escolheu o bitrise em uma semana não tinha entregado.

hj não tô mais na empresa e não tem mobile aqui onde estou agora =)

TFS. Acho muito prático por fazer tudo dentro do Visual Studio, sem ficar nessa doideira alternando entre um bando de ferramentas.

Só para reforçar o coro, também estou nessa mesma transição de Jenkins 2 para Gitlab CI. Usei Jenkins 1 por muito tempo, daí passamos a usar o Jenkins 2 e com ele usar pipelines declarativos em scripts versionados. Diga-se de passagem, achei muito mais fácil ler um pipeline como código que abrir aquela tela de configuração do Job com 95792353425298283410 plugins instalados e não utilizados. Cheguei a usar inclusive o recurso Docker do pipeline do Jenkins 2. Porém, nos últimos anos, com o processo de migração da base de código para o Gitlab, o Gitlab CI se tornou forte alternativa, convergindo todos esses benefícios anteriores e mantendo o assunto CI à vista por estar dentro do próprio repositório.

interessante hein? Será o fim do Jenkins em uns dois anos?

o jenkins não é usando apenas p/ CI/CD, maioria das pessoas q converso da área de engenharia de dados usam ele p/ executar o PDI (pentaho data integration) e fazer suas ETLs

então, acho q pode durar um pouco mais, legados são complexos de acabar.

mas neste caso ele tá sendo usado como uma espécie de agendador de tarefas, não?
Tipo um CRON glorificado?

Fizemos o mesmo. Primeiro Jenkins 1 para 2, usando pipelines declarativos. Usávamos o Git para armazená-los. Logo para mim, quando o GitLab ganhou mais corpo, fez todo sentido migrar para ele, já que seus pipelines também ficam armazenados no próprio repositório.

Acho que as únicas “grandes vantagens” que o Jenkins ainda tem, são seus plugins, e muito suporte da comunidade, o que facilita a vida dos iniciantes, ou quem já está acostumado com ele.

Mas quem já sabe usar o GitLab CI é capaz de substituí-lo integralmente.

Acredito que sim. E mesmo essa “funcionalidade” de CRON já pode ser feita no GitLab. No entanto, acho que muitos projetos manterão o uso do Jenkins nos próximos anos, porque o ser humano muitas vezes tende a se manter na zona de conforto, então “se tá funcionando, não mexe”.

Agora não tenho dúvidas que o Jenkins vai perder uma grande parte do seu mercado para ferramentas que integrem versionamento de código com automatização de processos. Faz todo sentido ter os pipelines versionados como código e próximos ao código da aplicação, e executados a cada commit (no caso de integração contínua, deploy contínuo) sem intervenção manual.

exatamente isso que tenho visto

itexto