Para que serve Jenkins, e o que ele pode fazer?

Em quase todas as discussões sobre integração contínua de código aberto ou ferramentas de entrega contínua (CI / CD – continuous integration or continuous delivery), o Jenkins inevitavelmente será mencionado. Mas para que é usado o Jenkins, especificamente, e como funciona?

Neste artigo, damos uma visão geral do Jenkins, como ele é usado e dicas para equipes prontas para avançar na integração desta popular ferramenta de CI / CD de código aberto.

Para que o Jenkins é usado?

Jenkins é usado para construir e testar o seu produto continuamente, para que os desenvolvedores possam integrar continuamente as mudanças na construção. Jenkins é a ferramenta de CI / CD de código aberto mais popular no mercado hoje e é usado no suporte de DevOps, junto com outras ferramentas nativas da nuvem.

Automação, incluindo CI / CD e automação de teste, é uma das principais práticas que permitem que as equipes de DevOps entreguem soluções de tecnologia “mais rápidas, melhores e mais baratas”.

Portanto, Jenkins se tornou uma ferramenta indispensável para ajudá-lo a atingir esses objetivos. Jenkins tem sido uma tecnologia de capacitação chave que está ajudando cada vez mais as práticas de DevOps a serem amplamente adotadas em muitas organizações em todo o mundo.

Jenkins é uma ferramenta de integração/entrega contínua?

Embora seja usado por muitas equipes de DevOps avançadas que oferecem aplicativos nativos de nuvem de última geração, o Jenkins já existe há um bom tempo. O projeto (originalmente chamado de Hudson) foi desenvolvido em 2004 por Kohsuke Kawaguchi enquanto trabalhava na Sun Microsystems e lançado em 2005. Depois que a Oracle adquiriu a Sun, o projeto foi bifurcado para permanecer open source e o fork foi nomeado Jenkins em 2011.

Embora Kohsuke tenha desenvolvido originalmente o Jenkins para facilitar a integração contínua para aplicativos Java, Jenkins desde então evoluiu para orquestrar todo o pipeline de entrega de software para as linguagens e tecnologias mais populares usadas por desenvolvedores em todo o mundo hoje. Escrito em Java, com extensibilidade no núcleo de sua arquitetura, existem centenas de plug-ins disponíveis que estendem o Jenkins para fornecer a flexibilidade de automatizar todos os aspectos do pipeline de entrega de software.

Antes do Jenkins …

Antes do Jenkins, muitas equipes de desenvolvimento empregavam um build noturno como parte do processo de entrega de software. O processo de construção noturno exigia que as equipes enviassem seu código ao repositório de código-fonte em um determinado horário de corte todos os dias. Isso foi um desafio ainda maior ao trabalhar com equipes geograficamente dispersas. Um horário noturno de, digamos, 23h PST equivaleria a 12h30 IST na Índia.

Portanto, os desenvolvedores na Índia seriam forçados a comprometer o seu código no meio do dia e, em seguida, esperar que a construção “noturna” fosse executada, afetando sua produtividade. Então, uma vez que o build fosse concluído, as equipes de desenvolvimento frequentemente se deparariam com a pergunta: “Quem quebrou o build?”. Nesse ponto, as equipes de desenvolvimento se esforçariam para determinar quem foi o commit que quebrou a compilação e a acusação começaria. Tinha que haver uma maneira melhor.

Como funciona o Jenkins?

O Jenkins aciona uma construção a cada confirmação para o repositório de código-fonte, normalmente para um branch de desenvolvimento.

Jenkins pode ser configurado para executar um conjunto inicial de testes de unidade para garantir que o commit não “quebrou a compilação”. Se os testes não passarem, o desenvolvedor pode ser notificado imediatamente para tomar uma ação corretiva. Isso põe de lado a questão de “Quem quebrou o build?” pois é fácil determinar qual confirmação causou a falha da compilação. Se todos os testes de unidade forem aprovados, o pipeline de construção pode prosseguir para a próxima fase com testes de integração que geralmente levam mais tempo para serem executados.

O Jenkins oferece a capacidade de executar um build em paralelo em várias máquinas para minimizar o tempo total necessário para concluir muitas dessas atividades. Por fim, o Jenkins pode implantar o build em um ambiente que permite qualquer teste de aceitação do usuário (UAT – user acceptance testing) necessário antes de liberá-lo para produção. Essas etapas simplificadas abrangem o espírito de um ambiente de integração contínua (CI).

Para alcançar o Santo Graal da entrega contínua (CD), esses testes UAT também podem ser automatizados usando uma ferramenta como Selenium, onde se esses testes passarem, o código pode ser mesclado no branch master onde uma compilação “dourada” pode ser criada e implantado diretamente na produção sem intervenção manual. As empresas que alcançaram o marco de entrega contínua podem implantar na produção muitas vezes ao dia, como Amazon, Facebook e Google.

Avançando com Jenkins para DevOps

Olhando para o futuro, Jenkins encontrou um ponto ideal em muitos ambientes DevOps. Alguns até o chamaram de “o motor do DevOps”, o uso da nuvem e dos contêineres. Jenkins pode ser executado na nuvem (AWS, Google, Azure, IBM, etc.) e tecnologias de aproveitamento como Docker e Kubernetes fornecem ao Jenkins flexibilidade, velocidade e confiabilidade adicionais para atender às demandas dos aplicativos modernos nativos da nuvem e baseados nos micros serviços de hoje. O futuro parece muito promissor com o Jenkins como uma tecnologia de capacitação chave para pipelines de CI / CD para empresas em todo o mundo.

Referencia: https://www.openlogic.com/blog/what-is-jenkins-used-for